Optimierung von Pixel

[Medium]

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

[EWeiss]

Zitat von Medium:

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 von Medium:

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.

[EWeiss]

Zitat von 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.

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

Siehe Shot! (Ist ja nicht so als wenn wir nichts hätten)
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!

gruss