История изменений

There are two possible contributions to this topic.

The animation system is, for the case of 'threaded' and 'windows' render loops tied to vsync, rather than actual time, so that means that animations will run on its own time, which is close to, but not exactly the same as Date's current time. For animations that spin for a very long time, the animation system and current time, as reported by Date, are expected to drift apart. This is intentional there are no plans to change this. Timer is driven by the Animation system, so it is subject to the same drift.

If 'threaded' or 'windows' render loops are used and buffer swapping is not vsync blocked, then animations will tick as fast as the rendering is able to push out frames. Say a frame completes in 10 ms, well, then animations will advance with 16ms every 8ms, and thus complete a presumed 1 second cycle in 500ms. This is a bit unfortunate, but also a symptom that your system / application is not running optimally as you are in fact rendering two times as fast as your screen can display content, and you should fix your system by enabling blocking vsync.

When using 'basic' render loop, animations and Timer are both driven based on Qt Core timers, which are close to, but also not exactly the same as, actual time. However, these timers are not expected to drift over time, as the vsync based times are.

There are two possible contributions to this topic.

The animation system is, for the case of 'threaded' and 'windows' render loops tied to vsync, rather than actual time, so that means that animations will run on its own time, which is close to, but not exactly the same as Date's current time. For animations that spin for a very long time, the animation system and current time, as reported by Date, are expected to drift apart. This is intentional there are no plans to change this. Timer is driven by the Animation system, so it is subject to the same drift. If 'threaded' or 'windows' render loops are used and buffer swapping is not vsync blocked, then animations will tick as fast as the rendering is able to push out frames. Say a frame completes in 10 ms, well, then animations will advance with 16ms every 8ms, and thus complete a presumed 1 second cycle in 500ms. This is a bit unfortunate, but also a symptom that your system / application is not running optimally as you are in fact rendering two times as fast as your screen can display content, and you should fix your system by enabling blocking vsync.

When using 'basic' render loop, animations and Timer are both driven based on Qt Core timers, which are close to, but also not exactly the same as, actual time. However, these timers are not expected to drift over time, as the vsync based times are.