-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic adjustment of repaint delays #4734
Comments
See swaywm/sway#4588 Will need changing when swaywm/sway#4734 is closed. I haven't actually gone and validated that these are the best numbers that I can get, they are conservative estimates.
For the reference, I implemented this in Mutter at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620. See the MR for detailed explanations, but the gist is that I estimate:
So far in my tests it works reasonably well even for heavier workloads in mutter / gnome-shell. Note that in mutter the surface delays are per-surface rather than per-view as in sway (a limitation of manual configuration rather than wlroots).
You beat me to it. :) |
#4588 introduced the ability to set up constant repaint delays for outputs and views in order to reduce visual latency. However, setting them up is a little involved, and we can do better, automatically.
It's important to note that the minimal time between a DRM commit and vblank varies based on the damaged region and possibly other things.
The safe simple first idea to try for the automatic adjustment is: start with 1 millisecond
max_render_time
for outputs, then if a frame was dropped increment it by 1 (with a threshold past which it's just turned off). The main downside is that this method cannot reduce the latency back down when the damaged region reduces (for example, when quitting out of a full-screen game back to calm desktop usage).Another idea is to somehow measure how much time it takes from starting compositing to presentation and use that to compute
max_render_time
. Not sure how and if that would work.For views, similar strategies could be explored. It's actually possible to do even better than the constant delays here as
max_render_time
can only be set on a per-view granularity (for configuration convenience), but automatic adjustment can work on a per-surface granularity (where it should be).The text was updated successfully, but these errors were encountered: