Details
-
Suggestion
-
Resolution: Unresolved
-
P2: Important
-
5.15.6, 6.1.3, 6.2
Description
Current behavior:
(as per https://bugreports.qt.io/browse/QTBUG-91923)
When vsync is disabled, the animation speed is tied to frame time, not clock time. This means that animations are clearly faster or slower depending on the framerate of the rendered scene. This means that when running at <60fps, animations will vary in speed with an application's ability to achieve the reference 60fps. Meaning that animations are running at half speed on a 30hz display, and double speed or more on a high refresh rate display.
With vsync enabled and when Animator falls below the refresh rate of the display, the animations systems falls back to using wall time for speed sync which should prevent any unwanted variation in animation speed. Reasoning behind this is due to the fact that syncing animations to vsync is more accurate that relying on system time, and vsync should generally be enabled to limit wasted CPU cycles and power.
Suggestion:
While outcome of QTBUG-91923 might be valid generally. There are use cases when vsync might be wanted to be disabled for example when tracking user motion input. Using vsync slows down the rendering artificially and as a outcome a lot of the tactile feeling is lost. Running the app with higher frame rates enables access to better quality input data on Windows. When vsync is enabled, input events might be effectively lost while the render thread synchronizes and blocking this longer than needed leads to clusters of input points rather than nice, smooth continuous data. The golden standard of 60 fps and using vsync does not fit for every situation. This concerns only Windows as other platforms work differently and don't suffer from this issue.
The current workarounds involve knowledge of and access to private parts of QtQui, running animations on the GUI thread or by disabling the threaded render loop and using the (slower) basic render loop instead. There should be an option to squeeze every last frame out in a way that Qt does not limit but make use of the gains which can be achieved by using C++ and GPU based rendering. Even though 60 FPS may be enough for example to animate a hover effect on button in normal app, it happens currently at the expense of apps which need perform better than that. There exists a need for an alternative option which has a more modern approach.
Summary:
Feature request is to add a way to turn off vsync and let the app run as fast as possible on any given hardware, but not have things like animation duration break, nor be forced to use the basic render loop. This should be possible regardless of platform used without the knowledge of and access to private parts of QtGui.
Attachments
Issue Links
- relates to
-
QTBUG-58885 Real animation duration not equals to declared time
- Reported