![]() |
AW: Optimierung von Pixel
Du musst auch dann natürlich deine Pointertypen anpassen ;) PRGBQuad statt PRGBTriple in diesem Fall.
|
AW: Optimierung von Pixel
Zitat:
Der Unterschied ist gleich 0 egal 24 oder 32Bit bleibt gleich. gruss |
AW: Optimierung von Pixel
Ich glaube dann brauchen wir noch Mal ein Stückchen Code.
|
AW: Optimierung von Pixel
Zitat:
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 |
AW: Optimierung von Pixel
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:
|
AW: Optimierung von Pixel
Zitat:
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 |
AW: Optimierung von Pixel
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.) |
AW: Optimierung von Pixel
Zitat:
Ja weil ich Move für jede Zeile verwende in Verbindung mit Paletten. Zitat:
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 |
AW: Optimierung von Pixel
Hier noch ne Änderung welche die CPU Auslastung auf 0 senkt.
Delphi-Quellcode:
Das komplette Bitmap wegen einer Linie immer wieder neu zu zeichnen ist nicht gerade die optimale Lösung.
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; Deshalb habe ich es auf die aktuelle Position inklusive des Zeichnen des Textes beschränkt. Hätte den Profis auffallen müssen ;) gruss |
AW: Optimierung von Pixel
ops.. Naja nun sind die 100 voll! :mrgreen:
gruss |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz