TBitmap32 in ByteArray (schneller) oder Alternative

[Delphi-Narr]

Also beide Varianten lösen dennoch Fehlermeldungen aus, die direkte Übergabe verändert dabei am Bildschirm rein gar nichts.
Der Pointer lässt ein paar wahllos platzierte Punkte erscheinen.
Die Übergabe des manuell erstellten Bytearrays führt zu einer korrekten Anzeige und einer anschließenden Fehlermeldung.
Ersetze ich das TBitmap32 durch TBitmap und verwende dann die Canvas Funktionen, so funktioniert die Anzeige anschließend ohne Problem und Fehler.

Es funktioniert auch ohne Fehler, wenn ich beim Bitmap32 die Farben über Canvas.Pixels abfrage. Dabei sind dann jedoch Rot und Blau vertauscht (ist ja an sich auch logisch).

So noch eine kleine Änderung, mit

Delphi-Quellcode:

P:=VirtualBitmap.Bits;
   for I := 0 to 320*240-1 do
    begin
      color:=WinColor(P[i]);
      R:=color and $FF;
      G:=(Color shr 8) and $FF;
      B:=(Color shr 16) and $FF;
      Pic2[I*4]:=R;
      Pic2[I*4+1]:=G;
      Pic2[I*4+2]:=B;
      Pic2[I*4+3]:=255;
    end;

klappt es eigentlich ganz gut, CPU Last ist jedoch immer noch bei 7%.

[Der schöne Günther]

Ich komme nicht ganz hinterher.

1) TByteArray
Das ist doch einfach nur type TByteArray = array [0..32767] of Byte; . Ich habe in Delphi (aus Zeitgründen) nach wie vor gewaltige Lücken, aber Delphi hat doch für Arrays wie für Strings bsp. Referenzzählung? Wer weiß, was da noch alles drinsteckt was die DLL eigentlich nicht brauchen kann und dementsprechend durcheinanderkommt. Ich verstehe das Schlüsselwort packed noch nicht wirklich, vielleicht kann das helfen?

2) Geschwindigkeit
Die CPU-Auslastung ist wirklich extrem hoch, ohne wirklich Ahnung zu haben würde ich die benutzten Delphi-Routinen bzgl. Farben beschuldigen. Kannst du mittels FillChar oder ähnlichem einfach das Bild immer Schwarz/Weiß flackern lassen? Hast du mal versucht mit einer TStopWatch zu messen, welche Aufrufe hier so lange brauchen?

[Delphi-Narr]

Also das von mir definierte ByteArray hat keine feste Größe, sondern kann dynamisch verändert werden.
Mit diesem Array aus Bytes kommt die DLL inzwischen auch wunderbar klar, wenn ich die Farben aus dem Bitmap32.Canvas.Pixels auslese und nicht aus Bitmap32.pixel
Somit wird die Anzeige jetzt recht flüssig dargestellt.
Wenn ich die gesamte Anzeige rausnehme (Sowohl das Erstellen als auch das Aufbereiten und Ausgeben), ist die CPU immernoch bei 7% - es liegt
anscheinend einfach daran, dass der Timer sehr sehr oft den Status der Buttons der G19 abfragt, um entsprechend zu reagieren.
Da währenddessen auch noch immer über eine OleVariant die aktuelle Titelposition, Name, Interpret, Album, Lautstärke etc. aus iTunes abgefragt werden, wird die CPU Auslastung
anscheinend doch hierbei erzeugt.
Die grafische Darstellung fällt dank Bitmap32 fast nicht mehr ins Gewicht.

Viele Grüße!

[Der schöne Günther]

CPU-Auslastung gehört zu iTunes wie das Amen in der Kirche

[Delphi-Narr]

Das sowieso
Aber hier sind wohl doch die alle 20ms stattfindenden Abfragen Schuld
Das native Logitech Medienapplet schafft es auch, das alles ordentlich abzufangen und darzustellen, ohne eine ultimative CPU Auslastung zu haben.
Irgendeine Idee, wie ich das machen kann?

[Der schöne Günther]

Zitat von Delphi-Narr:

das alles ordentlich abzufangen und darzustellen, ohne eine ultimative CPU Auslastung zu haben.

Aber doch bestimmt nicht 50 mal pro Sekunde auf den Titel in iTunes, Lautstärke und sonstwas prüfen? Immer wenn ich so etwas irgendwo gesehen habe, waren da oft sogar Verzögerungen von einer bis zwei Sekunden im Spiel, so genau will sicher niemand wissen, was gerade aus den Lautsprechern kommt...

Ansonsten: Wirklich 7-8% Gesamt-CPU-Last? Oder 7-8% auf dem Kern?

[Delphi-Narr]

Es waren 7% auf der gesamten CPU.
Das hab ich jetzt auf 1-2 runtergeschraubt (sogar besser als das Logitech Standardmodul mit weniger Funktionen).
Die Exceptions treten immer dann auf, wenn ich auf die DLL Funktionen außerhalb der Timerprozedur zugreife. Liegt es daran, dass das nicht threadsicher ist?!
Solang alles in der Timerprozedur bleibt, ist es kein Problem.
Den Bildschirm kann ich weiterhin mit 10-20 fps betreiben, das interessiert die CPU inzwischen nicht mehr wirklich.

Vielen Dank für die Hilfe