Ich würde es bei den Speicherlecks lassen - Windows räumt ja auf. Aber wenn es dir so wichtig ist:

Komprimiere nur einen kleinen Teil des Bilds und nehme dies als Anhaltspunkt, welches Format besser ist
Schreibe den JPG/PNG Algorithmus selbst oder binde eine Bibliothek ein, die das unterbrechen gestattet.
Entwickle eine Heuristik. Zum Beispiel sind Bilder mit Gradienten und homogenen Flächen tendenziell besser für PNG geeignet, Bilder mit vielen Details besser für JPG.

Wie wäre es, wenn man auf das Ende der Threads wartet, bevor sich die Anwendung beendet?

Zitat von himitsu:

Wie wäre es, wenn man auf das Ende der Threads wartet, bevor sich die Anwendung beendet?

So mache ich es im Moment. Aber das Komprimieren je einer JPEG und einer PNG-Datei kann bei einem 200 dpi Bild mit durchschnittlicher CPU mal eben jeweils 8 Sekunden dauern. Bei 10 Bildern will man nicht wirklich warten. Mir wäre es auch egal, weil der Benutzer die Speicherlecks nicht sieht. Aber es ist unsaubere Programmierung.

• die Thread-Instanz darf sich nicht selber freigeben
• das Programm ruft Thread.Terminate auf
• die Threads beenden sich (nach durchschnittlich 4 Sekunden aka 50% von 8 Sekunden)
• das Programm wartet auf das Ende
• und beendet sich dann

Zitat von Schwedenbitter:

Aber das Komprimieren je einer JPEG und einer PNG-Datei kann bei einem 200 dpi Bild mit durchschnittlicher CPU mal eben jeweils 8 Sekunden dauern.

Nochmal: Du schmeißt 8 Sekunden Arbeitszeit einfach weg, wenn du die Größe hast

Zitat von Schwedenbitter:

Bei 10 Bildern will man nicht wirklich warten.

Eventuell könnte dir ein Threadpool gut tun. Wenn die 10 Threads nebenläufig rödeln, kommen die sich vermutlich bloß in die Quere.
Außerdem könntest du im Threadpool vor dem Vergeben einer neuen Aufgabe prüfen, ob die Anwendung beendet wurde.

An deiner Stelle würde ich mir tatsächlich eine TStream-Ableitung schreiben und mal gucken, wie die Bibliotheken den Stream benutzen. Wenn die regelmäßig Schreibzugriffe auf den Stream machen, dann wäre das eine schöne Gelegenheit, den ganzen Quark mit einer Exception (oÄ.) abzubrechen.

Wenn ein Prozess beendet wird, egal wie, ob regulär oder wenn über den Taskmanager, gibt es keine Speicherlecks. Wo sollen die auch sein? Speicherlecks kann es nur innerhalb eines Prozesses geben. Dieser existiert aber nicht mehr. Man kann ja auch kein Loch in einem Loch buddeln. Des weiteren schließt Windows automatisch alle von dem Prozess geöffneten Händels. Also: Prozess beendet, alles gut.

Natürlich kann man darüber diskutieren, ob es guter Programmierstil ist nicht hinter sich aufzuräumen. Da hat jeder seine eigene Meinung.

Wenn man selber aufräumt, dann sieht man zumindestens, ob sich unbeabsichte Löcher verstecken.
Und wenn richtig aufgeräumt wird, dann sind Fehler beim Beenden minimiert.

z.B. Komponente auf Form, die beim Beenden auf etwas Globales in einer Unit zugreift ... wenn die Unit bereits ordentlich entladen wurde, dann würde es durt womöglich schön knallen.

Die Spiecherlecks werdn doch deshalb angezeigt, weil die Threads beim Beenden des Prozesses einfach abgeschossen werden und die von jedem Thread belegten Ressourcen nicht freigeben wurden.

Wenn man das nicht haben möchte, dann muss man sich eben selber um die Freigabe der Threads kümmern und nicht TThread.FreeOnTerminate := True; wegdelegieren.

BTW: Das hier ist grober Unfug:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TCalcThread.Create(Codec: TCodecType; Bitmap: TBitmap;
   OnCalcDone: TOnCalcDone);
Begin
   fSize:= -1; // ungültigen Wert vorgeben
   fCodec:= Codec; // Codec merken
   fOnCalcDone:=OnCalcDone; // Zeiger auf Ereignis merken
   fBitmap:=TBitmap.Create; // TBitmap anlegen
   fBitmap.Assign(Bitmap); // Bild kopieren
   FreeOnTerminate:=True; // Speicher selbst freigeben

   Inherited Create(True); // Thread erstellen
   Priority:= tpIdle; // geringe Priorität
// Resume; // "Start" löst Exception aus!
   Start; // "Resume" ist veraltet
End;

Während der Constructor abgearbeitet wird wird der Thread nicht loslaufen! Mit der Erkenntnis kann der Code wie folgt geschreiben werden:

zusammenfalten · markieren

Delphi-Quellcode:

Constructor TCalcThread.Create(Codec: TCodecType; Bitmap: TBitmap;
   OnCalcDone: TOnCalcDone);
Begin
   fSize := -1; // ungültigen Wert vorgeben
   fCodec := Codec; // Codec merken
   fOnCalcDone := OnCalcDone; // Zeiger auf Ereignis merken
   fBitmap := TBitmap.Create; // TBitmap anlegen
   fBitmap.Assign( Bitmap ); // Bild kopieren

   Inherited Create( False ); // Thread erstellen
   Priority := tpIdle; // geringe Priorität
   FreeOnTerminate := True; // Instanz selbst freigeben <- hmmm, nicht geschickt
End;

Der Destructor sollte allerdings wie folgt aufgebaut werden:

markieren

Delphi-Quellcode:

Destructor TCalcThread.Destroy;
Begin
   fOnCalcDone:=nil; // Zeiger löschen

   Inherited; // den Rest ausführen

   fBitmap.Free; // TBitmap selbst freigeben
End;

In TThread.Destroy wird unter anderem TThread.Terminate aufgerufen, weil der Thread ja noch aktiv sein kann. Wenn man dem Thread während der Abarbeitung die Ressource fBitmap unter dem A.... wegzieht, was kann dann passieren? Genau, es knallt. Also erst inherited , danach ist der Thread gesichert beendet und dann können alle Ressourcen ohne Reue freigeben werden!