Ein ausgelastetes System ist ein ausgelastetes System. Klar. Aber ein Thread knallt doch regelmäßiger dazwischen als ein Timer, vor allem wenn man ihm noch ein wenig höhere Prio verpasst - falls die Animation diese Wichtigkeit hat. Streng genommen müsste man daher sogar 2 Thread nehmen: Einen, der die Frames berechnet, und einen der nur zeichnet. Da ich in obigem Beispiel aber die zum berechnen benötigte Zeit im Sleep() berücksichtige, geht das so auch schon ganz gut. (Ich hab's ziemlich genau so auch mehrfach im Einsatz. Das geht schon ganz gut, glaub mir )

Application.OnIdle ???

Feuert auf manchen Systemen nur, wenn man die Maus über einem der Fenster bewegt, oder man im OnIdle von Hand invalidiert, was wiederum zu Hakeln in der Bedienung führen kann. Vor allem, wenn das Erstellen der Bilder etwas mehr als eine halbe Hand voll Zyklen kostet.

nuja, wenn man Done auf false setzt nicht ....

Okay, ja stimmt, das war damals als ich diverse Methoden probiert habe mein Fehler, Mist =) Dennoch finde ich es hübscher, möglichst wenig im Thread der GUI rennen zu lassen. Ich mag Threads mittlerweile sooo gerne, weil sie oft schon von sich aus zu schlankem und stark entkoppeltem Design zwingen. Und gerade bei so schnellen zyklischen Dingen wäre ich heilfroh das weitestgehend aus meinem GUI Kontext raus zu haben. Hat mir einfach jetzt schon zu oft das Leben leichter gemacht, als dass ich es nicht nachdrücklich empfehlen wollen würde

OnIdle wird, so wie es auch in der OH erwähnt wird, nur einmal ausgeführt, wenn alle anderen nstehenden Messages abgearbeitewt wurden.

Bewegt man die Maus ein Stückchen, dann kommen neue Messages rein (z.B. WM_MOUSEMOVE) und wurden diese wieder abgearbeitet, wird OnIdle jedes Mal erneut ausgeführt.




Wie gesagt, um in Delphi auf die VCL-Forms zu zeichnen, muß/sollte man sich im VCL-Thread befinden ... also solange man nicht zusätzliche (längere) Berechnungen im Thread hat, kommt man mit einem Timer IMHO besser.

Zitat von himitsu:

OnIdle wird, so wie es auch in der OH erwähnt wird, nur einmal ausgeführt, wenn alle anderen nstehenden Messages abgearbeitewt wurden.

Done = False sorgt dafür das das Event öfters kommt (solange bis man fertig ist und Done nicht mehr auf False setzt).

Belastet "Sleep" nicht die CPU (while sleeping) ? Danke, werd's mal ausprobieren.

markieren

Delphi-Quellcode:

  
  repeat
    loopBeginTickCount := GetTickCount;
    // FBitmap mit neuem Frame bestücken, was auch immer das ist
    Synchronize(DrawFrame);
    Sleep(Max(MS_PER_FRAME - (GetTickCount-loopBeginTickCount), 1));
  until Terminated;

Nein, Sleep versetzt den aufrufenden Thread im Scheduler in einen "schlafenden" Status, und er wird erst wieder erweckt wenn dessen Timeout (der übergebene Wert in ms) abgelaufen ist. So lange ein Thread schläft, tut er einfach gornix, ausser ein Eintrag (unter vielen) im Scheduler zu sein.

Himi und Bummi: Warum wölltet ihr einen Thread hier so gerne meiden? Es ist kaum mehr Code, und der einzige, dafür flotte Zugriff auf das VCL Formular ist abgesichert. Dafür ist man hübsch entkoppelt, und wird auch dann nicht in die Bedrängnis kommen den GUI Thread zuzukleistern, wenn das Bildberechnen doch mal üppiger wird. Timer haben für mich fast immer einen Beigeschmack von Gefrickel und "so lange es gut geht, Glück gehabt". Gerade bei so kurzen Zykluszeiten! Und SO viel einfacher zu debuggen ist eine mit Timern vollgekleisterte Anwendung auch nicht wirklich