Optimierung von Pixel

[EWeiss]

Jemand ne Idee wie ich das beschleunigen kann?

Delphi-Quellcode:

Image1.Picture.Bitmap.Canvas.Pixels[ColumnCounter, BUFFER_SIZE - i] := HSLtoRGB(H, S, L);

Bei einer Bitmap weite von 17507 kann das ganz schön lange dauern bis ich da durch bin.

gruss

[CHackbart]

Probier mal Scanline, oder noch besser: Erstelle einen eigenen Pixelbuffer: Breite x Höhe * 4 und zeichne das erst dort rein und kopiere es dann in das Image.

[EWeiss]

Zitat:

Zitat von CHackbart (Beitrag 1334944)

Probier mal Scanline, oder noch besser: Erstelle einen eigenen Pixelbuffer: Breite x Höhe * 4 und zeichne das erst dort rein und kopiere es dann in das Image.

Kleine Anregung wie meinst das mit Pixelbuffer?
In wie weit ist das schneller.
Bei einer Mp3 18sec benötige ich gut 5sec um den Stream einzulesen.

Mit Pixel wohlbemerkt.

gruss

[Zacherl]

Delphi-Quellcode:

Canvas.Pixel

macht bei JEDEM Aufruf einen API Call. Reine Schätzung, aber

Delphi-Quellcode:

Canvas.ScanLine

ist locker um den Faktor 1000 schneller (eher mehr). Dort schreibst du die Daten praktisch direkt in den internen Bitmapspeicher.

Einen Pixelbuffer brauchst du meiner Meinung nach nicht. Nichts anderes liefert

Delphi-Quellcode:

Canvas.ScanLine

doch: Einen Zeiger auf den Pixelbuffer des Bitmaps.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1334947)

Delphi-Quellcode:

Canvas.Pixel

macht bei JEDEM Aufruf einen API Call. Reine Schätzung, aber

Delphi-Quellcode:

Canvas.ScanLine

ist locker um den Faktor 1000 schneller (eher mehr). Dort schreibst du die Daten praktisch direkt in den internen Bitmapspeicher.

Einen Pixelbuffer brauchst du meiner Meinung nach nicht. Nichts anderes liefert

Delphi-Quellcode:

Canvas.ScanLine

doch: Einen Zeiger auf den Pixelbuffer des Bitmaps.

Werde mich mal schlau machen wie ich das umsetzen kann ;)

Danke.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1334948)

Werde mich mal schlau machen wie ich das umsetzen kann ;)

Prinzipiell wie mit

Delphi-Quellcode:

Pixels

, nur dass du jetzt jeweils eine Zeile des Bitmaps direkt füllen kannst (eventuell würde es sogar gehen mit dem Pointer der 1. Zeile sämtliche Daten zu schreiben, aber da Bitmapdaten auch nicht-durchgehend sein können [Strides], würde ich das vermutlich nicht riskieren).

Achten musst du nur auf die Anzahl der Bits pro Pixel. Meistens ist das in Delphi benutze Format

Delphi-Quellcode:

pf24Bit

. Das bedeutet, dass du pro Pixel ein R, G und B Byte hast. Bei

Delphi-Quellcode:

pf32Bit

kommt noch ein Alpha-Byte hinzu und alles unter

Delphi-Quellcode:

pf24Bit

wird kompliziert, da du dann mit Bits rechnen musst (wirst du aber vermutlich nicht brauchen).

Achso. Die Reihenfolge der Farben war nicht RGB, soweit ich mich erinnere. Da bin ich schon öfters drauf reingefallen, aber leider habe ich die korrekte Reihenfolge trotzdem schon wieder vergessen :-D :stupid:

[EWeiss]

scheint wieder nicht so einfach zu sein .. ;)
Na wird schon irgend wie .. LOL

Scanline gibt ja die Farbe zurück
Ich muss sie aber zuweisen

Hmm bin mir jetzt nicht klar darüber wie ich

Delphi-Quellcode:

HSLtoRGB(H, S, L);

Scanline zuweisen soll.

