AW: Nach CopyMemory werden Daten nicht übernommen
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:
Trotzdem steigt der Speicher!
SafeArrayCopy(TVariantArg(ValOUT).parray, PpixelDataArr);
SafeArrayDestroy(TVariantArg(ValOUT).parray); SafeArrayDestroy(PpixelDataArr); 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:
Hätte das ganze keinen triftigen Grund gehabt hätte ich nicht gefragt. Hört doch auf mit eurem unnötigen Gewäsch.. :evil: 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 |
AW: Nach CopyMemory werden Daten nicht übernommen
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. |
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
Zitat:
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:
Danke für die Infos.
// *********************************************************************//
// 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; PS: Da bin ich auch noch nicht hinter gestiegen was damit gemeint ist. Zitat:
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 |
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
|
AW: Nach CopyMemory werden Daten nicht übernommen
Hmmm hab es mit 32 Bitmaps versucht das geht nicht.
32 Bitmaps sind 8 Byte per Pixel (incl. Alpha Channel) Oder? gruss |
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
|
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
Zitat:
gruss |
AW: Nach CopyMemory werden Daten nicht übernommen
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.) |
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
Danke für die Richtigstellung. Zitat:
Aber egal lassen wird das. Zitat:
Warum sollte ich dann anderen was bezahlen? :) gruss |
AW: Nach CopyMemory werden Daten nicht übernommen
Zitat:
Zitat:
Deshalb würde ich erwarten, dass es in dem Objekt irgendwo auch ein Zugriff auf den Buffer möglich ist. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:27 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz