Optimierung von Pixel

[EWeiss]

Zitat:

Oder den Buffer zwar so groß machen wie ihn die Bass.dll befüllt, aber weniger daraus lesen.

Das tue ich ja auch
Ich lese ja nur soviel Pixel wie das Bitmap in der Höhe ist
for i := 0 to BUFFER_SIZE - 1 do

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

gruss

[Medium]

Du übergibst deinen zu kurzen Buffer mit BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); in die Obhut der Bass.dll, und sagst ihr: "Hallo Bass.dll, bitte fülle diesen Buffer mit den FFT Daten eines 512 Byte langen Samples.". Die Bass.dll sieht nur einen Pointer auf ein Stück speicher, und glaubt dir blind, dass du genug Speicher für all die Werte die sie nun schreiben will reserviert hast, und legt los alle 512 Werte zu schreiben.
Aber du hattest eigentlich nur 160 Bytes für den Buffer reserviert. Was eventuell hinter deinen 160 Bytes steht, weiss maximal der Speichermanager. Aber weder du noch die Bass.dll wissen das. Es wäre nichts ungewöhnliches, wenn dort z.B. die Daten für einen der Buttons in deinem Programm lägen o.ä., und die Bass.dll würde die dann einfach so ungeprüft übernageln. Was das mit dem Verhalten von dem Button anstellt, ist vermutlich klar.
Dein Lesen ist nicht das Problem.

[Zacherl]

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Hier SetLength(Buffer, BUFFER_SIZE); // Reserviert Speicher für 159x Single/Float und hier BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); // Schreibt 256x Single/Float in den Buffer

[Medium]

Zitat von Zacherl:

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Hier SetLength(Buffer, BUFFER_SIZE); // Reserviert Speicher für 159x Single/Float und hier BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); // Schreibt 256x Single/Float in den Buffer

Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten, aber eigentlich gehören sie dazu. Ich weiss nicht genau wie die Bass.dll das handhabt. Aber 160 Bytes sind definitv zu wenig, egal wie.

[EWeiss]

Zitat von Zacherl:

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Schreibt 256x Single/Float in den Buffer[/DELPHI]

korrekt!

Aber ich verwende davon nur 160 Floats.
Es dürfte doch kein Problem sein aus einem Array nur so viele Einträge zu verwenden wie man sie benötigt
vorausgesetzt ich verwende nicht mehr wie enthalten sind.

wo entsteht bei dieser Konstellation ein Überlauf ?

Zitat:

Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten

Nein


gruss

[Uwe Raabe]

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.

Eventuell kannst du noch etwas Performance herausholen, wenn du die Scanlines cached:

Delphi-Quellcode:

var
  ScanLines: TArray<PRGBTriple>;


  { nach Zuweisung von Bitmap.Height werden die Scanlines im Array mit der ersten Spalte initialisiert }
  SetLength(ScanLines, BitMap.Height);
  for I := 0 to Length(ScanLines) - 1 do begin
    ScanLines[I] := Bitmap.ScanLine[I];
  end;

  { statt SetPixel }
  aColor := HSLtoRGB(H, S, L); // hier könnte man noch etwas herausholen, wenn direkt die RGB-Werte zurückgegeben werden.
  P := ScanLines[BUFFER_SIZE - i];
  P^.rgbtRed := GetRValue(aColor); // dann spart man sich hier wieder das auslesen
  P^.rgbtGreen := GetGValue(aColor);
  P^.rgbtBlue := GetBValue(aColor);

  { nach Inc(ColumnCounter) werden die ScanLine-Pointer um eine Spalte weiter gerückt. }
  for I := 0 to Length(ScanLines) - 1 do begin
    Inc(ScanLines[I]);
  end;

Vorausgesetzt, es gibt eine Prozedur procedure HSLtoRGB(H, S, L: double; out R, G, B: Byte); könnte der relevante Code etwa so aussehen:

Delphi-Quellcode:

  SetLength(ScanLines, BitMap.Height);
  for I := 0 to Length(ScanLines) - 1 do begin
    ScanLines[I] := Bitmap.ScanLine[I];
  end;
  while BASS_ChannelIsActive(Channel) <> BASS_ACTIVE_STOPPED do
  begin
    BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512);
    for i := 0 to BUFFER_SIZE - 1 do
    begin
      Value := SQRT(SQRT(Buffer[i]));
      H := 0 + Value / 1.5;
      L := Value;
      P := ScanLines[BUFFER_SIZE - i];
      HSLtoRGB(H, S, L, P.rgbtRed, P.rgbtGreen, P.rgbtBlue);
    end;
    for I := 0 to Length(ScanLines) - 1 do begin
      Inc(ScanLines[I]);
    end;
    Progress := trunc(100 * (BASS_ChannelGetPosition(Channel, BASS_POS_BYTE) / BASS_ChannelGetLength
          (Channel, BASS_POS_BYTE)));

    if (Form2.ProgressBar1.position <> Progress) then
    begin
      Form2.ProgressBar1.position := Progress;
      PB.Refresh;
    end;
  end;

Wenn nicht schon geschehen, solltest man auch mal die Basiszeit der Analyse ermitteln, die sowieso verbraucht wird ohne in das Bitmap zu schreiben.

[Uwe Raabe]

Übrigens: Der Buffer-Overflow schlägt gnadenlos auf das Scanlines-Array zu. Der Code funktioniert nur, wenn man SetLength(Buffer, 256); verwendet.

[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 von Uwe Raabe:

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 von 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 von Uwe Raabe:

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

[Zacherl]

Zitat von EWeiss:

Aber ich verwende davon nur 160 Floats.
Es dürfte doch kein Problem sein aus einem Array nur so viele Einträge zu verwenden wie man sie benötigt
vorausgesetzt ich verwende nicht mehr wie enthalten sind.

Das ist alles korrekt. Du darfst zu wenig lesen, aber du darfst nicht zu viel lesen und ebenfalls nicht zu viel schreiben. Aber genau das zu viel Schreiben passiert beim BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512) Aufruf.

Zitat von Medium:

Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten, aber eigentlich gehören sie dazu.

Laut Dokumentation werden mit dem FFT512 Parameter 256 Floats geschrieben, also 1024 Bytes.

Nach eine generelle Frage:
Würde es nicht mehr Sinn machen, nur die ersten paar Sekunden zu visualisieren und danach on-demand jeweils die nächsten paar Sekunden ab aktueller Abspielposition?