Nach CopyMemory werden Daten nicht übernommen

[EWeiss]

begin OT;
Ihr mit euren Spitzfindungen!
Warum versucht ihr die Leute immer zu belehren anstatt einfach nur etwas zum Thema zu sagen.
Wenn ihr das nicht wollt last es einfach.
Ist mir lieber als das unnötige Getue Drumherum.
end OT;

Ich weis was den stetigen Anstieg versursacht nur man kann nicht mehr tun als die Ressourcen freizugeben.

SafeArrayCopy speichert mein neu erstelltest Array in mein Arbeits Array.

Delphi-Quellcode:

SafeArrayCopy(TVariantArg(ValOUT).parray, PpixelDataArr);
SafeArrayDestroy(TVariantArg(ValOUT).parray);
SafeArrayDestroy(PpixelDataArr);

Trotzdem steigt der Speicher!

Jetzt erkläre mir mal mit einem wirklich guten Spruch wie ich den Speicher freigeben soll
wenn die Funktion Ansicht intern diesen Speicherleck verursacht?
Kommentiere ich diese Zeile aus funktioniert alles so wie es soll.

Soll ich jetzt noch 100 NIL's hinterherschicken oder was!

Zitat:

mit dem dafür nötigen Debugwissen beschschäfftigt

Und?
Hätte das ganze keinen triftigen Grund gehabt hätte ich nicht gefragt.
Hört doch auf mit eurem unnötigen Gewäsch.. Trollerei

Nach meiner Korrektur geht es jetzt konstant 14MB Speicher auch ohne dein zutun.

Delphi-Quellcode:

    bitMapSize := Bmp.bmWidth * Bmp.bmHeight;

    rgsabound[0].cElements := bitMapSize;
    rgsabound[0].lLbound := 0;

    PpixelDataArr := SafeArrayCreate(VT_UI1, 1, rgsabound);
    if Assigned(PpixelDataArr) then
    begin
      SafeArrayAccessData(PpixelDataArr, pArrayData);
      CopyMemory(pArrayData, Bmp.bmBits, bitMapSize);
      SafeArrayUnaccessData(PpixelDataArr);
    end;
    AtmoCtrlLib.AtmoSendPixelData;

    pArrayData := nil;
    SafeArrayDestroy(PpixelDataArr);
    DeleteObject(Background.Handle);
    FreeAndNil(BitmapStream);

gruss

[jaenicke]

Also wenn ich die Doku zur einfachen DLL-Version richtig verstehe, funktioniert das ganze bei der DLL Version so:
- Threadstart
AtmoInitialize + AtmoCreateTransferBuffers
- Benutzung
AtmoLockTransferBuffer um den Pointer auf den Buffer zu holen, AtmoSendPixelData zum Senden
- Threadende
AtmoFinalize(1)

Bei dir erzeugst du jedes mal den Buffer neu. Aber warum sollte das bei Verwendung von COM notwendig sein? Dazu habe ich allerdings keine Doku gefunden.

[EWeiss]

Zitat:

AtmoLockTransferBuffer um den Pointer auf den Buffer zu holen

Nö sperrt den Transfer des Buffer (Lock)

Zitat:

Bei dir erzeugst du jedes mal den Buffer neu. Aber warum sollte das bei Verwendung von COM notwendig sein?

Weil das Bild sich jede MS ändert.
Ich habe es auch versucht mit einem Flag welches prüft ob die Funktion schon aufgerufen wurde.
Das Ergebnis war das die Anwendung einen AV gemeldet hat.
Daher gehe ich erstmal davon aus das es so sein muss.

AtmoCreateTransferBuffers
Wird der Header der Bitmap erstellt also vorbereitet zum senden.

Danach werden die Pixel gesendet mit AtmoSendPixelData.

Ich kann mir das aber nochmal genau anschauen ob ich dahingehend noch was ändern kann / muss.

Delphi-Quellcode:

// *********************************************************************//
// richtet den Pixeltransferbuffer für den LiveSource Modus mit externer Quelle ein.
// FourCC enthält dabei den Code wie die Pixeldatei aufgebaut sind - derzeit sind
// folgende Codes in AtmoWinA.exe implementiert - andere Codes werden einfach ignoriert.

// FourCC =  "HSVI"  steht für ein Bild was bereits in HSV Daten vorliegt...
// oder man übergibt die in Windows.h? definierte Konstante "BI_RGB" was
// signalisiert dass es sich um unkomprimierte Pixeldaten handelt.

// bytePerPixel = legt fest wieviel Byte ein Pixel benötigt
// für HSVI wird der Wert 3 erwartet.
// für BI_RGB sind die Werte 2, 3 oder 4 zulässig.
// für 2 ist RGB 565 definiert!
// width = Breite des Bildauszugs derzeit ist nur 64 zulässig!
// height = Höhe des Bildauszugs derzeit ist nur 48 zulässig!
// *********************************************************************//
procedure TAtmoCtrlLib.AtmoCreateTransferBuffers(FourCC, bytePerPixel, width,
  height: Integer);

begin

  if Assigned(PbitmapInfoArr) then
  begin
    SafeArrayDestroy(PbitmapInfoArr);
    PbitmapInfoArr := nil;
  end;

  PbitmapInfoArr := SafeArrayCreateVector(VT_UI1, 0, sizeof(BITMAPINFOHEADER));

  SafeArrayAccessData(PbitmapInfoArr, Pointer(pheader));
  pheader.biSize := sizeof(BITMAPINFOHEADER);
  pheader.biWidth := width;
  pheader.biHeight := height;
  pheader.biBitCount := bytePerPixel * 8;
  pheader.biCompression := FourCC;
  SafeArrayUnaccessData(PbitmapInfoArr);
