Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   TimeSetEvent / Canvas / Thread? (https://www.delphipraxis.net/158000-timesetevent-canvas-thread.html)

Bernhard Geyer 2. Nov 2011 12:20

AW: TimeSetEvent / Canvas / Thread?
 
Zitat:

Zitat von himitsu (Beitrag 1133979)
OnIdle wird, so wie es auch in der OH erwähnt wird, nur einmal ausgeführt, wenn alle anderen nstehenden Messages abgearbeitewt wurden.

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

Aremo 2. Nov 2011 12:35

AW: TimeSetEvent / Canvas / Thread?
 
Belastet "Sleep" nicht die CPU (while sleeping) ? Danke, werd's mal ausprobieren.

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;

Medium 2. Nov 2011 12:49

AW: TimeSetEvent / Canvas / Thread?
 
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 :)

Bummi 2. Nov 2011 13:58

AW: TimeSetEvent / Canvas / Thread?
 
@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.

Medium 2. Nov 2011 14:15

AW: TimeSetEvent / Canvas / Thread?
 
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.

Mavarik 2. Nov 2011 14:30

AW: TimeSetEvent / Canvas / Thread?
 
Hmm...

Die Hauptarbeit wird sicherlich das zeichen sein.

Allso zeichne im Thread auf eine TempBMP immer kontinuierlich und löse nur einen Event aus, wenn die Bitmap "fertig" ist.

Über Synconize wird leider immer die Hauptthread angehalten, daher würde ich eine Sendmessage erzeugen und in dieser dann lediglich die TempBMP auf den Canvas kopieren...

Grüsse Mavarik

Medium 2. Nov 2011 14:42

AW: TimeSetEvent / Canvas / Thread?
 
Würde ich im Normalfall auch so tun, aber gerade bei Animationen kann einem die Messagequeue durchaus den Spaß verderben. Und ob ich nun synchronized oder durch eine Message ausgelöst zeichne - in beiden Fallen wird die selbe Arbeit im Hauptthread gemacht. (Und ein Bitmap auf einen Canvas blitten ist nicht wirklich zeitraubend, so lange man jetzt nicht über Full-HD redet.)
Aber grundsätzlich würde ich, wenn es nicht auf die Millisekunde ankommt, auch Notifications in Form von Messages nutzen. (Mache ich auch fast überall in meinen Projekten so.) Daher ein sehr berechtigter Einwand.

Bummi 2. Nov 2011 14:42

AW: TimeSetEvent / Canvas / Thread?
 
@Mavarik

mach Dir mal den Spass mehrere Threads gleichzeitig auf TempBitmaps malen zu lassen und diese Synchronized irgendwo darzustellen/laden.

Ich hatte dabei 90% ausfälle bei den Bitmaps wenn kein Canvas.Lock verwendet wird, das letztlich fast mit dem Arbeiten im Haupthread gleichzusetzen ist ...

Medium 2. Nov 2011 14:46

AW: TimeSetEvent / Canvas / Thread?
 
Das ist aber ein anderes Problem! Ich wäre nichtmals auf die Idee gekommen, mehrere Threads in das selbe Bitmap malen zu lassen :shock:
Für so etwas würde ich mein Bitmap in N Streifen unterteilen, einen Verwaltungsthread die eigentlichen Renderthreads starten, in diesem auf dessen Fertigwerden warten, dann die Streifen im Verwaltungsthread auf ein kombiniertes Bitmap zeichnen, und DAS dann auf den Bildschirm bringen. So hat jeder fein säuberlich seine eigenen Ressourcen, und keiner muss irgendwen locken. (Auch schon so gemacht, für nen Mulitiline/threaded Raytracer.)

Mavarik 2. Nov 2011 14:51

AW: TimeSetEvent / Canvas / Thread?
 
Zitat:

Zitat von Bummi (Beitrag 1134040)
@Mavarik

mach Dir mal den Spass mehrere Threads gleichzeitig auf TempBitmaps malen zu lassen und diese Synchronized irgendwo darzustellen/laden.

Naja so macht das mein Fernwartungsprogramm.

Da werden dann noch über mehrerer Threads die Teile der BMP erst gepackt und dann auf einen Server gestreamt... ;-)

Also denke ich ich weis wovon ich rede... :oops:

Mavarik


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:16 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz