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

[Amateurprofi]

Zitat von Harry Stahl:

Zitat von Amateurprofi:

Hallo Harry:
Ich hab mir mal die Mühe gemacht, mehrere ASM-Routinen zu schreiben, die alle recht flink arbeiten, und zusätzlich ein kleines Testprogramm.

Wow, bin beeindruckt

In der Anlage ein Screenshot mit den Testergebnissen. Meine AMD-CPU ist halt doch ein Ticken langsamer.

Was mich aber wundert, sind die z.T. erheblichen Schwankungen beim gleichen Test (SSE: 13 / 25 MS).

32- oder 64-Bit macht keinen nennenswerten Unterschied.

Hallo Harry,
zu "Was mich aber wundert, sind die z.T. erheblichen Schwankungen beim gleichen Test (SSE: 13 / 25 MS)."

Ich habe (bei allen Funktionen) ähnliche Schwankungen gesehen, allerdings nur, wenn ich das als "Release" compiliert hatte.
Bei "Debug" waren die Schwankungen eher im Normalbereich.

[Memnarch]

Zitat von Harry Stahl:

Meine CPU ist schon etwas älter, aber durchaus schnell genug für meine Zwecke:

AMD Athlon 64 X2 Dual Core Processor 5000+, 2600 MHz, 2 Kern(e), 2 logische(r) Prozessor(en)

Die hier gezeigte Variante ist mit ca. 23 MS in etwa so schnell wie meine Lösung (ebenfalls im Release-Mode)

Ahh also etwas betagter und auch noch AMD^^".
(Release 2007 wenn ichs recht sehe?)

[Uwe Raabe]

Zitat von Harry Stahl:

Meine CPU ist schon etwas älter, aber durchaus schnell genug für meine Zwecke:

Zitat von Harry Stahl:

...benötigt die Routine hier auf meinem Rechner ca. 80 MS um das ganze Bitmap zu prüfen, was ziemlich viel Zeit ist.

[Memnarch]

Ach sach ma:
Wie misst du eigentlich die Zeit? Doch hoffentlich nicht mit Now()

Nochmal genauer gemessen:
Meine alte Variante brauchte ~ 5.8ms
Nen bisschen was umgestellt und jetzt läuft sie bei mir zwischen 3.9 - 4.1ms
(Vielleicht ist nen off by one error drin nicht genau geprüft *hust*)

Delphi-Quellcode:

type
  TRGBA = packed record
    B, G, R, A: Byte;
  end;

  PRGBA = ^TRGBA;

  TRGBA4 = array[0..3] of TRGBA;
  PRGBA4 = ^TRGBA4;

  TScanLine = array[0..100000] of TRGBA;
  PScanLine = ^TScanLine;

function HasTransparentRGBAValues(const bm:TBitmap): Boolean;
var
  z: Integer;
  RGBA: PScanLine;
  LPixels, LLastPixels: PRGBA4;
  LPixel: PRGBA;
  i: Integer;
begin
  RGBA := bm.Scanline[bm.Height-1];
  z := bm.Width * bm.Height;
  LPixels := @RGBA[0];
  LLastPixels := @RGBA[z div 4 * 4];
  while (LPixels <> LLastPixels) and ((LPixels[0].A and LPixels[1].A and LPixels[2].A and LPixels[3].A) = 255) do
    Inc(LPixels);
  Result := ((LPixels[0].A and LPixels[1].A and LPixels[2].A and LPixels[3].A) <> 255);
  if not Result then
  begin
    Inc(LPixels);
    LPixel := PRGBA(LPixels);
    for i := 0 to z mod 4 - 1 do
    begin
      if LPixel.A < 255 then
        Exit(True);
      Inc(LPixel);
    end;
  end;
end;

[Harry Stahl]

Zitat von Memnarch:

Ahh also etwas betagter und auch noch AMD^^".
(Release 2007 wenn ichs recht sehe?)

Ja, korrekt. Aber durch eine Giga-SSD und zügige NVIDIA-Karten eigentlich noch gut nutzbar.

[Harry Stahl]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

