EOutOfRessources bei vielen Bitmap-Operationen

[Sanchez]

Hallo zusammen,

In meinem Programm wird ein MJpeg-Stream ausgelesen und jedes einzelne Bild hintereinander in ein Bitmap kopiert. Nach etwa 3 Stunden Laufzeit bekomme ich nur noch EOutOfResources-Exceptions.

So sieht die Funktion aus, die meine Bitmaps füttert:

Delphi-Quellcode:

procedure TMJPEGThread.GenerateBitmap;
var
  JPEGImage: TJPEGImage;
begin
  JPEGImage := TJPEGImage.Create;
  try
    JPEGImage.LoadFromStream(FAktImg);
    JPEGImage.Performance := jpBestSpeed;

    FBitmap.Assign(JPEGImage);
    ImgReady(FBitmap);
  finally
    JPEGImage.Free
  end;
end;

In der Zeile mit dem Assign meldet mir MemProof

Zitat:

60463 CreateDIBSection(1023481475,...,0,03E10000,0,0) Bitmap 9E051863 0 404 CreateDIBSection gdi32.dll
CreateDIBSection creates a device-independent bitmap that applications can write to directly.
The returned bitmap handle must be freed with DeleteObject when no longer needed.

Muss ich also vor dem Assign den alten Inhalt des Bitmaps freigeben?

Ich hab versucht FBitmap.FreeImage aufzurufen, bevor das neue Bild zugewiesen wird, dass ändert aber nix an den Meldungen von MemProof.

Was mach ich falsch?

grüße, daniel

[EDIT]Hatte nur die hälfte von der Memproof-Meldung kopiert.[/EDIT]

[marabu]

Hallo Daniel,

ich vermisse in deinem Code die Bitmap-Methoden Dormant(), FreeImage(), ReleaseHandle(), was allerdings auch daran liegen könnte, dass du die an anderer Stelle verwendest. Sobald du keinen Bedarf mehr für die Original-Bildparameter hast, sind die angesagt.

Grüße vom marabu

[Muetze1]

Moin!

Zitat von marabu:

Bitmap-Methoden Dormant()

Wozu? Dormant wandelt meist in einem langwierigen Prozess das Bild von einem GDI Objekt in ein Systemobjekt um. Wozu dieser Aufwand? Wie gesagt: dieser Vorgang braucht meistens recht viel Zeit und zum anderen werden als Nebeneffekt die GDI Resourcen freigegeben - richtig, weil er ja dann die Systemresourcen nutzt.

MfG
Muetze1

[Sanchez]

Hallo Marabu,

Ich hab jetzt mal die Funktion so angepasst:

Delphi-Quellcode:

procedure TMJPEGThread.GenerateBitmap;
var
  JPEGImage: TJPEGImage;
begin
  JPEGImage := TJPEGImage.Create;
  try
    JPEGImage.LoadFromStream(FAktImg);
    JPEGImage.Performance := jpBestSpeed;
    FBitmap.Assign(JPEGImage);
    ImgReady(FBitmap);
  finally
    FBitmap.Dormant;
    FBitmap.FreeImage;
    FBitmap.ReleaseHandle;
    JPEGImage.Free
  end;
end;

MemProof meldet das gleiche Problem noch in der Funktion ImgReady und zwar beim Aufruf eines Events, dem diese Funktion zugewiesen ist:

Delphi-Quellcode:

procedure TAnzeige.OnImage(Sender: TObject; _Img: TBitmap);
begin
  if Assigned(FCritSect) then begin
    FCritSect.Acquire;
    try
      if not FLocked then begin
        if not FBitmap.Empty then begin
          FBitmap.Dormant;    // Free up GDI resources
          FBitmap.FreeImage;  // Free up Memory.  (not really needed)
          FBitmap.ReleaseHandle;   // This will actually lose the bitmap (not needed)
        end;
        FBitmap.Assign(_Img);
      end;
    finally
      FCritSect.Leave;
    end;
    if GetTickCount >= (FLastImgRefresh + FMinImgRefresh) then begin
      //PostMessage(self.Handle, WM_PAINT, 0, 0);
      FFestImgReady := true;
      (sender as TImgThread).DoSynchronize(pbImg.Invalidate);
      FLastImgRefresh := GetTickCount;
    end;
  end;