Delphi-Quellcode:

  Value := SQRT(SQRT(Buffer[i]));
  H := 0 + Value / 1.5;
  L := Value;

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1334951)

Scanline gibt ja die Farbe zurück
Ich muss sie aber zuweisen

Du kannst beides damit machen:

Delphi-Quellcode:

var
  B: TBitmap;
  X, Y: Integer;
  P: PByte;
begin
  B := TBitmap.Create;
  try
    B.PixelFormat := pf24Bit;
    B.Width := 200;
    B.Height := 200;
    for Y := 0 to B.Height - 1 do
    begin
      P := B.ScanLine[Y];
      for X := 0 to B.Width - 1 do
      begin
        P^ := 0;   Inc(P);
        P^ := 255; Inc(P);
        P^ := 0;   Inc(P);
      end;
    end;
    Canvas.Draw(0, 0, B);
  finally
    B.Free;
  end;
end;

Das füllt dein Bitmap in der Farbe rot.

Statt mit

Delphi-Quellcode:

PByte

zu arbeiten, kannst du auch

Delphi-Quellcode:

PDWord

verwenden (der Speicher sollte eh aligned sein, weshalb du auch beim letzten Pixel mit dem

Delphi-Quellcode:

pf24Bit

Format kein invalid-read bekommen solltest) und dann die einzelnen Farbwerte per Bitshifts reinpacken:

Delphi-Quellcode:

var
  B: TBitmap;
  X, Y: Integer;
  P: PDWord;
begin
  B := TBitmap.Create;
  try
    B.PixelFormat := pf24Bit;
    B.Width := 200;
    B.Height := 200;
    for Y := 0 to B.Height - 1 do
    begin
      P := B.ScanLine[Y];
      for X := 0 to B.Width - 1 do
      begin
        P^ := (0 shl 8) or (255 shl 16) or (0 shl 24);
        P := PDWord(PByte(P) + 3); // 3 byte per pixel for pf24Bit
      end;
    end;
    Canvas.Draw(0, 0, B);
  finally
    B.Free;
  end;
end;

[Uwe Raabe]

Guckst du hier: http://docwiki.embarcadero.com/CodeE...nLine_(Delphi)

[Neutral General]

Noch ein Hinweis:
Pixelformat auf 32-Bit stellen und P nicht als PByte definieren sondern als PRGBQuad.
Das ist ein Pointer auf ein Record mit den RGBA werten. Da musst du dir keine Gedanken über die Reihenfolge machen. Und mit einem inc(P) bist du dann auch automatisch direkt 1 Pixel weiter.

[CHackbart]

Grob auf dem Tablet zusammengezimmert würde das so aussehen:

Delphi-Quellcode:

Var buf: PDWord;
 I, x: integer;
Begin
 For i := 0 to bmp.height - 1 do
 Begin
  Buf := bmp.scanline[i];
  For x := 0 to bmp.width - 1 do
   Begin
      Buf^ := $FF000000 or HLSToRGB(...);
      Inc(buf);
   End;
 End;

[Zacherl]

Zitat:

Zitat von Neutral General (Beitrag 1334954)

Pixelformat auf 32-Bit stellen und P nicht als PByte definieren sondern als PRGBQuad.
Das ist ein Pointer auf ein Record mit den RGBA werten. Da musst du dir keine Gedanken über die Reihenfolge machen. Und mit einem inc(P) bist du dann auch automatisch direkt 1 Pixel weiter.

Exzellenter Hinweis, wenn man die Wahl hat auf

Delphi-Quellcode:

pf32Bit

zu stellen. Ansonsten siehe meinen editierten Post.

Zitat:

Zitat von CHackbart (Beitrag 1334955)

Grob auf dem Tablet zusammengezimmert würde das so aussehen

Auch nur bei

Delphi-Quellcode:

pf32Bit

! Dann sollte man auch auf jeden Fall Neutral Generals Hinweis beachten. Dadurch wird der Code deutlich verständlicher. Und wie gesagt, sind die RGB Werte nicht in der korrekten Reihenfolge.