Meine CPU ist schon etwas älter, aber durchaus schnell genug für meine Zwecke:

Zitat von Harry Stahl:

...benötigt die Routine hier auf meinem Rechner ca. 80 MS um das ganze Bitmap zu prüfen, was ziemlich viel Zeit ist.

Also die erste Messung meiner Standard-Methode war im Debug-Modus mit AQTime, da habe ich wohl mal 80 MS gemessen. Das scheint aber relativ zu schwanken, jetzt kriege ich DEBUG-Modus immer um die 60 MS. Im Release-Modus um die 50 MS.

Im Unterschied dazu sind die Messungen mit der Demo-Anwendung, die ich geschrieben und hier ja mal hochgeladen hatte etwas anders.

Im Debug-Modus erhalte ich dort ca. 50 MS und im Release-Modus ca.23 MS.

Warum hier diese Abweichungen in der Messung zwischen AQTime und Queryperformancecounter sind, weiß ich leider auch nicht.

[Harry Stahl]

Zitat von Memnarch:

Ach sach ma:
Wie misst du eigentlich die Zeit? Doch hoffentlich nicht mit Now()

Nochmal genauer gemessen:

Messe mit

QueryPerformanceFrequency(iTimerFreq);
QueryPerformanceCounter(iTimerStart);

Das sollte doch OK sein, oder?

[Sir Rufo]

Gemütlicher geht das mit TStopWatch

[Harry Stahl]

Zitat von Amateurprofi:

Hallo Harry,

das kann so auch nicht funktionieren.
Das Boolean-Resultat einer Funktion wird im Register AL erwartet, also dem unteren Byte von EAX.
Der Asm-Teil stellt deshalb das Resultat in AL.

Bei einer Pascal-Funktion (nicht Pure-Asm) wird eine lokale Variable "Result" angelegt, deren Inhalt vor dem Verlassen der Funktion, i.d.R. vor der Bereinigung des Stacks nach AL kopiert wird.
Was vorher in AL stand, geht dabei verloren.

Ich hab das mal im Debugger angeschaut (siehe weiter unten):
In der Kopie ist leider nicht zu sehen, an welcher Stelle der Haltepunkt ist.
Dehalb :
Der Haltepunkt steht an der Adresse 0052D36D und dort wird das Ergebnis der Prüfung, (hier True) in AL gestellt.
Versuch mal folgendes:
Beim Label True:
Das mov al,True ersetzen durch mov Result,True
Und zwei Zeilen darüber
das xor al,al ersetzen durch mov Result,False
Weiß nicht ob das dann funktioniert.
Meine Enpfehlung ist, ASM und Pascal strikt zu trennen. Der "Doppelte Funktionsaufruf", den du vermeiden möchtest,
kostet nichts (oder so gut wie nichts), er bringt dir aber sauberen Code.

Meine ASM-Kenntnisse sind leider sehr rudimentär. Scheint aber mit Deinen Änderungen jetzt zu funktionieren, jedenfalls fällt mir nichts ungewöhnliches mehr auf. Scheint wohl insgesamt die schnellste Variante zu sein. Unter AQTime kommt die so zwischen 35 und 45 MS (meine Demo-Version ca. 22 MS).

Insgesamt glaube ich aber inzwischen, dass man hier per ASM oder sonstige Prüf-Optimierungen wohl nicht mehr viel machen kann (wenn es denn DEN Super-ASM-Befehl nicht gibt).

[Harry Stahl]

Zitat von Sir Rufo:

Gemütlicher geht das mit TStopWatch

Klar, das kannte ich auch schon, denn wenn man unter FMX was messen will (insbesondere andere OS), dann ist es da die angesagte Funktion.

Unter Windows benutzt TStopwatch aber auch QueryPerformanceCounter und hier hatte ich mir schon vor langer Zeit mal die benötigten MS-Funktionen in eigene Start- und Stop-Funktionen gekapselt.

Aber wer das noch nicht gemacht hat, kann hier Dank der neueren Delphi-Versionen direkt bequem per Einbindung der Systems.Diagnostics drauf zugreifen.