Verständnisfrage: TImage

[Medium]

Es ist der absolut übliche, und vermutlich auch performanteste Weg, ein Bitmap zu leeren, in dem man es wirklich einfach mit einem großen Rechteck übermalt.

Selbst 3D APIs machen das im Prinzip so, es ist auch auch der aus Computersicht offensichtlichste Weg. Der Speicher in dem das leere neu erzeugte Bild sein soll muss irgendwie initialisiert werden um nicht buntes Rauschen darin zu haben, also wird auch das Neu-Erzeugen einer frischen Instanz letztlich intern das frische neue Bitmap anfangs so "leeren" müssen. Warum dann erst den ganzen Aufwand drumrum mit verursachen?

Das Erzeugen neuer Instanzen bedingt hier insbesondere auch immer wieder Griffe in die GDI, was i.A. am Ende kaum besser sein kann. Vor allem nicht, wenn auch noch munter Größen neu angepasst werden müssen etc., wodurch schlimmstenfalls auch noch große Blöcke umher kopiert werden müssen - von den nötigen Allokationen mit ggf. Auslagern u.ä. mal ganz abgesehen. Es macht einfach null komma gar kein Sinn das so tun zu wollen.

Übermal einfach. Schnell, schlank, usus.

[SearchBot]

Zitat von Medium:

Es ist der absolut übliche, und vermutlich auch performanteste Weg, ein Bitmap zu leeren, in dem man es wirklich einfach mit einem großen Rechteck übermalt.
...
Übermal einfach. Schnell, schlank, usus.

Gefällt mir.
(Blöd daß es keinen Button/smiley dafür gibt )

[Medium]

Zusatz: Man könnte natürlich auch ein wenig freaky werden, sich den Pointer auf die Rohdaten abholen (Scanline), und da mit ZeroMemory() oder FillChar() rumfuchteln. Könnte sogar noch einen Happs flotter sein, man muss dabei nur aufpassen wie rum das Bitmap im Speicher liegt. (Normal ist Bottom-Up, also quasi falsch rum. Muss es aber nicht, und Windows entscheidet recht eigenmächtig wann das so ist )
So arg viel schneller sollte man damit aber im Mittel auch nicht werden, aaaber es würde wohl gehen und auch sehr schlank sein

Edit: Noch ein sehr schneller Weg: Eine Bitmap mit dem "Leerbild" vorhalten, und zum leeren dieses mit BitBlt() kopieren. Könnte sogar noch besser sein als das obige! (Zumindest etwas weniger "hacky")

[himitsu]

Was mag wohl theoretisch schneller sein?

- etwas zu kopieren/abzumalen (viele Bytes von hier nach da kopieren)
- oder einen Eimer voll Farbe drüberzukippen (nur einen kleinen Wert laden und damit alles füllen)

[Medium]

Der Vorteil dürfte hier aus BitBlt resultieren, da dieser imho große Blöcke am Stück bewegt, während ZeroMemory und FillChar letztlich eine Schleife über Bytes macht. Allerdings kennen ich die Interna von BitBlt zu wenig, man müsste es also mal testen. (Früher war sowas ja über den "Blitter" quasi Hardware-beschleunigt, es käme also darauf an, ob bei BitBlt ebenfalls ähnliche Dinge hinter stecken, oder auch das am Ende nur eine Read-Write-Loop auf Bytes ist.)