Bilder komprimieren und speichern mit Threads

[Bummi]

zumindest Append müsstest Du mit einer CS kapseln ...
ansonsten habe ich so ein komisches Bauchgefühl ...

[Schwedenbitter]

Zu früh gefreut:

Ich habe meinen Code jetzt mal unter realistischeren Bedingungen getestet. Dazu habe ich jeweils zwischen

Delphi-Quellcode:

Append();

ein

Delphi-Quellcode:

Sleep();

gepackt. Hintergrund ist der, dass der Scanner die Bilder auch nicht sofort auf einmal liefert.
Zudem habe ich den Thread zur besseren Lesbarkeit in eine eigene Unit gepackt.

Dabei ist mir ein weiterer Fehler aufgefallen.
Der Thread wird offenbar noch korrekt gestartet. Auch wenn das Ereignis an das MainForm erst später kommt, so sehe ich zeitnah nach dem Erstellen des Thread die 1. Datei auf dem Laufwerk erscheinen. Dann passiert aber lange nichts. Der Rest wird erst in die Dateien gespeichert, wenn alle Dateien geliefert wurden. Das ist aber leider nicht der Sinn vom Ganzen. Nach meinem Verständnis sollte der Thread, solange nicht

Delphi-Quellcode:

Ende:=True;

gesetzt ist, alles sofort wegspeichern, was in der Liste ist... :gruebel:

Ich habe die Änderungen vom Code wieder als zip-Datei angefügt und würde mich freuen, wenn mal jemand von den Profis drüber schauen und mir sagen könnte, wo mein Fehler liegt.

Gruß & Dank, Alex

[Bummi]

Ich habe nicht alles nachvollzogen, aber ein paar Sachen sind mir aufgefallen:
1.) keine CS bei Append und Ende
2.) in diesem Block

Delphi-Quellcode:

FThread.Append(Bild);
Sleep(250);// -> 4 Bilder / 1 Sek.

läuft der Thread ja bereits.....
3.) wenn das:

Delphi-Quellcode:

Procedure TMainForm.RepeaterTimer(Sender: TObject);
Begin
   Repeater.Enabled:=False;
   ScannenClick(nil);
End;

ausgeführt wird, wird jedes mal eine neuer Thread losgetreten

Vielleicht schaut Sir Rufo mal drüber ....

[Schwedenbitter]

Erstmal danke fürs Drüberschauen!

Zitat:

Zitat von Bummi (Beitrag 1085287)

1.) keine CS bei Append und Ende

Das kommt noch. Ich hatte es bereits drin, wollte aber wirklich jede mögliche Fehlerquelle für das beschriebene Phänomen ausschließen.

Zitat:

Zitat von Bummi (Beitrag 1085287)

2.) in diesem Block

Delphi-Quellcode:

FThread.Append(Bild);
Sleep(250);// -> 4 Bilder / 1 Sek.

läuft der Thread ja bereits.....

Eben!
Auf meinem Rechner braucht er allein für das Umwandeln in png ca. 1 Sek/Bild. Er sollte an diese Stelle daher bereits genug zu tun haben, um noch während des Anfügens (

Delphi-Quellcode:

Append();

)weiterer Bilder die bereits vorhandenen umzuwandeln.
Das macht er aber nicht, was ich wiederum nicht verstehe.

Zitat:

Zitat von Bummi (Beitrag 1085287)

3.) wenn das:

Delphi-Quellcode:

Procedure TMainForm.RepeaterTimer(Sender: TObject);
Begin
   Repeater.Enabled:=False;
   ScannenClick(nil);
End;

ausgeführt wird, wird jedes mal eine neuer Thread losgetreten

Das ist ausdrücklich so gewollt!
Ich hatte ebenfalls bereits meine Code fürs Vergrößern/Verkleiner und/oder Drehen mit drin. Da erhielt ich hin und wieder - aber leider nicht wirklich reproduzierbar - eine

Delphi-Quellcode:

EOutOfResources

. Ich habe das Code-Fragment daher mal eine Weile ohne Benutzereingaben laufen lassen.
Man kann den Kreislauf ja jederzeit unterbrechen, indem man einfach den Haken rausnimmt. Dann hört der "Spuk" nach dem nächsten Thread-Ende auf!

Zitat:

Zitat von Bummi (Beitrag 1085287)

Vielleicht schaut Sir Rufo mal drüber ....

Das wäre wirklich nett.

Gruß, Alex

[Schwedenbitter]

Ich bin wieder ein Stück weiter!

Die von mir zur Steuerung des Scanners verwendete Komponente

Delphi-Quellcode:

TDelphiTwain

liefert die Bilder immer per Ereignis an das Hauptprogramm. Ich habe dieses Verhalten nun nachgebaut, indem ich die Bilder nicht wie bisher mittels Schleife an den Thread übergebe, sondern per

Delphi-Quellcode:

TTimer.OnTimer;

. Dieses hängt nun - einem sehr schnellen Scanner gleich - aller 250 ms ein weiteres Bild an die Liste im Thread und das klappt jetzt:
Die Meldung "Alle Bilder geliefert..." kommt regelmäßig so ca. nachdem 17 Seiten bereits gespeichert wurden :lol: So war der Plan!

Dennoch finde ich das ein eigenartiges Verhalten. Scheinbar wird der Thread tatsächlich erst gestartet, nachdem die Procedure, in dem er erzeugt wurde, vollständig beendet ist. Das hätte ich nicht vermutet.
Kann jemand diese Beobachtung zumindest für TurboDelphi bestätigen?

