Optimierung von Pixel

[Memnarch]

Kurze Frage(vllt hab ich das übersehen):
Warum puffert ihr die Scanlines? Beim Abfragen einer Scanline bekommt ihr doch nur einen Pointer. Von dort aus kann man sich selbstständig durch die Bitmap wühlen o.O.

Habe mich immer daran gehalten:
http://edn.embarcadero.com/article/29173

Um es damals in meinem SoftwareRenderer zu implementieren:
https://github.com/Memnarch/Software...ter/Shader.pas
https://github.com/Memnarch/Software...olorShader.pas

[Uwe Raabe]

Dazu müsste man wissen, ob die Zeilen in aufsteigender oder absteigender Reihenfolge vorliegen. Dann könnte man das so machen.

[Memnarch]

Steht oben im ersten Artikel ;)

Zitat:

Scanlines are stored in memory sequencially, usually in reverse order, like this:

[Medium]

Das Puffern der Scanlines kommt da her, dass Emil fortschreitend vertikale Linien zeichnet, und das von mir schon weiter vorne im Thread vorgeschlagene für jeden Pixel immer wieder neu Abholen der Scanline unerwartet große Performance-Einbußen brachte. Im 8-Bit Thread wurde auch meine Idee von weiter vorne hier, auf einem gerdrehten Offscreen-Bitmap zu malen, und dann mit PlgBlt gedreht auf das Formular angesprochen. Mittlerweile glaube ich aber, dass das gegenüber den gepufferten Scanlines keinen merklichen Gewinn bringt, eher sogar noch Verlust, da das Bild ja nach jeder Spalte erneut ausgegeben werden soll, und man dann pro Spalte je einen PlgBlt Aufruf dazu bekäme.
Ich halte die aktuelle Version mit gepufferten Scanlines und vertikalem Zeichnen direkt in das Ziel-Bitmap für sehr nah am mit der VCL erreichbaren Optimum.

[EWeiss]

Zitat:

Ich halte die aktuelle Version mit gepufferten Scanlines und vertikalem Zeichnen direkt in das Ziel-Bitmap für sehr nah am mit der VCL erreichbaren Optimum.

Sehe ich ebenfalls so. Ob da noch eine Leistungssteigerung zu erwarten ist möchte ich bezweifeln
da jetzt, lange genug getestet, das Zeichnen das kleiner übel ausmacht.
Aber natürlich kann man es weiterhin versuchen ;)

gruss

[Zacherl]

Zitat:

Zitat von Memnarch (Beitrag 1335226)

Kurze Frage(vllt hab ich das übersehen):
Warum puffert ihr die Scanlines? Beim Abfragen einer Scanline bekommt ihr doch nur einen Pointer. Von dort aus kann man sich selbstständig durch die Bitmap wühlen o.O.

Das hatte ich irgendwo weiter vorne auch schon in Betracht gezogen. Sprich:

Delphi-Quellcode:

ScanLine

von der ersten Zeile anfordern und danach den Begin er weiteren Zeilen im zurückgelieferten Zeiger manuell berechnen.

Allerdings gibt es da ein paar Edge-Cases, die man beachten müsste. Windows erlaubt z.b. Bottom-up Bitmaps, bei denen man die Indizes der Zeilen invertieren müsste. Auch kann man die Zeilen nicht einfach in der Form

Delphi-Quellcode:

CurrentLinePointer := Pointer(PByte(ScanLine0Pointer) + ((Bitmap.Width * 3{pf24Bit}) * CurrentLineNumber))

berechnen, weil die Daten im Speicher unter Umständen aligned werden. Das kann man aber theoretisch alles ermitteln, also machbar wäre es schon.

[himitsu]

Delphi-Quellcode:

var
  ScanlineTempArray: array of PPixelRect;

ScanlineTempArray[Line][Row] := ...;

Poiner-Arithmetik muß für PPixelRect aktiv sein und am Schnellsten geht es mit einem 32-Bit-Bitmap, da alles aligned und mit "vollständigen" Integern arbeitet, wo die CPU nix groß verschieben und zusammenkopieren/maskieren muß.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1335319)

Delphi-Quellcode:

var
  ScanlineTempArray: array of PPixelRect;

ScanlineTempArray[Line][Row] := ...;

Poiner-Arithmetik muß für PPixelRect aktiv sein und am Schnellsten geht es mit einem 32-Bit-Bitmap, da alles aligned und mit "vollständigen" Integern arbeitet, wo die CPU nix groß verschieben und zusammenkopieren/maskieren muß.

Habe nichts dagegen wenn du es versuchst.
Ob es Vorteile hat wird sich dann zeigen. :)

Das letzte Sample ;)

gruss

[Memnarch]

Zitat:

Zitat von himitsu (Beitrag 1335319)

Delphi-Quellcode:

var
  ScanlineTempArray: array of PPixelRect;

ScanlineTempArray[Line][Row] := ...;

Poiner-Arithmetik muß für PPixelRect aktiv sein und am Schnellsten geht es mit einem 32-Bit-Bitmap, da alles aligned und mit "vollständigen" Integern arbeitet, wo die CPU nix groß verschieben und zusammenkopieren/maskieren muß.

