Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
Nochmal: Weil der Scheduler deutlich zuverlässiger ist was das Einhalten der "Schlafzeit" angeht, da man sich u.a. nicht noch die Messagequeue ans Bein bindet. Die scheint ja, wie der TE schrieb, durchaus etwas anfälliger für Einflüsse, die man nicht in der Hand hat. Das war ja das Problem des TE.
Zudem könnte die Kommentarzeile in der Realität durchaus einige dicke Operationen beinhalten, ich...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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.
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
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...
Forum: GUI-Design mit VCL / FireMonkey / Common Controls
by Medium,
2. Nov 2011
Du sprichst von Threadsicher im Zusammenhang mit einem Timer. Der Timer ist aber kein Thread! Dein Vorhaben würde ich nämlich tatsächlich mit einem (echten) Thread angehen. Mal eine Pseudoklasse:
type
TMyAnimation = class(TThread)
private
FBitmap: TBitmap;
FTargetCanvas: TCanvas;
procedure DrawFrame;
protected
procedure Execute; override;
