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

@Medium

Ich habe nichts gegen Thread, im Gegenteil, allerdings muss die Hauptarbeit auch im Thread stattfinden, da alle Canvaszugriffe Threadsave gemacht werden müssen macht es halt IMHO auch nur Sinn wenn nicht die Hauptarbeit darin besteht auf dem Canvas zu arbeiten.

Ich hätte als Haupt"arbeit" hier angesehen, dass das (sehr kurze) Zeitintervall zwischen den Bildern möglichst konstant eingehalten wird. Dabei besteht die Arbeit natürlich hauptsächlich aus passend Warten, das ist wohl wahr Dafür erscheint mir der Scheduler aber durchaus auch zuverlässiger als die Messagequeue. Aber gut, bei so kleinen Aufgaben wirds dann fast mehr eine Glaubensfrage ob Thread oder Timer, wobei mir der Thread eben wegen der Flottheit des Intervalls zuverlässiger scheint. Letztlich ist das natürlich auch kein Garant, Windows ist ja (manchmal leider) kein RT OS.