Suche Schnelle Alternative zu "CopyRect"

[EWeiss]

Zitat:

Zudem erzeugt die OpenGl version ja gar keine CPU Load ...

Wie denn auch OpenGL nutzt die Grafikkarte und weniger die CPU.
Bei BItBlt ist das genau umgekehrt die API hat mit deiner Grafikkarte(Hardware) nix zu tun
Deshalb geht das voll auf die CPU

das einzigste was mit BitBlt gleich kommt ist GDI
GdipDrawImageRectRectI

Schau dir das Beispiel Blub von turboPascal an

gruss Emil

[turboPASCAL]

Wie gross sind denn die Bitmaps die du kopieren möchtest und wie wird das Endergebnis auf dem Bildschirm
angezeigt ?

[Corpsman]

die einzelbildchen werden ja aus großen rausgeschnitten und sind immer 8x12

das endergebniss wird dann wie bereits geschrieben mittels canvas.draw ausgegeben.

[Blup]

Ist das Pixelformat bei allen beteiligten Bitmaps "pfDevice", das heist gleich dem Ausgabegerät?

[Corpsman]

Nope ich hatte pf24bit.

Allerdings habe ich das Grad getestet, und mit pfDevice bekomme ich 2 - 3 FPS weniger als mit pf24bit. Keine Ahnung why, evtl mus der ja bei pf24bit wegen der nur 3 byte tatsächlich weniger kopieren, meine Screen Auflösung ist schlieslich 32 Bit = 4 Byte.

[OldGrumpy]

8x12 ist etwas krumm, schau doch mal ob 8x8 oder 8x16 bessere Ergebnisse im Speed bringen. Ausserdem kann es Speedvorteile bringen wenn aus einem zusammenhängenden Block gelesen werden kann (durchs Caching), schau doch mal ob Du die Reihenfolge der einzelnen Kopiervorgänge sortieren kannst bevor die durchgeführt werden.

[Corpsman]

Uff, sortieren ist halt auch "Teuer"

Witzigerweise konnte ich das Double Buffering ausmachen, und das hat mir auch noch mal 1-2 FPS gebracht, ohne das es Flackert ;)

und 8x12 ist es halt wegen der Font .. ( letzendes sind das ja Ascii Font teile die ich Kopiere ... )

[Phantom1]

Müssen es denn eigentlich 24bit bzw 16,7 mio farben sein? oder würden auch 15bit bzw 32767 farben reichen? denn wenn du alles auf pf15bit umstellst dürften nämlich die fps um ca 50% steigen.

[Corpsman]

in dem Programm selbst nutze ich nur 10 Verschiedene Farbwerte.

D.h. theoretisch würden sibat 4Bit reichen, Nur weis ich nicht in wie weit man das reinprogrammieren kann.

Momentan habe ich ein Arrey 0..9 das die RGB werte in Byte größe beinhaltet, deswegen eben 24bit...

Delphi-Quellcode:

 
Type
 
  Tvector3ub = Record
    x, y, z: Byte;
  End;

Const
 Colors: Array[0..9] Of Tvector3ub = (
    (x: 18; y: 29; z: 13),
    (x: 26; y: 43; z: 18),
    (x: 34; y: 57; z: 23),
    (x: 42; y: 71; z: 28),
    (x: 50; y: 85; z: 33),
    (x: 50; y: 87; z: 36),
    (x: 75; y: 129; z: 52),
    (x: 100; y: 171; z: 68),
    (x: 125; y: 213; z: 84),
    (x: 150; y: 255; z: 100));

[Phantom1]

Zitat:

Zitat von Corpsman

in dem Programm selbst nutze ich nur 10 Verschiedene Farbwerte.

Ums einfacher zu machen würde ich in dem fall warscheinlich mit 8bit arbeiten.

Zitat:

Zitat von Corpsman

Momentan habe ich ein Arrey 0..9 das die RGB werte in Byte größe beinhaltet, deswegen eben 24bit...

Könntest du evtl mal den kompletten sourcecode als download anbieten oder mir per pn zuschicken, dann könnte ich selbst mal schauen.