Einzelnen Beitrag anzeigen

Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#5

AW: MouseMove verzögern

  Alt 22. Mär 2016, 20:14
Hardgecodete Intervalle würde ich immer so gut es geht vermeiden. Rechner sind unterschiedlich schnell, der eine verkraftet mehr als der andere. Wenn jemand das Programm in 10 Jahren verwendet, ärgert er sich, weil er unnötig ausgebremst wird, obwohl das Programm seinen Rechner nicht voll auslastet.

Ich habe das Problem so verstanden, dass der Rechner nicht schnell genug ist, um die Aktualisierung bei jeder Bewegung durchzuführen, ohne dass das Benutzerinterface stockt. Da bietet es sich an, den aufwendigen Teil in einen Hintergrundthread auszulagern und asynchron zu aktualisieren, wann immer es eben geht. So bremst man nicht mehr aus als nötig.

Es passiert nicht alles im UI-Thread. Das ganze ist so gedacht, dass der Thread z.B. erst mal alles in ein Bitmap rendert (der aufwendige Teil) und dann im Synchronize nur ein BitBlt macht. Das setzt natürlich voraus, dass das BitBlt nicht der langsame Teil ist.

Angenommen, die Berechnung würde eine Sekunde dauern, dann würde mit deiner Timer-Lösung das Benutzerinterface immer noch ab und zu für eine Sekunde einfrieren, mit dem Thread aber nicht. Ganz so extrem scheinen die Verzögerungen bei Bjoerk zwar nicht zu sein, aber das Prinzip bleibt dasselbe.
  Mit Zitat antworten Zitat