Delphi-Quellcode:

HLSToRGB

müsste bei deinem Ansatz deshalb entsprechend angepasst werden.

[EWeiss]

Danke werde mir das mal alles zu gemüte führen

Hab das früher mit GetDiBits gemacht aber man glaubt es nicht ist auch nicht schneller als Scanline. (Hmm.. oder doch nicht)
http://ksymeon.blogspot.de/2010/02/g...pixels-in.html

Hier mal noch etwas code wie ich die Daten fülle.

Delphi-Quellcode:

    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;

            Image1.Picture.Bitmap.Canvas.Pixels[ColumnCounter, BUFFER_SIZE - i] := HSLtoRGB(H, S, L);
        end;
        Inc(ColumnCounter);
        Progress := Trunc(100 * (BASS_ChannelGetPosition(Channel, BASS_POS_BYTE) / BASS_ChannelGetLength(Channel, BASS_POS_BYTE)));
        Form2.ProgressBar1.Position := Progress;
        Application.ProcessMessages;
    end;

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1334957)

Hab das früher mit GetDiBits gemacht

Die API kopiert ja soweit ich weiß auch nur den Inhalt des Bitmaps und du benötigst dann SetDIBits zum Ändern. Bei der ScanLine Methode arbeitest du direkt mit dem internen Speicher. Ohne Kopieren und ohne zusäzliche API Aufrufe. Die Performance sollte deshalb noch deutlich höher sein.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1334959)

Zitat:

Zitat von EWeiss (Beitrag 1334957)

Hab das früher mit GetDiBits gemacht

Die API kopiert ja soweit ich weiß auch nur den Inhalt des Bitmaps und du benötigst dann SetDIBits zum Ändern. Bei der ScanLine Methode arbeitest du direkt mit dem internen Speicher. Ohne Kopieren und ohne zusäzliche API Aufrufe. Die Performance sollte deshalb noch deutlich höher sein.

Danke für eure Hinweise werde mir das mal zurecht schrauben :)

gruss

[EWeiss]

Hier was zum spielen.
Aber wie gesagt mit Pixel eine Qual..

Anhang gelöscht..

gruss

[Rollo62]

Graphics32 ?

[Neutral General]

Zitat:

Zitat von Zacherl (Beitrag 1334956)

Exzellenter Hinweis, wenn man die Wahl hat auf

Delphi-Quellcode:

pf32Bit

zu stellen. Ansonsten siehe meinen editierten Post.

Es gibt auch PRGBTriple für 24-Bit ;)

[Medium]

Unter sehr leichtem Performaceverlust lässt sich Scanline auch ähnlich wie Pixels verwenden, wenn man sich eine kleine Helferprozedur bastelt.

Delphi-Quellcode:

procedure SetPixel(aBitmap: TBitmap; aX, aY: Integer; aColor: TColor);
var
  P: PRGBTriple;
begin
  if aBitmap.Pixelformat <> pf24Bit then
    raise Exception.Create('Bitmap hat falsches Pixelformat (nicht 24-Bit).');
  if (aX < 0) or (aX > aBitmap.Width) then
    raise Exception.Create('X-Koordinate liegt außerhalb des Bitmaps.');
  if (aY < 0) or (aY > aBitmap.Width) then
    raise Exception.Create('Y-Koordinate liegt außerhalb des Bitmaps.');
  P := aBitmap.Scanline[aY];
  Inc(P, aX);
  P^.R := GetRValue(aColor);
  P^.G := GetGValue(aColor);
  P^.B := GetBValue(aColor);
end;

Aufruf dann so:

Delphi-Quellcode:

    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;

            SetPixel(Image1.Picture.Bitmap, ColumnCounter, BUFFER_SIZE - i, HSLtoRGB(H, S, L));
        end;
        Inc(ColumnCounter);
        Progress := Trunc(100 * (BASS_ChannelGetPosition(Channel, BASS_POS_BYTE) / BASS_ChannelGetLength(Channel, BASS_POS_BYTE)));
        Form2.ProgressBar1.Position := Progress;
        Application.ProcessMessages;
    end;

Wenn man es direkt in seine Schleife baut, lässt sich halt das immer wieder erneute Abholen der Scanline vermeiden (zumindest innerhalb einer Zeile, und wenn man den Stride selber behandelt auch generell), und die Prüfungen fallen nur ein Mal an. Aber das hier düfrte dennoch etliche hundert Mal schneller als Pixels[] sein, bzw. kaum merklich langsamer als ohne die Krücken-Prozedur SetPixel().

Es kann sein, dass das Bild dann auf dem Kopf steht. Windows speichert Bitmaps nämlich auf dem Kopf, wenn ich mich nicht irre. Um das zu beheben müsste nur die Zeile

Delphi-Quellcode:

P := aBitmap.Scanline[aY];

zu

Delphi-Quellcode:

P := aBitmap.Scanline[aBitmap.Height-aY-1];

geändert werden.

[EWeiss]

Danke für deine Mühe.
Mit ein paar kleinen Änderungen funktioniert es ganz gut.

BUFFER_SIZE von 160 um 1 decrementiert.
Habe nun aber eine andere Farbe denke das liegt an pf24Bit.

Zitat:

Es kann sein, dass das Bild dann auf dem Kopf steht.

Nein ist Ok..

gruss

[EWeiss]

Zitat:

Reine Schätzung, aber Canvas.ScanLine ist locker um den Faktor 1000 schneller (eher mehr).

Ist es möglich das ScanLine etwas oder sehr überschätzt wird.
Kann nicht wirklich eine verbesserte Geschwindigkeit feststellen.

Das analysieren einer MP3 "Pink Floyd - Echoes"

1. Zeit: 00:16:30
2. Größe: 37 MB
3. Frequenz: 44k1
4. Bitrate: 320k

ScanLine: 109138 ticks
Pixel: 109404 ticks

Also um beim Faktor 1000 mal schneller zu bleiben
sollte ScanLine eigentlich 109.138 Ticks betragen

Also irgendwie :(

gruss

[Valle]

Welche der genannten Methoden hast du denn für deine Messung verwendet?

Ich bin mir sicher dass man das noch verbessern kann, aber dafür müssten wir hier wohl mehr Details kennen.

Auch wundere ich mich etwas, ob die Methode von Medium wirklich funktioniert. Damit hat man ja einen ScanLine-Aufruf pro Pixel. Ich weiß nicht genau was ScanLine im Hintergrund macht, aber ich wäre davon ausgegangen, dass genau der Wegfall dieser vielen Aufrufe einen Großteil des Performancegewinn ausmacht. :gruebel:

[Zacherl]

Mediums Funktion ist sogar LANGSAMER als

Delphi-Quellcode:

Canvas.Pixels

:lol: Mein Testcode

Delphi-Quellcode:

var
  B: TBitmap;
  X, Y: Integer;
  P: PRGBTriple;
  C: Cardinal;
begin
  B := TBitmap.Create;
  try
    B.PixelFormat := pf24Bit;
    B.Width := 2000;
    B.Height := 2000;
    // Canvas.Pixels
    C := GetTickCount;
    for Y := 0 to B.Height - 1 do
    begin
      for X := 0 to B.Width - 1 do
      begin
        B.Canvas.Pixels[X, Y] := clRed;
      end;
    end;
    ShowMessage(IntToStr(GetTickCount - C));   // 1141ms
    // Custom SetPixel method by Medium
    C := GetTickCount;
    for Y := 0 to B.Height - 1 do
    begin
      for X := 0 to B.Width - 1 do
      begin
        SetPixel(B, X, Y, clRed);
      end;
    end;
    ShowMessage(IntToStr(GetTickCount - C));   // 1391ms
    // Bitmap.ScanLine
    C := GetTickCount;
    for Y := 0 to B.Height - 1 do
    begin
      P := B.ScanLine[Y];
      for X := 0 to B.Width - 1 do
      begin
        P^.rgbtRed   := 255;
        P^.rgbtGreen := 0;
        P^.rgbtBlue  := 0;
        Inc(P);
      end;
    end;
    ShowMessage(IntToStr(GetTickCount - C));  //    15ms
  finally
    B.Free;
  end;
end;

produziert folgendes Ergebnis:

Code:

1141ms - Canvas.Pixels
1391ms - SetPixel by Medium
  15ms - ScanLine

[stahli]

@Emil

Bei Performanceproblemen hat mit AQTime Pro schon gut geholfen.
Da kann man sogar einzelne Zeilen messen lassen.

Nur man sollte es nicht in die Delphi-IDE Einbinden, sondern extern nutzen.

[EWeiss]

Zitat:

Zitat von stahli (Beitrag 1335033)

@Emil

Bei Performanceproblemen hat mit AQTime Pro schon gut geholfen.
Da kann man sogar einzelne Zeilen messen lassen.

Nur man sollte es nicht in die Delphi-IDE Einbinden, sondern extern nutzen.

Danke für die Info :)
Aber eigentlich sollte doch GetTickCount ausreichend sein

