schnelle Zeichen Routinen. Zur Zeit Canvas.Draw

[WordsBG]

Mit Andorra würdest du einfach alles in eine TAdImageList laden und dann per Draw zeichnen. Nicht viel aufwendiger aber wahlweiße DirectX oder OpenGL beschleunigt.

[Lossy eX]

GDI: Die Geschwindigkeit ist unterschiedlich. Das kommt ganz darauf an ob die Grafikkarte mit zur Beschleunigung genutzt wird oder nicht. Wenn du ein TBitmap erstellst dann solltest du in jedem Falle den HandleType auf bmDDB stellen. Dadurch weißt du der GDI mit vorhandene Hardware benutzen zu dürfen. Wenn der auf bmDIB steht dann läuft alles auf der CPU ab. Ein frisch geladenes Bit steht auf bmDIB.

PS: Den HandleType natürlich erst dann setzen wenn das Bitmap komplett geladen ist. Also fertig zum zeichnen. Ansonsten wird der womöglich wieder zurückgesetzt.

PPS: Wenn du auf die Scanlines zugreifen möchtest darfst du bmDDB nicht verwenden. Da dadurch die Scanlines nicht verfügbar sind. Du kannst es aber auch kurzzeitig umstellen.

[Muetze1]

Zitat:

Zitat von Lossy eX

GDI: Die Geschwindigkeit ist unterschiedlich. Das kommt ganz darauf an ob die Grafikkarte mit zur Beschleunigung genutzt wird oder nicht. Wenn du ein TBitmap erstellst dann solltest du in jedem Falle den HandleType auf bmDDB stellen. Dadurch weißt du der GDI mit vorhandene Hardware benutzen zu dürfen. Wenn der auf bmDIB steht dann läuft alles auf der CPU ab. Ein frisch geladenes Bit steht auf bmDIB.

Wieso sollte DIB über die CPU ablaufen? Die Grafikkartentreiber können die GDI Befehle durch eigene, beschleunigte Funktionen ersetzen. Wenn den neuen Implementierungen was nicht passt, rufen sie die langsamen Originalroutinen auf. die Standard GDI von Windows macht eigentlich alles in Software und erst die Treiber sorgen für Geschwindigkeit. Warum aber ein DIB nicht beschleunigt werden sollte, ist mir ein Rätsel. Ein DDB bedeutet nichts weiter, als dass es ein Palette (falls benötigt) im aktuellen Context gestellt wird. Spätestens ab den nicht Paletten-basierenden Farbtiefen von 15 Bit und aufwärts ist keine mehr nötig und man hat die Pixelinformationen. Dabei rechnet der Treiber diese Informationen genauso schnell in das im Grafikkartenspeicher genutzte System um um es dann direkt zu verwenden. Bei den DDBs hast du nur mehr Probleme, u.a. bei paletten-basierenden Auflösungen etc und vor allem durch die entsprechende Anpassung der Farbpalette. Male auf einem 256 Farben Screen mit einer selbstgemischten Farbe auf einem DDB - die Farbe wird immer dem farblich nächsten Eintrag angepasst und entspricht nicht mehr deiner Mischung. Das RealizePalette() System klappt in der VCL eh nicht ganz richtig und macht hier nur mehr Probleme.

Meine App arbeitet in der gesamten Firma auf den unterschiedlichsten Rechnern und Betriebssystem und genauso Auflösungen und unterschiedlichen Farbtiefen immer ohne flackern oder Verzögerungen. Selbst ein PII muckt nicht rum...

Zitat:

Zitat von Lossy eX

PPS: Wenn du auf die Scanlines zugreifen möchtest darfst du bmDDB nicht verwenden. Da dadurch die Scanlines nicht verfügbar sind. Du kannst es aber auch kurzzeitig umstellen.

Wobei dabei wieder die gesetzten (z.B. RGB Werte) der aktuellen Palette des Devices angepasst werden und somit die Farben verändert werden.

[Whookie]

Zitat:

Zitat von Jackie1983

habe es jetzt geändert. Soweit so gut, bei 100 Objekten ist die cpu bei 70-75%
Das ist mir leider noch zu viel. Da werde ich wohl oder übel auf opengl umsteigen.....

Hmm ... bist du dir sicher das du das ganze an der richtigen stelle machst (also im OnPaint)? Was du da schilderst klingt einwenig nach permanentem Aufrauf deiner Zeichenroutine??

[Lossy eX]

Muetze1: Was Palettenbilder angeht muss ich gänzlich passen. Ich arbeite aussließlich mit 24 oder 32 Bit Bildern/Farbtiefen. Und dort wo ich es bisher eingesetzt habe darf man so etwas auch erwarten. Von daher kann ich dazu gar nichts sagen.

Hardwarebeschleunigung: Was genau alles beschleunigt wird liegt voll und ganz in den Händen des Treibers. Da stimmen wir beide ja überein. Ob DIBs jetzt wirklich nur auf der CPU ausgeführt werden kann ich mit Gewissheit nicht sagen, da ich mich bisher nie so genau damit beschäftigt habe was unten drunter passiert. Allerdings habe ich damit schon sehr viele Tests gemacht und diese sprechen eindeutig dafür, dass (auf meinen bisherigen Systemen) die DDBs das gegünstigtere Format waren.

1. Versuch mal bei ein DDB eine entsprechend große Größe einzustellen. Ab einer gewissen Größe bekommst du gnadenlos nur noch Out Of Resurce Exceptions. Wärend ein DIB nur von dem verfügbaren RAM begrenzt werden. Zusätzlich dazu kann man an der Auslastung des Speichers der Anwendung gut sehen, dass sich DDBs so gut wie gar nicht bemerkbar machen. DIB hingegen vollkommen.

2. Einfacher Geschwindigkeittest. Das Zeichnen von 1000 256x256 Bitmaps (immer das selbe) auf einer 800x600 Fläche. Inklusive Bliten der Fläche auf einem Formular. Allerdings alles OHNE direkte GDI und unter der Vorraussetzung, dass der Treiber es beschleunigt.
Beide Bilder DDB = 11 ms
Beide Bilder DIB = 380 ms

In der Delphihilfe wird von geräteabhängigen (DDB) und geräteunabhängigen (DIB) Bitmaps gesprochen. Ich denke mal diese Beschreibung trifft es besser (eigentlich benutze ich auch immer das). Laut OH sind DIBs auch wesentlich kompatibler was sich aber in einer langsameren Geschwindigkeit äußert.

[Gandalfus]

Zitat:

Also wenn Du auf GDI umstellst müsstest du um einiges schneller werden.

TCanvas ist GDI bzw eine Wrapper Klasse für die GDI.