schnelle Zeichen Routinen. Zur Zeit Canvas.Draw

[Jackie1983]

hi,

zur Zeit Zeichne ich meine Bitmaps sind ca. 100-200 auf ein Canvas mit canvas.Draw(x,y,bitamp)
Nur wenn ich 100 Bitmaps zeichnen muss, ist die cpu bei 100%.

Bin also auf der suche nach einer Methode die etwas schneller ist. Die Bitmaps können verschoben werden und sind in einer liste vorhanden die ich mit einer for schleife durchgehe. Hatte damals schon mal mit opengl gearbeitet. Müste mich aber wieder komplett einarbeiten......

Was meint ihr?

[mkinzler]

Von der Performance ist OpenGL oder DirectX auf jeden Fall besser.

[Apollonius]

Du kannst mal schauen, ob BitBlt schneller ist. Für die DCs musst du Canvas.Handle und Bitmap.Canvas.Handle einsetzen.

[Jackie1983]

Zitat:

Zitat von Apollonius

Du kannst mal schauen, ob BitBlt schneller ist. Für die DCs musst du Canvas.Handle und Bitmap.Canvas.Handle einsetzen.

leider nicht die methode ist noch langsamer wie jetzt.........

[Jackie1983]

Zitat:

Zitat von mkinzler

Von der Performance ist OpenGL oder DirectX auf jeden Fall besser.

dann werde ich mich wohl oder übel wieder mit opengl beschäftigen.....

[OlafSt]

Zitat:

Zitat von Jackie1983

Zitat:

Zitat von Apollonius

Du kannst mal schauen, ob BitBlt schneller ist. Für die DCs musst du Canvas.Handle und Bitmap.Canvas.Handle einsetzen.

leider nicht die methode ist noch langsamer wie jetzt.........

Das wundert mich jetzt... Ich habe BitBlt eingesetzt, um Canvas.Draw loszuwerden, denn Bitblt war Faktor 20 schneller. Selbst die Umstellung auf MaskBlt (wegen der Transparenz) war noch immer 12x schneller.

[Jackie1983]

dann habe ich was falsch gemacht....

[Whookie]

Also wenn Du auf GDI umstellst müsstest du um einiges schneller werden. Der beste Weg IMHO. Zuerst einen CreateCompatibleDC einen Memory-DC holen , dann mit BitBlt alles in den Memory-DC blitten und den zum Abschluß einmalig auf den Canvas, das sollte mehr als den Faktor 20 bringen!

[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.....

[Muetze1]

Ich habe eine Anwendung entwickelt welche mit BitBlt und z.T. auch Draw über tausend Objekte auf dem Form Canvas malt und habe gar keine Probleme und vor allem keine CPU Last. Ich nutze dabei aber InvalidateRect(), TCanvas.ClipRect, InterSectRect() und wie gesagt BitBlt(). Bei mir werden Objekte wirklich nur gemalt, wenn sie gemalt werden müssen (schneiden oder innerhalb des ClipRect) und dann auch nur den Teil, den sie malen müssen (IntersectRect() liefert das Übeschneidungsrechteck). Ganz ohne OpenGL oder andere Dinge..

[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.