end;

Weil FBitmap das OffScreen-Bitmap für eine PaintBox ist, kann ich Dormant und Co. erst vor dem nächsten Zuweisen aufrufen.

MemProof zeigt mir übrigens immer jeweils einen Fehler beim Aufruf von GenerateBitmap und einen beim Aufruf dieses Events an.

[Nachtrag zum Posting von Muetze]
Heißt das für mich, ich sollte einfach mit FreeImage und ReleaseHandle aufräumen?

[Sanchez]

Ich hab gerade bemerkt, dass GenerateBitmap in dieser Form:

Delphi-Quellcode:

procedure TMJPEGThread.GenerateBitmap;
var
  JPEGImage: TJPEGImage;
begin
  JPEGImage := TJPEGImage.Create;
  try
    JPEGImage.LoadFromStream(FAktImg);
    JPEGImage.Performance := jpBestSpeed;
    FBitmap.Assign(JPEGImage);
    ImgReady(FBitmap);
  finally
    FBitmap.Dormant;
    FBitmap.FreeImage;
    FBitmap.ReleaseHandle;
    JPEGImage.Free
  end;
end;

innerhalb von ca. 1 Minute satte 350MB Speicher frisst.
Wenn ich ReleaseHandle auskommentiere, ist der Speicherverbrauch gestoppt.
Ich werds mal versuchen, nur mit FreeImage laufen zu lassen.

[marabu]

Hola Sanchez,

ich bin kein Grafikspezialist, also nur zum Abgleich unseres Verständnisses von TBitmap...

Mit LoadFrom...() wird ein lossless image von der externen Bitmap-Datei im Speicher erzeugt. Sobald du an dem Bild rumspielst, wird eine Kopie davon erzeugt - dabei wird die Farbtiefe auf 16 reduziert. Statt Rumspielen kannst du das Kopieren auch mit Dormant() erzwingen. Der Schlafmodus bezieht sich dabei offenbar auf das lossless image. Der Verbrauch von GDI-Resourcen wird dabei verringert, aber der Speicherbedarf kann steigen. Mit FreeImage() kannst du den Speicher des dormant image freigeben. Mit ReleaseHandle() werden handle und image voneinander getrennt, z.B. zwecks Freigabe des Handles mit DeleteObject().

Wenn alle deine Arbeiten mit dem Bitmap beendet sind, dann solltest du nach meiner Meinung das klassische Free() aufrufen, bevor du mit Assign() zum nächsten Bild gehst. Vielleicht habe ich dich mit meinem unbedachten Hinweis auf die vielen bunten Methoden aus dem Delphi OH Beispiel ein wenig in die falsche Richtung gejagt...

vaja con dios

Zerknirschte Grüße vom marabu

[Sanchez]

Oiga marabu,

Ich hab jetzt mal einen Versuch gemacht, bei dem ich mir für jedes Assign eine eigene Bitmap-Instanz erzeuge und am Ende wieder freigebe. Dadurch werden die GDI-Ressourcen aber trotzdem verbraten. Allerdings bei weitem nicht bei jedem Durchlauf. So ca. jede Minute geht ein Handle verloren. Es werden aber in der Sekunde vermutlich min. 50 Bitmaps zugewiesen.
Ich werd aus dem ganzen nicht schlau.

grüße, daniel

[Ultimator]

Was passiert denn, wenn du das JPEGImage nicht immer neu erstellst, sondern eine private-Feld deines Threads draus machst, das beim Formcreate (oder so) erstellst und beim Formdestroy freigibst?

[Sanchez]

Hi,
Das ändert gar nichts.
Mir ist übrigens gerade aufgefallen, dass laut MemProof auch der Aufruf einer Funktion, die von zwei Bitmaps die Scanlines durchmarschiert und in eines davon reinpinselt, gelegentlich GDI-Ressource schluckt.
Kann mir jemand erklären warum und was ich dagegen machen könnte?

[Sanchez]

Das Problem hab ich jetzt weitgehend im Griff.
Das Problem waren die Massen an Assigns die ich Kreuz und Quer ausgeführt hab.
Die hab ich jetzt teilweise durch BitBlts ersetzt und nach etwas Spielerei meldet Memproof keine vernichteten GDI-Ressourcen mehr.