Hi,
das hast du zwar schon richtig verstanden, aber man sollte da doch ein wenig richtig stellen. Es wird hier so getan als ob ein Thread totalen Overhead darstellt und dich jahrelange Einarbeitung ohne sinn kostet. Also gerade weil du ein so einfaches Problem hast, ist es eigentlich kein Problem das in einen Thread auszulagern. Du musst nur eine Klasse von TThread ableiten und die Execute Methode überschreiben. Das schätze ich mal so mit ca. 5 min Aufwand ab. Sicherlich tippt sich ein Application.ProcessMessages schneller. Bleibt also die Frage nach dem Nutzen.
Also einerseits hast du noch nicht mit Threads gearbeitet und die kommen in nächster Zeit eher nicht aus dem Trend (siehe HyperThreading, MultiCore CPUs usw.). Jedenfalls ist in deinem Fall die eigentliche Schwierigkeit (die Verwaltung konkurrierender Zugriffe) gar nicht vorhanden. Damit kannst du alles was gemacht wird direkt in der Execute-Methode des Threads machen (ohne Rücksicht auf irgendwas).
Application.ProcessMessages verarbeitet alle anstehenden unbehandelten Nachrichten und kehrt dann zurück. Das heißt für dich, sobald diese Funktion aufgerufen wird, wird hier Rechenzeit verbraucht. Wurde dein Form zum Beispiel bewegt, so würde die neue Position jetzt gezeichnet werden. Wurde es nicht bewegt ist trotzdem Rechenzeit weg (auch hier gibt es einen Overhead!).
Bewegst du dein Form, merkt es dein Programm aber erst wenn Application.ProcessMessages aufgerufen wird. Solange du das nicht tust ist dein Form wieder eingefroren. Stellt sich die Frage wann aufrufen? Zu oft führt zu unnötigem Overhead, zu selten führt zu einfrieren. Und dann kommt noch das Problem, dass es auf unterschiedlich schnellen Rechnern unterschiedlich viel Overhead bedeutet.
Mit einem Thread (der in deinem Problem wirklich einfach zu realisieren ist) musst du dich nicht darum kümmern. Der verwaltet die Rechenzeit selbst. Und alle Zeit die zum zeichnen gebraucht wird, wird mit Vorrang (höhere Priorität) zu gewiesen.
Natürlich klappt es mit beiden Wegen (aber siehe auch andere Threads oder Luckies Vorschlag, die Lösung mit Threads ist die eher zu empfehlende). Ich persönlich finde es ist ein wenig der Vergleich zwischen imperativer Programmierung und
OOP in Delphi, du kannst beides machen. Objekte bedeuten im ersten Moment eine Menge overhead (Konstruktoren, Destruktoren,...) aber alles in allem... (natürlich Geschmackssache).