TBitmap32 in ByteArray (schneller) oder Alternative

[Delphi-Narr]

Hm ok ich stehe wohl etwas auf dem Schlauch

Delphi-Quellcode:

var
    Pic2:TByteArray;
    i,j,ges:integer;
    R,G,B:byte;
    color:TColor;
    P: PColor32Array;
    C: TColor32;
begin
    SetLength(Pic2,320*240*4);

   ges:=0;
   P:=VirtualBitmap.Bits;
   for I := 0 to 320*240-1 do
    begin
      C:=P[i];
      Pic2[ges]:=TColor32Entry(C).R;
      Pic2[ges+1]:=TColor32Entry(C).G;
      Pic2[ges+2]:=TColor32Entry(C).B;
      Pic2[ges+3]:=255; 
      ges:=ges+4;
    end;
   // ...
   LogiLcdColorSetBackground(Pic2);

So sieht das bisher bei mir aus - ist etwas umständlich gemacht, weil die Schleife noch von der alten Methode übrig geblieben ist.
Die benötigten Werte stehen ja auch in C.Planes drin vermute ich?!
Auf diese Weise erhalte ich zwar generell das gewünschte Bild auf dem G19 LCD, doch lediglich den ersten Frame - nach dem Update (LogiLcdColorSetBackground)
kommt eine schöne Fehlermeldung:

Zitat:

In Projekt xyz.exe trat ein problem mit folgender Meldung auf: 'pivileged instuction at 0x0018fd95'. ...

Da scheint wohl irgendein Problem beim Aufruf vorzuliegen...

[jfheins]

Ich würde es jetzt einfach mal so probieren:

Delphi-Quellcode:

// ggf. casten
    LogiLcdColorSetBackground(VirtualBitmap.Bits);
// Vielleicht erwartet die Funktion aber auch nen Pointer?
    LogiLcdColorSetBackground(@VirtualBitmap.Bits);

Zu verlieren hast du ja nix

[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?