Zitat:

Mein Testcode

Danke werde deine Variante mal testen.

gruss

[Medium]

Canvas.Pixels[] ruft intern die WinAPI Funktion SetPixel auf. Scanline macht zwar auch einen API Call (GDIFlush), aber dennoch ist es erheblich schneller als SetPixel. Klar, der "saubere" Weg wäre es mit nur einem Mal Scanline abrufen und ab dann nur noch den Pointer inkrementieren. Aber dennoch sollte der Unterschied sehr deutlich ausfallen.

Misst du eventuell das Berechnen der FFT mit? Weil das dürfte bei so einem langen Stück selbst mit den diversen optimierten FFTs recht lange dauern.

Ansonsten mal so probieren:

Delphi-Quellcode:

var
  b: TBitmap; // Pufferbitmap um horizontal zeichnen zu können
  p0, p: PRGBTriple;
  c: TColor;
  points: array[0..2] of TPoint;
begin
  b := TBitmap.Create;
  b.PixelFormat := pf24Bit;
  b.SetSize(BUFFER_SIZE, 1);
  p0 := b.Scanline[0];
...
    while BASS_ChannelIsActive(Channel) <> BASS_ACTIVE_STOPPED do begin
        BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512);
        p := p0;
        for i := 0 to BUFFER_SIZE - 1 do begin
            Value := SQRT(SQRT(Buffer[i]));
            H := 0 + Value / 1.5;
            L := Value;
            c := HSLtoRGB(H, S, L);

            p^.rgbtRed := GetRValue(c);
            p^.rgbtGreen := GetGValue(c);
            p^.rgbtBlue := GetBValue(c);
            Inc(p);
        end;
        points[0] := Point(ColumnCounter+1, 0);
        points[1] := Point(ColumnCounter+1, BUFFER_SIZE-1);
        points[2] := Point(ColumnCounter, 0);
        PlgBlt(Image1.Picture.Bitmap.Canvas.Handle, points, b.Canvas.Handle, 0, 0, b.Width, b.Height, 0, 0, 0); // b gedreht an die richtige x-Position auf das Image malen
        Inc(ColumnCounter);
        Progress := Trunc(100 * (BASS_ChannelGetPosition(Channel, BASS_POS_BYTE) / BASS_ChannelGetLength(Channel, BASS_POS_BYTE)));
        Form2.ProgressBar1.Position := Progress;
        Application.ProcessMessages;
    end;
...
  b.Free;

Nicht ganz getestet, aber zumindest die Punkte sollten so passen. ich weiss jetzt nicht, ob die Nutzung von PlgBlt schneller ist, oder alternativ das immer wieder neue Abholen der Scanline, aber einen Versuch ist es wert. (Da du ja progressiv immer spaltenweise zeichnest, müsste man eh die Scanline immer neu holen (oder den Stride selber behandeln).)

[Medium]

Roter Kasten:

Zitat:

