Zunächst könntest Du die Gemauigkeit auf 0 ( = höchste Genauigkeit ) setzen und die Aufrufhäufigkeit auf 10 mSec

also von
mmResult := TimeSetEvent(50, 10, @TimeCallBack, DWORD(Self), TIME_PERIODIC);
auf
mmResult := TimeSetEvent(10, 0, @TimeCallBack, DWORD(Self), TIME_PERIODIC);

herabsetzen. Wenn Du die Routine nur alle 50 mSec ausführen möchtest, kannst Du intern einen Zähler von 1 bis 5 installieren und nur bei Zähler = 5 ausführen.

Dies löst aber wahrscheinlich nocht nicht das Problem, dass der Timer bei Mausbewegungen pausiert.
Dieses Pausieren habe ich bei Disk I/O auch schon feststellen müssen uns suche nach einer entsprechenden Lösung.

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:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyAnimation = class(TThread)
  private
    FBitmap: TBitmap;
    FTargetCanvas: TCanvas;
    procedure DrawFrame;
  protected
    procedure Execute; override;
  public
    constructor Create(aCanvas: TCanvas);
    destructor Destroy; override;
  end;

implementation

constructor TMyAnimation.Create(aCanvas: TCanvas);
begin
  inherited Create(false);
  FTargetCanvas := aCanvas;
  FBitmap := TBitmap.Create;
end;

destructor TMyAnimation.Destroy;
begin
  FBitmap.Free;
end;

procedure TMyAnimation.DrawFrame;
begin
  FTargetCanvas.Draw(FBitmap.Canvas, ... ...);
end;

procedure TMyAnimation.Execute;
var
  loopBeginTickCount: Int64;
const
  MS_PER_FRAME = 50;
begin
  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;
end;

Nicht die Pixel an dem ungenauen Timer-Interval richten, denn Timer-Events haben eine geringe Priorität ... also nahezu alle anderen Messages werden bevorzugt verarbeitet und ist mal der Rechner und/oder dein VCL-Thread ausgelastet, dann hängt es halt.

Ein Intervall von 50 (bis zu 20 Bilder die Sekunde) sollte ausreichen, aber dabei nicht das X um 1 hochzählen, sondern die tatsächliche Zeit, zwischen den Aufrufen oder von Beginn an, messen und davon abhängig die Position "berechnen".


[add]
Ich würde garkeine Thread verwenden.
Einfach den Timer und immer wenn Zeit ist, wird gezeichnet ... der Thread kann da auch nix machen, wenn keine Zeit vorhanden ist, da er sich ja eh synchronisieren muß.

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