Nachdem ich das nun - scheinbar endgültig - geklärt habe. Werde ich mich nun wieder den Problemen Stretchen und Drehen zuwenden.
Das hatte ich bereits getan, bevor ich merkte, dass das Speichern tatsächlich nicht so läuft, wie es soll. Ich hatte dabei mehrfach eine Exception

Delphi-Quellcode:

EOutOfResources

gefangen und würde hierzu ggf. gern mal nachfragen.

@Moderator
Soll ich dazu dann ein neues Thema aufmachen oder hier weiterschreiben?
Ich habe die aktuelle Version mal für die Nachwelt angefügt. Die vorhergehenden Code-Beispiele können bei Platzmangel ggf. gelöscht werden. Danke.

Gruß & Dank, Alex

[Blup]

Der Zugriff auf FBilder muss durch eine Critical Section abgesichert werden.

Delphi-Quellcode:

self.Priority:=tpIdle
;

Natürlich macht der Thread so nur was, wenn der Hauptthread gerade nichts zu tun hat.
Beim Erzeugen des Formulars ist der Hauptthread aber schon beschäftigt.

[Schwedenbitter]

Zitat:

Zitat von Blup (Beitrag 1085506)

Der Zugriff auf FBilder muss durch eine Critical Section abgesichert werden.

Na gut, na gut. Das habe ich nun gemacht.

Zitat:

Zitat von Blup (Beitrag 1085506)

Delphi-Quellcode:

self.Priority:=tpIdle;

Natürlich macht der Thread so nur was, wenn der Hauptthread gerade nichts zu tun hat.
Beim Erzeugen des Formulars ist der Hauptthread aber schon beschäftigt.

Das verstehe ich nicht ganz. Vom Grundsatz her ist mir das klar. Aber der Thread wird doch erst erzeugt und gestartet, wenn man auf den Button "Scannen" klickt. Da ist doch das Formular bereits erzeugt worden, oder wo ist mein Denkfehler.

Es läuft jetzt übrigens auf einem Testrechner seit mehr als 2 Stunden problemlos. Sorgen bereitet mir nur, dass FastMM mir 3 - wenn auch mit 620 Bytes sehr kleine - Speicherlecks bringt. Ich habe das Programm bereits mit Debug-DCU, map-Dateien etc. pp. compiliert. Allerdings kommen immer Meldungen mit TButton, TDialog usw. Die werden zwar vom Hauptprogramm verwendet. Ich dachte aber, dass sich der Compiler bei entsprechenden Komponenten selbst um die Freigabe kümmert...
Ich würde - falls noch jemand Muße hat - den aktuellen Code nochmal hochladen.

Am Schluss noch eine allgemeine, vielleicht auch marginale Frage:
Im Moment schicke ich vom Thread Ereignisse an den HauptThread und zwar so:

Delphi-Quellcode:

Procedure TSaveThread.MessageNext;
Begin
  If Assigned(FOnNext) Then
    FOnNext(self, FNext);
End;

Procedure TSaveThread.Execute;
Begin
  While (Not Terminated) Do
  Begin
    ... // <- tu irgendwas

    Syncronize(MessageNext);
  End;  
End;

Kann man das bedenkenlos auch so machen:

Delphi-Quellcode:

Procedure TSaveThread.MessageNext;
Begin
  FOnNext(self, FNext);
End;

Procedure TSaveThread.Execute;
Begin
  While (Not Terminated) Do
  Begin
    ... // <- tu irgendwas

    If Assigned(FOnNext) Then
      Syncronize(MessageNext);
  End;  
End;

Dann würde er nämlich nicht erst Syncronize aufrufen und in die andere Procedure springen müssen, wenn er vorher prüft, ob das Ereignis überhaupt zugewiesen ist.
Die 1. Variante habe ich mehrfach gesehen und gehe deshalb davon aus, dass sie richtig ist. Spricht etwas gegen die 2. Variante?

Gruß, Alex

[Bummi]

Wenn Du den Setter von FOnNext mit einer CS verriegelt hast spricht IMHO nichts dagagen, sonst könnte bei (wirst Du nicht machen) gleichzeitigen Zugriff Müll in FOnNext stehen.

[Medium]

Wenn es nicht notwendig ist, dass diese "Message" synchron zum (bzw. im) Thread läuft, kannst du auch tatsächliche Windows Messages an dein Fensterhandle schicken, und dort mit einem Eventhandler reagieren. (SendMessage()) Das würde das ganze noch eine Spur mehr entkoppeln, ist aber daran gebunden, dass im Handler weder Thread auf MainForm noch MainForm auf Thread Felder zugreifen. So angelegte Konzepte "behagen" mir in der Regel mehr, als harte synchrone Callbacks, zumal man mit zu vielen letzterer den Nutzen von Threads auch gerne mal schmälern bis vernichten kann.

[Blup]

Im Prinzip ist diese Lösung zulässig:

Delphi-Quellcode:

    CS.Enter;
    try
      If Assigned(FOnNext) Then
        Syncronize(MessageNext);
    finally
      CS.Leave;
    end;

Aber man muss dann auch den Zugriff aus dem Hauptthread auf das Property "OnNext" mit CS schützen.
Damit würde aber in der Ereignisbehandlung "OnNext" im Hauptthread bei einem eventuellen Zugriff auf das Property "OnNext" des SaveThread ein Deadlock entstehen.

In der ursprünglichen Variante ist ein Schutz nicht notwendig, da auf FOnNext grundsätzlich nur im Hauptthread zugegriffen wird.
Ich denke es spricht hier aber nichts dagegen, auf "Assigned(FOnNext)" zusätzlich auch im Thread ohne CS zu prüfen, um unnötige Aufrufe von "Syncronize" zu vermeiden.