Also wenn mich nicht meine (trübe) erinnerung täuscht ist das blitten einer 32bit bmp am ende sogar etwas schneller als einer 24bit oder 16bit bmp. Meine windows muss da rumfuhrwerken. Sicher bin ich mir nicht(mehr...). Hab mir angewöhnt fürs (perpixel) rendern immer auf 32bit zu gehen.

[EWeiss]

Zitat:

Zitat von Memnarch (Beitrag 1335321)

Zitat:

Zitat von himitsu (Beitrag 1335319)

Delphi-Quellcode:

var
  ScanlineTempArray: array of PPixelRect;

ScanlineTempArray[Line][Row] := ...;

Poiner-Arithmetik muß für PPixelRect aktiv sein und am Schnellsten geht es mit einem 32-Bit-Bitmap, da alles aligned und mit "vollständigen" Integern arbeitet, wo die CPU nix groß verschieben und zusammenkopieren/maskieren muß.

Also wenn mich nicht meine (trübe) erinnerung täuscht ist das blitten einer 32bit bmp am ende sogar etwas schneller als einer 24bit oder 16bit bmp. Meine windows muss da rumfuhrwerken. Sicher bin ich mir nicht(mehr...). Hab mir angewöhnt fürs (perpixel) rendern immer auf 32bit zu gehen.

Es ist aber nicht allein damit getan pf32Bit zu übergeben.
Denn dann wird das Bitmap Grau.
Was fehlt dann noch?

gruss

[Medium]

Du musst auch dann natürlich deine Pointertypen anpassen ;) PRGBQuad statt PRGBTriple in diesem Fall.

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1335327)

Du musst auch dann natürlich deine Pointertypen anpassen ;) PRGBQuad statt PRGBTriple in diesem Fall.

Ok Danke!
Der Unterschied ist gleich 0 egal 24 oder 32Bit bleibt gleich.

gruss

[Medium]

Ich glaube dann brauchen wir noch Mal ein Stückchen Code.

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1335329)

Ich glaube dann brauchen wir noch Mal ein Stückchen Code.

Wie meinst das?
Ich habe lediglich pf24Bit mit pf32Bit ersetzt und PRGBQuad statt PRGBTriple implementiert.
Das Ergebnis ist bei beiden Versionen gleich.

Lässt sich mit deiner Laufzeit Überprüfung sehr gut Nachvollziehen :)
+- 2 > 3 ms das ist aber nicht der Rede wert.
Ein umbau deshalb nicht nötig.

gruss

[Medium]

Achsooo! Hab das so verstanden, als würde auch mit dem anderen Pointer-Typ nur graue Suppe raus kommen :) Dann alles gut, bitte weiter gehen. Hier gibt es nichts zu sehen. :stupid:

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1335336)

Achsooo! Hab das so verstanden, als würde auch mit dem anderen Pointer-Typ nur graue Suppe raus kommen :) Dann alles gut, bitte weiter gehen. Hier gibt es nichts zu sehen. :stupid:

Klar gibt es was zu sehen.
Bisher die schnellste ScanLine function..

Siehe Shot! (Ist ja nicht so als wenn wir nichts hätten):stupid:
1 viertel der gesamten Spielzeit was für eine Leistung.

gruss

[Medium]

Ich habe jetzt mal ein knapp 5min langes Lied genommen, und komme bei pf32Bit auf 11s Gesamt und 4,5s davon zum Zeichnen. Irgendwie ist bei dir etwas anders.

Was mir auch auffiel: Bei einem 5min Lied wird das Bitmap schon über üppige 25000 Pixel breit, was von der Anzahl her 4 Megapixel sind. Bei 16min Liedern werden das schon gut 12MP, und das Bitmap >75000 Pixel breit. Da ist irgendwann bald mal Ende. Mich wundert, dass die GDI überhaupt bei einem Bitmap mit einer Kante über 64k mit macht - irgendwo habe ich mal gelesen, dass da eine Grenze sei.
Wenn da jetzt jemand eine mp3 mit 1h Laufzeit nimmt, wirds eventuell ungemütlich, und auch der Speicher eng. Da du aber immer nur eine "Seite" in der Scrollbox anzeigst, wäre es ultimativ wohl besser, wenn du immer nur die eine "Seite" zeichnen würdest, die jetzt gerade angezeigt wird. Das wäre dann so ein Zwischending zwischen vorab und live zeichnen, sieht aber nachher genau so aus wie vorab. (Du musst nur berechnen, wie viel angezeigte Breite in deinem mp3 sind. Aber das sollte mit den Mitteln gehen, mit denen du jetzt schon die Zeitleiste machst.)

[EWeiss]

Zitat:

Irgendwie ist bei dir etwas anders

.
Ja weil ich Move für jede Zeile verwende in Verbindung mit Paletten.

Zitat:

wenn du immer nur die eine "Seite" zeichnen würdest, die jetzt gerade angezeigt wird. Das wäre dann so ein Zwischending zwischen vorab und live zeichnen

