Prüfung eines Bitmaps auf Transparenz (gehts noch schneller)?

[Uwe Raabe]

Der Effekt tritt schon auf, wenn man in den Compileroptionen die Optimierung aktiviert (und natürlich ein Rebuild des Projekts macht). Interessanterweise ist die ASM-Variante mit aktiver Optimierung offenbar langsamer also ohne.

Code:

005C61C7 8BC7             mov eax,edi
Unit13.pas.143: for x := 0 to z-1 do begin
005C61C9 48               dec eax
005C61CA 85C0             test eax,eax
005C61CC 7C14             jl $005c61e2
005C61CE 40               inc eax
005C61CF 33D2             xor edx,edx
Unit13.pas.144: if RGBA[x].rgbReserved <> 255 then begin
005C61D1 807C9303FF       cmp byte ptr [ebx+edx*4+$03],$ff
005C61D6 7406             jz $005c61de
Unit13.pas.145: EXIT (TRUE);
005C61D8 C645FF01         mov byte ptr [ebp-$01],$01
005C61DC EB04             jmp $005c61e2
Unit13.pas.147: end;
005C61DE 42               inc edx
Unit13.pas.143: for x := 0 to z-1 do begin
005C61DF 48               dec eax
005C61E0 75EF             jnz $005c61d1

[Namenloser]

Assembler-Befehle wie LOOP sollte man heutzutage nicht mehr verwenden, die sind auf modernen CPUs ziemlich langsam. Vermutlich liegt es daran.

Wenn schon Assembler, dann wäre eher was mit SIMD interessant.

Ansonsten würde mir noch folgende reine Pascal-Alternative einfallen:

Delphi-Quellcode:

function HasTransparentRGBAValues (const bm:TBitmap): Boolean;
var
  x, z: Integer;
  pixel: PLongWord;
begin
  Result := FALSE;
  pixel := bm.Scanline[bm.Height-1];
  z := bm.Width * bm.Height;

  for x := 0 to z-1 do begin
  begin
    if (pixel^ and $FF000000) <> $FF000000 then 
      EXIT (TRUE);
    inc(pixel);
  end;
end;

Statt auf den Pointer einen Offset von 3 Bytes hinzuzuaddieren, werden die 32 Bit einfach maskiert. Ob das schneller ist, keine Ahnung.

[Uwe Raabe]

Zitat:

Zitat von Namenloser (Beitrag 1330966)

Ansonsten würde mir noch folgende reine Pascal-Alternative einfallen:

Mal abgesehen, daß die sich wegen eines zusätzlichen

Delphi-Quellcode:

begin

nicht compilieren lässt, ist sie zeitlich gleichauf mit der ursprünglichen Routine. Insofern ist bisher noch der einzige erfolgreiche Ansatz zur Optimierung das Aktivieren der Optimierung in den Compileroptionen.

[Neutral General]

Hab ne andere Idee:

Delphi-Quellcode:

function HasTransparentRGBAValues (const bm:TBitmap): Boolean;
var
  x, z: Integer;
  pixel: PRGBQuad;
  sum: Cardinal;
begin
  pixel := bm.Scanline[bm.Height-1];
  z := bm.Width * bm.Height;

  sum := 0;
  for x := 0 to z-1 do
  begin
    sum := sum + pixel^.rgbReserved;
    inc(pixel);
  end;

  Result := sum < (z * 255);
end;

Ob das schneller ist, ist natürlich die Frage weil die ganze Schleife durchlaufen muss.
Dafür spart man sich ggf. ne Menge Vergleiche. Ein Versuch ists Wert denke ich.

[himitsu]

Bei Assambler kann keine Codeoptimierung greifen. :stupid:

[Harry Stahl]

Zitat:

Zitat von frankyboy1974 (Beitrag 1330949)

hallo,

ich kenne jetzt ja die fachlichen Anforderungen nicht genau, aber man könnte natürlich auch sagen, wer würde bei einem Bitmap von circa 10 Mio. Pixeln schon ein einziges Pixel auf transparent setzen. Oder anders formuliert, muss du wirklich jedes Pixel auf Transparenz überprüfen, oder würde es nicht reichen 1 Pixel zu überprüfen und dann ein gewisse Anzahl zu überspringen, bis du das nächste Pixel überprüfst.:wink:

Ansonsten würde ich auch die Variante empfehlen, dass du je nach Anzahl der verfügbaren Computerkerne, eine ensprechende Anzahl parallele Handungsabläufe erzeugst.


mfg

Ja, es geht hier um Bilder, das aus mehreren Ebenen besteht (z.B. aus Photoshop bzw. meinem eigenen Dateiformat, siehe mal zur Demo anliegenden Screenshot). Da muss ich halt prüfen, ob ein Ebenenbild ein oder mehrere Pixel mit Transparenz hat, denn das muss ich dann mit dem darunterliegenden verrechnen (ohne Transparenz kann man es einfach drüberschreiben).

Da die Verrechnungsvariante auf jeden Fall deutlich länger dauert, als die Variante des Drüberkopierens, lohnt es sich, zunächst rauszufinden, ob das Bild eine Transparenz hat oder nicht.

Oft ist es bei Bildkompositionen so, dass die Hintergrundebene ohne Transparenz ist und die drüberliegenden Bilder mit Teiltransparenzen. I.d.R. ist dann auch das Hintergrundbild das größte Bild von allen und da muss ich dann halt eben einmal ganz durchprüfen, braucht aber relativ viel Zeit, die ich gerne noch etwas reduzieren möchte.

[Neutral General]

Hast du meinen letzten Vorschlag mal probiert?
Würde mich echt interessieren ob das schneller ist :)

[Harry Stahl]

Hey, Danke erst mal an Alle, die sich hier an den Überlegungen beteiligt haben.

In der Tat muss man den Einwand von Uwe berücksichtigen, ob mit Debug oder Release kompiliert.

Da die Auslieferung des Programms natürlich in Release erfolgt, ist das letztlich der Maßstab (hatte mein Demo aber im Debug-Modus getestet).

Anliegend daher die hier aufgeführten Varianten einmal zum Testen eingebaut, die jeweilige Methode kann man aus der Drop-Downbox auswählen.

Die ASM-Variante ist die schnellste im Debug-Modus (ca. 32 MS, im Gegensatz zu meiner Standard-Methode hier mit ca. 50 Ms).

Im Release Modus bleibt die ASM-Variante bei 32 MS und meine Standard-Methode kommt auf ca. 24 MS.

[Harry Stahl]

Zitat:

Zitat von Neutral General (Beitrag 1330998)

Hast du meinen letzten Vorschlag mal probiert?
Würde mich echt interessieren ob das schneller ist :)

Ja, Deine Nachfrage und meine Antwort haben sich hier gerade überschnitten.

Also im Release-Modus leider nicht schneller.

Wenn es da den SUPER-ASM-Befehl nicht gibt, müsste man sich vielleicht in den DirectX-Funktionen noch einmal umsehen, evtl. gibt es da etwas, was per GPU-Unterstützung diese Frage beantworten kann.

[Blup]

Hast du an andere Wege der Optimierung gedacht, wird die Information für jede Bildebene irgendwo gespeichert?