Zitat von Sir Rufo:

Damit hast du rein gar nichts gewonnen ... ja, es funktioniert, aber wozu benötigst du dann einen Thread, wenn du es eh wieder im Hauptthread zeichnen lässt.

Das bringt nur was wenn vor dem Synchronize eine gaaaaanze menge arbeit passiert ... "zeichnen" bezieht sich hier ja nur auf einen Blit auf den Screen (der ja eigentlich flott sein sollte)

In der Tat passiert eine ganze Menge arbeit, das geht aus dem Beispiel jetzt nicht wirklich hervor.
Es sind viele Berechnungen und Zeichnungen, die zu einem Bild zusammengefügt werden, welches dann kopiert werden soll.
Da für jedes Bild alles neu berechnet werden muss ist ein thread sinnvoll.
Soweit ich das sehe wird nur der Synchronize-Teil von der Hauptform ausgeführt während die Berechnung des Bildes, welches später auf die Hauptform gemalt, threadsicher ist?
Oder muss beim Veränderungsvorgang wieder abgesichert werden, obwohl keine Zugriffe von der Hauptform erfolgen (was nicht sehr logisch wäre)?

Zitat von TheGroudonx:

In der Tat passiert eine ganze Menge arbeit, das geht aus dem Beispiel jetzt nicht wirklich hervor.
Es sind viele Berechnungen und Zeichnungen, die zu einem Bild zusammengefügt werden, welches dann kopiert werden soll.
Da für jedes Bild alles neu berechnet werden muss ist ein thread sinnvoll.
Soweit ich das sehe wird nur der Synchronize-Teil von der Hauptform ausgeführt während die Berechnung des Bildes, welches später auf die Hauptform gemalt, threadsicher ist?
Oder muss beim Veränderungsvorgang wieder abgesichert werden, obwohl keine Zugriffe von der Hauptform erfolgen (was nicht sehr logisch wäre)?

Beim Multithreading spricht man von Threadkontext und nicht "von der Hauptform ausgeführt". Entweder es wird im MainThreadContext ausgeführt (du kannst gefahrlos auf als Form-Komponenten zugreifen) oder eben nicht. Wenn du nicht im MainThreadContext bist, kannst du per Synchronize eine Methode im MainThreadContext ausführen lassen.

Zitat:

So sollte Multithreading eben gerade nicht funktionieren. Der Backgroundthread bekommt alle Informationen zum Abarbeiten als Kopie übergeben, bearbeitet das und benachrichtigt, dass er damit fertig ist. Dann kann wer auch immer sich dieses abholen.

Das war ja auch meine Anfangsidee. Leider funktionierte das "abholen" nicht.

Zitat von Whookie:

Zitat von Sir Rufo:

Damit hast du rein gar nichts gewonnen ... ja, es funktioniert, aber wozu benötigst du dann einen Thread, wenn du es eh wieder im Hauptthread zeichnen lässt.

Das bringt nur was wenn vor dem Synchronize eine gaaaaanze menge arbeit passiert ... "zeichnen" bezieht sich hier ja nur auf einen Blit auf den Screen (der ja eigentlich flott sein sollte)

Aber wie soll das passieren, er übergibt dem Thread die Referenz auf die Komponente, und dazu müsste man vorher per Synchronize das Bitmap daraus holen, dann verarbeiten und dann zurückschreiben. Und immer hoffen, dass die Komponente noch da ist.

So sollte Multithreading eben gerade nicht funktionieren. Der Backgroundthread bekommt alle Informationen zum Abarbeiten als Kopie übergeben, bearbeitet das und benachrichtigt, dass er damit fertig ist. Dann kann wer auch immer sich dieses abholen.

Zitat von Sir Rufo:

Der Backgroundthread bekommt alle Informationen zum Abarbeiten als Kopie übergeben, bearbeitet das und benachrichtigt, dass er damit fertig ist. Dann kann wer auch immer sich dieses abholen.

Kommt immer auf den Anwendungsfall an, ich verstehe das Beispiel so, dass in:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TPaintThread.Execute;
begin

 While (Terminated = False) do
 begin
   CalcABitmap(MyBild); // komplexe zeichenoperation...
 Synchronize(Zeichnen);
 sleep(1);

 end;
end;

..auf eine thread-interne ressource gezeichnet wird, CalcABitmap() benötigt entspr. Zeit und - wenn fertig - wird zum mainthread context gewechselt ... und da kann das bild ja abholen wer will ... in dem beispiel wirds halt in ein TImage geblittet und somit am schirm ausgegeben ...

Was mich nur noch verwundert ist, dass wenn ich den Thread durchsteppe, nach wie vor access-violations bzw auch einmal eine eexternalexception auftreten, während Threadeigene Bitmaps bearbeitet werden, auf die nicht von ausserhalb des Threads zugegriffen wird, welche auch 100% existieren. Dabei variiert das Tempo, in dem man zur nächsten Codezeile springen kann, stark, was normalerweise nicht passiert.

Lockst du deinen MyBild.Canvas auch korrekt?

markieren

Delphi-Quellcode:

procedure TPaintThread.CalcABitmap(const MyBild: TBitmap);
begin
   MyBild.Lock;
   try
     .. malen bis der bär kommt ..
   finally
     MyBild.Unlock;
  end;
end;

Wie gesagt wenn ich diese Art von locken verwende (MyBild.Canvas.lock) kommt es zu Fehlermeldungen.
Lasse ich es weg funktioniert es in der Regel.
Mein Problem ist jedoch, dass es bei meinem Beispielprojekt funktioniert, nicht aber bei meinem größeren Projekt.
Ich versuce gerade herauszufinden, wo der Unterschied liegt.

Na toll,

habe gerad herausgefunden, dass die Zeichenprozedur des Threads aufhört richtig zu arbeiten, kurz nachdem man mit der Maus über das TImage der Form fährt ._.