Zitat von Zacherl (Beitrag 1335025)

Mediums Funktion ist sogar LANGSAMER als

Delphi-Quellcode:

Canvas.Pixels

Das wundert mich ehrlich gesagt, aber da ich keine konkreten Tests gemacht habe, nehme ich das mal so hin :)

[Zacherl]

Zitat:

Zitat von Medium (Beitrag 1335041)

Roter Kasten:

Zitat:

Zitat von Zacherl (Beitrag 1335025)

Mediums Funktion ist sogar LANGSAMER als

Delphi-Quellcode:

Canvas.Pixels

Das wundert mich ehrlich gesagt, aber da ich keine konkreten Tests gemacht habe, nehme ich das mal so hin :)

Hat mich selbst stark gewundert, weil der erste Aufruf von

Delphi-Quellcode:

ScanLine

den Bitmap-Buffer eigentlich cached. Allerdings werden da neben dem Anfordern des Buffers noch 100 andere Sachen in der Funktion gemacht, die ich mir jetzt nicht genauer angeschaut habe. Diese Funktionen werden wohl der Grund für den Performanceverlust sein.

[Valle]

Man könnte ja mal spaßeshalber eine Art Zwischenspeicher für das Ergebnis von ScanLine einführen.

Code:

if aY != old_aY:
    old_aY = aY
    scanlineResult = ScanLine(..., aY)
// mit scanlineResult weiter verfahren

[EWeiss]

Ich habe jetzt alle Varianten durch und lade das Projekt mal hoch. (Anhang gelöscht neue auf der nächsten Seite)

Seltsamer weise tut die Funktion von Zacherl nicht was sie soll.. Oder ich war zu blöd diese einzubinden.
Die neue von Medium liefert auch nicht das richtige Zeichnungs Resultat.

wäre schön wenn ihr das mal testen würdet.
alte Version ohne Änderung.

wundert mich schon warum der Kram so lange dauert bei analysieren.
Was nicht geht ist das auf die nächste Seite gesprungen wird.

PS:
Nicht wundern!
00:00:00 = Min,Sec,Ms

gruss

[Zacherl]

Delphi-Quellcode:

PB.Refresh

verbraucht fast deine ganze CPU Zeit.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1335050)

Delphi-Quellcode:

PB.Refresh

verbraucht fast deine ganze CPU Zeit.

Ist richtig deshalb dauert es auch so lange..
Habe es deaktiviert. Auch wenn es schöner wäre die Fortschritte des ladens zu sehen.

Auf der anderen Seite hat es keinen Einfluss darauf ob ScanLine schneller als Pixel ist.
Macht bei mir nach dem deaktivieren von PB.Refresh gerade mal eine Sekunde aus.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1335051)

Habe es deaktiviert. Auch wenn es schöner wäre die Fortschritte des ladens zu sehen.

Habe es bei mir zum Testen ebenfalls auskommentiert. Das

Delphi-Quellcode:

Application.ProcessMessages

auch. Trotzdem sehe ich den Fortschritt .. ist das bei dir nicht der Fall?

Zitat:

Zitat von EWeiss (Beitrag 1335051)

Auf der anderen Seite hat es keinen Einfluss darauf ob ScanLine schneller als Pixel ist.
Macht bei mir nach dem deaktivieren von PB.Refresh gerade mal eine Sekunde aus.

Der Vorteil skaliert halt stark mit der Größe des Bitmaps. Würde auf jeden Fall trotzdem ScanLine benutzen.

[EWeiss]

Zitat:

Trotzdem sehe ich den Fortschritt .. ist das bei dir nicht der Fall?

Nein beim Analysieren der Daten wird kein Paintevent ausgelößt.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1335054)

Zitat:

Trotzdem sehe ich den Fortschritt .. ist das bei dir nicht der Fall?

Nein beim Analysieren der Daten wird kein Paintevent ausgelößt.

Bei meiner Delphi Version schon. Als Workaround könntest du das Refreshen immer nur dann ausführen, wenn sich wirklich der Progress geändert hat im Vergleich zum vorherigen Durchgang des Loops. Das wären dann maximal 100 Aufrufe im ganzen Loop.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1335057)

Zitat:

Zitat von EWeiss (Beitrag 1335054)

Zitat:

Trotzdem sehe ich den Fortschritt .. ist das bei dir nicht der Fall?

Nein beim Analysieren der Daten wird kein Paintevent ausgelößt.

Bei meiner Delphi Version schon. Als Workaround könntest du das Refreshen immer nur dann ausführen, wenn sich wirklich der Progress geändert hat im Vergleich zum vorherigen Durchgang des Loops. Das wären dann maximal 100 Aufrufe im ganzen Loop.

Jup. :)
Wäre eine Möglichkeit.

Ist deine Funktion jetzt schneller oder gibt es keine Unterschiede?

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1335058)

Zitat:

Zitat von Zacherl (Beitrag 1335057)

Zitat:

Zitat von EWeiss (Beitrag 1335054)

Zitat:

Trotzdem sehe ich den Fortschritt .. ist das bei dir nicht der Fall?

Nein beim Analysieren der Daten wird kein Paintevent ausgelößt.

Bei meiner Delphi Version schon. Als Workaround könntest du das Refreshen immer nur dann ausführen, wenn sich wirklich der Progress geändert hat im Vergleich zum vorherigen Durchgang des Loops. Das wären dann maximal 100 Aufrufe im ganzen Loop.

Jup. :)
Wäre eine Möglichkeit.

Das bringt dir schonmal ne ganze Menge Performance:

Delphi-Quellcode:

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;
  Application.ProcessMessages;
end;

Zitat:

Zitat von EWeiss (Beitrag 1335058)

Ist deine Funktion jetzt schneller oder gibt es keine Unterschiede?

Auskommentieren des SetPixel / Canvas.Pixel Codes beschleunigt die Analyse nochmal deutlich spürbar. Meine Funktion würde den selben Effekt haben, allerdings habe ich das noch nicht getestet.

[EWeiss]

Zitat:

Das bringt dir schonmal ne ganze Menge Performance:

Führ wahr, ganze 10 Sekunden und das ist schon mal eine spürbare Verbesserung.

Hat jetzt nicht direkt mit den Pixeln zu tun!
Was mich jetzt noch fuchst das ich die Seiten nicht umschalten kann ohne dass das Bitmap anfängt zu scrollen.
Also wenn die Linie das ende der Scrollbox erreicht hat.

Danke das du dir das Anschaust. ;)
Anbei ne neue Version mit deiner Änderung der Progressbar

gruss

[Medium]

Zitat:

Zitat von EWeiss (Beitrag 1335047)

Die neue von Medium liefert auch nicht das richtige Zeichnungs Resultat.

Leider bleibt "Channel" bei mir immer 0, daher kann ich nicht selbst testen. Inwiefern ist das Ergebnis falsch? (Ich frage aus persönlichem Interesse, nicht weil ich dir nicht glaube :))
Ist es trotz falsch dennoch flotter?

[Zacherl]

Zitat:

Zitat von Medium (Beitrag 1335064)

Zitat:

Zitat von EWeiss (Beitrag 1335047)

Die neue von Medium liefert auch nicht das richtige Zeichnungs Resultat.

Leider bleibt "Channel" bei mir immer 0, daher kann ich nicht selbst testen. Inwiefern ist das Ergebnis falsch? (Ich frage aus persönlichem Interesse, nicht weil ich dir nicht glaube :))
Ist es trotz falsch dennoch flotter?

Die Farben sind irgendwie anders. Aber das Problem liegt nicht zwingend in deinem Code :lol: Es gibt diverse Buffer Overflows in der Analyse Funktion, die das wohl verursachen werden. BASS_ChannelGetData mit BASS_DATA_FFT512 liefert nämlich 256 Float Values, aber das Buffer Array ist nur für 159 Floats Platz hat. Deshalb sieht die grafische Darstellung generell schon irgendwie gestaucht / falsch aus.