24-Bit Bitmap um 90 grad drehen - Resourcen-Optimierung

[venice2]

Zitat von striderx:

Zitat von haentschman:

Zitat:

der Vollständigkeit halber

Vollständig wäre es mit try/finally Blocks...

Grundsätzlich richtig, aber an welcher Stelle meinst du denn, dass hier eine Exception 'durchschlägt'?. Seitens GDI+ m. W. nicht, da kann man nur mit GetLastStatus den Status der letzten Operation abfragen. Könnte man natürlich verschachteln mit mehreren if AStatus = OK , aber bei dem Größenbug von FlipRotate ist der Status OK. Und selbst wenn man das tBitmap.Create wegläßt, knallt es nicht.

Aber vielleicht übersehe ich ja etwas.

Alles gut und schön.
Nur die Funktion im GDITest Projekt spiegelt das Bild es wird nicht korrekt dargestellt.
GDIPRotateFlipBitmap (bm, Rotate90FlipY);

GDIPRotateFlipBitmap (bm, Rotate90FlipNone);
wäre korrekt!
Ist zwar schnell aber das Ergebnis zu meiner Funktion ist nur schlecht.
Vergleiche beide Bilder das von mir hochgeladene und das hier.
Das vergleichen kann man hier vergessen da die Konvertierung des Bitmap (*.png) zu *.jpg (Hier im Forum) das original verfälscht.

[striderx]

Zitat von venice2:

Ist zwar schnell aber das Ergebnis zu meiner Funktion ist nur schlecht.

Ich habe gerade Harrys Beispiel-Bild in vier 90-Grad-Schritten gedreht, und das Ergebnis ist identisch mit dem Ausgangsbild (Vergleich aller Pixel).

[Renate Schaaf]

Zitat:

Zu guter letzt noch die Feststellung, dass sich die WorkerThreads eigentlich nur bei ganz großen Dateien lohnen

Meine (erst kürzlich erworbene) Erfahrung sagt, dass es sich gar nicht lohnt. Ich hab einen Thread gemacht, der nur eine vertikale Scheibe der Bitmap rotiert. Nachdem ich endlich herausgefunden hatte, wie 2 solcher threads an den selben Bitmaps arbeiten können, ohne critical sections und ohne AV, musste ich feststellen, dass die langsamer sind. Bei einer 16000x16000 sogar doppelt so langsam. Vielleicht habe ich was falsch gemacht, aber auf alle Fälle mal wieder viel gelernt.

Gruß, Renate

[Harry Stahl]

Zitat von Renate Schaaf:

Zitat:

Zu guter letzt noch die Feststellung, dass sich die WorkerThreads eigentlich nur bei ganz großen Dateien lohnen

Meine (erst kürzlich erworbene) Erfahrung sagt, dass es sich gar nicht lohnt. Ich hab einen Thread gemacht, der nur eine vertikale Scheibe der Bitmap rotiert. Nachdem ich endlich herausgefunden hatte, wie 2 solcher threads an den selben Bitmaps arbeiten können, ohne critical sections und ohne AV, musste ich feststellen, dass die langsamer sind. Bei einer 16000x16000 sogar doppelt so langsam. Vielleicht habe ich was falsch gemacht, aber auf alle Fälle mal wieder viel gelernt.

Gruß, Renate

Doch, es lohnt sich auf jeden Fall bei großen Grafiken, wie gesagt, hier auf meinem Entwicklungs-PC von ca. 6 Sekunden auf 3 Sekunden mit Workerthreads (alle anderen Varianten ca. 5-6 Sekunden, mal abgesehen von GDI unter 32 Bit).

Aber auch bei kleineren Grafiken gewinnt man speed, wenn bei kleinen Bildern (in der Höhe < 5000 Pixel) nur 2 CPUs verwendet werden, auch da ist die Worker-Thread Variante dann die schnellste Lösung (alle anderen Lösungen brauchen bei der kleineren Grafik so 130 -250 MS, die Worker-Thread-Varinate 80-130 MS). Bei mehr CPUs wird es
bei steigender Anzahl der verwendeten CPUS bei kleineren Grafiken immer langsamer, da ist dann der Verwaltungsaufwand zu groß).