Open YaLTeR opened 4 years ago
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:
max_render_time
) The maximum time from frame callback to surface committing a new buffer.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).
Ref https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620
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).