Schon richtig, wenn jemand ein Spektrogram braucht kann er das ja machen wie er möchte.
Mir ging es in erster Linie erst mal um die Optimierung, einlesen der Pixel.

Man könnte auch blockweise einlesen und den Kram zusammenschrumpfen so das der gesamte Stream auf einer Seite sichtbar ist.
So wie Audacity das macht aber genau das wollte ich ebenfalls nicht weil man dann die Visualisierung des Spectrum nicht 1 zu 1 sieht.

gruss

[EWeiss]

Hier noch ne Änderung welche die CPU Auslastung auf 0 senkt.

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
const
  DrawTLWidth = 25;
var
  XPos: Integer;
begin

  if bpp = 0 then
    Exit;

  XPos:= Bass_ChannelGetPosition(Channel, BASS_POS_BYTE);
  BitBlt(Bitmap.Canvas.handle, 0, 0, (XPos div integer(bpp)) + DrawTLWidth, PB.Height, DestBitmap.Canvas.handle, 0, 0, SrcCopy);

  DrawTime_Line(XPos, 0, TColor($FFFFFF));
  PB.Refresh;

end;

Das komplette Bitmap wegen einer Linie immer wieder neu zu zeichnen ist nicht gerade die optimale Lösung.
Deshalb habe ich es auf die aktuelle Position inklusive des Zeichnen des Textes beschränkt.
Hätte den Profis auffallen müssen ;)

gruss

[EWeiss]

ops.. Naja nun sind die 100 voll! :mrgreen:

gruss

[Medium]

Profis würden für sowas nie einen Timer nehmen (und gucken da nichtmal hin) :P


Aber läuft ja prima jetzt!

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1335406)

Profis würden für sowas nie einen Timer nehmen (und gucken da nichtmal hin) :P


Aber läuft ja prima jetzt!

Also dafür einen Thread zu verwenden war mir dann doch zu viel Spielerei. ;)

gruss

[Medium]

Auch das nicht. Ein Callback wäre ideal, und Bass scheint sowas anzubieten. Aber das sind i-Tüpfelchen jetzt.

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1335410)

Auch das nicht. Ein Callback wäre ideal, und Bass scheint sowas anzubieten. Aber das sind i-Tüpfelchen jetzt.

Ja in dem Fall muss ich dir recht geben ;)

gruss

[HeZa]

Hallo,

ich habe jetzt nicht alle Einträge zu diesem Thread gelesen, von daher mag mir etwas entgangen sein und erschwerend kommt vielleicht noch hinzu das ich keine großen Erfahrungen mit Bitmap-Manipulationen habe, aber ich finde der Hinweis von Uwe ist nicht ausreichend gewürdigt worden:

Zitat:

Zitat von Uwe Raabe (Beitrag 1335093)

In deinem Fall kann Scanline seinen eigentlichen Vorteil gar nicht richtig ausspielen. Mit ScanLine kann man sehr schnell eine ganze Zeile des Bitmaps bearbeiten. Dein Code arbeitet aber spaltenorientiert, weswegen du immer nur ein Pixel der jeweiligen Scanline änderst und beim nächsten Aufruf bereits eine andere Scanline brauchst.

Wenn Performance über alles geht, mach es nach diesem Hinweis nicht Sinn, die Bitmap um 90 Grad gedreht zu erzeugen, um die volle Leistungsfähigkeit von Scanline auszunutzen, um sie dann als Ganzes oder in Stücken um -90 Grad gedreht anzuzeigen?

[EWeiss]

Zitat:

Zitat von HeZa (Beitrag 1335418)

Hallo,

ich habe jetzt nicht alle Einträge zu diesem Thread gelesen, von daher mag mir etwas entgangen sein und erschwerend kommt vielleicht noch hinzu das ich keine großen Erfahrungen mit Bitmap-Manipulationen habe, aber ich finde der Hinweis von Uwe ist nicht ausreichend gewürdigt worden:

Zitat:

Zitat von Uwe Raabe (Beitrag 1335093)

In deinem Fall kann Scanline seinen eigentlichen Vorteil gar nicht richtig ausspielen. Mit ScanLine kann man sehr schnell eine ganze Zeile des Bitmaps bearbeiten. Dein Code arbeitet aber spaltenorientiert, weswegen du immer nur ein Pixel der jeweiligen Scanline änderst und beim nächsten Aufruf bereits eine andere Scanline brauchst.

Wenn Performance über alles geht, mach es nach diesem Hinweis nicht Sinn, die Bitmap um 90 Grad gedreht zu erzeugen, um die volle Leistungsfähigkeit von Scanline auszunutzen, um sie dann als Ganzes oder in Stücken um -90 Grad gedreht anzuzeigen?

Nein weil jede einzelne Zeile (Spalte) direkt gerendert wird.
Das ist nicht der Fall wenn ich das Bitmap vorher drehe.
Ich würde es erst dann sehen wenn es fertig befüllt ist.

In dem Fall muss ich leider etwas von der Performance wegnehmen Visualisierungs bedingt.

gruss