Ich hab befürchte, dass mich das mal jemand fragt... So muss ich mich dann wohl outen... Also ich programmiere seit ca. 85, mittlerweile - auch bei Delphi - professionell. Hab auch mit Multithreading (z.B. in Java) an sich keine Probleme - nur bei der Realisierung in Delphi haken für mich viele Sachen die ich ansonsten problemlos beherrsche. Sorry dafür, wenn ich das eher geschrieben hätte, hättest du dir vermutlich den theoretischen Teil schenken können, das ist mir alles klar.

Bloß - wie gesagt - wie ist's denn jetzt bei Delphi wirklich umgesetzt? Ich hab mein ursprüngliches Problem mal aufgebohrt: Berechnung über Synchronize dauert 0,58s, die Applikation friert aber mitnichten ein. Das ist es genau was mein Problem ist, Theorie und Beobachtung passen nicht zusammen. Fenster drüber schieben tut auch nichts, das hat aber nur was damit zu tun, dass ich den Hintergrundpuffer nur neu zeichne, wenn neue Daten da sind - bei einfacher Ver/Aufdeckung wird der bereits bekannte Puffer nur nochmal einkopiert.

Weiter mit dem jetzigen, das oben läuft ja gut - dürfte es zwar nicht, tut es aber:

....

Ok, hier stand bis vor 1 Minute noch der Quelltext von den drei beteiligten Routinen. Ist euch das auch schon öfters so gegangen, sobald ihr das alles strukturiert zusammen geschrieben habt, habt ihr auch den Fehler gefunden? Es ist einfach so, dass sich ein Methodenaufruf eingeschlichen hatte, der sich auf das falsche Display bezog... Dass dabei Dinge passieren die nicht zur Theorie passen ist wohl klar, eh? Damit ist mein zweites Problem definitiv gelöst; nach wie vor interessiert mich natürlich, warum friert meine Applikation während des Synchronize Aufrufes nicht ein???

Vielen Dank für die ausführliche Antwort und Entschuldigung für die verspätete Reaktion!

OK - dann hätte ich mir natürlich wirklich meinen vorherigen Beitrag sparen beziehungsweise anders formulieren können.

Stephan.Woebbeking hat folgendes geschrieben :

...nach wie vor interessiert mich natürlich, warum friert meine Applikation während des Synchronize Aufrufes nicht ein???

Wenn das Zeichnen des Puffers tatsächlich "nur" ca. 0.5 Sekunden dauert, bekommt man das wahrscheinlich nicht mit, wenn man nicht gerade zur selben Zeit etwas mit der Anwendung machen will. Integriere mal ein Sleep(5000), um die Zeichenmethode künstlich zu verlängern und test dann, ob das Programm immer noch bedienbar bleibt.

In der Tat hast du Recht... Damit ist meine Annahme, dass die Zeichenroutine zu signifikaten Verzögerungen der Queue führt wohl nicht korrekt. Die logische Folgerung wäre den ganzen Sums mit den Buffern fallen zu lassen und einfach direkt zu zeichnen - solange ich dabei keine Problem bekomme, richtig?

Ja - ganz genau.
Sollte die Zeichenmethode irgendwann einmal länger werden, dann würde ich die Variante mit dem Zeichnen im Thread und den umschaltbaren Puffern nehmen.

Ok, so werd ich das weiterhin machen. Dann auf jeden Fall vielen Dank allen Beteiligten an der regen Diskussion und Aufklärung!

Stephan