end;

Danke für die Infos.

PS:
Da bin ich auch noch nicht hinter gestiegen was damit gemeint ist.

Zitat:

für BI_RGB sind die Werte 2, 3 oder 4 zulässig.

Was für einen Wert 2,3 oder 4 bei mir ist BI_RGB = 0 welche Werte sollte man dann da noch addieren.
Na ok! Ich denke die meinen damit die Anzahl der Bytes wie bei 24 Bit Bitmaps = 4 Byte
32 Bit Bitmaps werden dann ignoriert weil mehr als 4 Bytes
Etwas undurchsichtig


gruss

[Zacherl]

Zitat von EWeiss:

Da bin ich auch noch nicht hinter gestiegen was damit gemeint ist.

Zitat:

für BI_RGB sind die Werte 2, 3 oder 4 zulässig.

Was für einen Wert 2,3 oder 4 bei mir ist BI_RGB = 0 welche Werte sollte man dann da noch addieren.
Na ok! Ich denke die meinen damit die Anzahl der Bytes wie bei 24 Bit Bitmaps = 4 Byte
32 Bit Bitmaps werden dann ignoriert weil mehr als 4 Bytes

So wie ich das verstanden habe, beziehen sich 2, 3 und 4 auf den Wert den bytePerPixel haben kann, wenn FourCC auf BI_RGB gesetzt ist. Das heißt, du kannst in diesem Falle 16, 24 und 32 Bit Bitmaps verwenden.

[EWeiss]

Hmmm hab es mit 32 Bitmaps versucht das geht nicht.
32 Bitmaps sind 8 Byte per Pixel (incl. Alpha Channel) Oder?

gruss

[Zacherl]

Zitat von EWeiss:

Hmmm hab es mit 32 Bitmaps versucht das geht nicht.
32 Bitmaps sind 8 Byte per Pixel (incl. Alpha Channel) Oder?

32 Bit Bitmaps sind 4 Byte pro Pixel. Jeweils 1 Byte für A, R, G und B.

[EWeiss]

Zitat von Zacherl:

Zitat von EWeiss:

Hmmm hab es mit 32 Bitmaps versucht das geht nicht.
32 Bitmaps sind 8 Byte per Pixel (incl. Alpha Channel) Oder?

32 Bit Bitmaps sind 4 Byte pro Pixel. Jeweils 1 Byte für A, R, G und B.

Ich will dir ja gerne glauben .. Aber dann schreibt jeder etwas anderes.

Zitat:

32 bpp.. Das Format ist wie bei BI_BITFIELDS, wenn folgende Farbmasken verwendet würden: 0x00FF0000 für den Rot-Kanal0x0000FF00 für den Grün-Kanal0x000000FF für den Blau-Kanal.
Jeder Farbkanal ist 8 Bit pro Pixel groß; insgesamt ergeben sich 16.777.216 mögliche Farben (8 Bit sind ungenutzt).
Einige Programme wie etwa Adobe Photoshop interpretieren die verbleibenden 8 Bits (0xFF000000) als Alphakanal mit 256 möglichen Transparenzstufen.
Dies ist jedoch von der Spezifikation nicht vorgesehen.

Kann auch sein das ich leicht übermüdet bin ... hehehehee

gruss

[Medium]

Bist du. Da steht 8 Bit pro Pixel, was genau 1 Byte ist. Bit <> Byte. Es gibt keine Windows-Nativen Bitmaps mit mehr als 8 Bit/Pixel, und das sind eben 32Bit Bitmaps. Schon immer gewesen. Oftmals sind sogar 24Bit Bitmaps zu 32Bit Bitmaps identisch ausgerichtet weil es für den Zugriff deutlich günstiger ist als 3 Byte; das vierte bleibt dabei dann (wie das Wiki ja schon sagt) einfach unbenutzt.
(Und sei mal etwas unempfindlicher. Was ist falsch daran, sich mit den verfügbaren Tools mal auseinanderzusetzen? Hilfe zur Selbsthilfe nennt sich das. Wenn du jemanden dein Programm genau vorkauen lassen möchtest, leg wat aufn Tisch.)

[EWeiss]

Zitat:

Bit <> Byte

Arghh... yeah immer das gleiche mit mir sehe den Unterschied zwischen Bit und Byte.. nicht.

Danke für die Richtigstellung.

Zitat:

Und sei mal etwas unempfindlicher. Was ist falsch daran, sich mit den verfügbaren Tools mal auseinanderzusetzen?

Nichts.. Aber darauf hinzuweisen das man zu blöd ist zum debuggen schon..
Aber egal lassen wird das.

Zitat:

Wenn du jemanden dein Programm genau vorkauen lassen möchtest

Mein Programm? Nö ich mache das für die Leute bei MediaPortal (Hobby) und dafür will ich nichts
Warum sollte ich dann anderen was bezahlen?

gruss

[jaenicke]

Zitat von EWeiss:

Zitat:

AtmoLockTransferBuffer um den Pointer auf den Buffer zu holen

Nö sperrt den Transfer des Buffer (Lock)

Zitat:

sperrt den Transferbuffer für den aktuellen Thread und liefert einen Zeiger auf den
Speicherblock zurück.

Wo du das Array überhaupt mit der AtmoCtrlLib in Verbindung bringst, ist mir aus deinem letzten Quelltext auch nicht klar. Du rufst dort nur AtmoCtrlLib.AtmoCreateTransferBuffers auf und dann AtmoCtrlLib.AtmoSendPixelData. Bei beiden Aufrufen ist aber keinerlei Verbindung zu deinem Array involviert.

Deshalb würde ich erwarten, dass es in dem Objekt irgendwo auch ein Zugriff auf den Buffer möglich ist.