Skip to content
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

Open
YaLTeR opened this issue Nov 17, 2019 · 3 comments
Open

Automatic adjustment of repaint delays #4734

YaLTeR opened this issue Nov 17, 2019 · 3 comments
Labels
enhancement New feature or incremental improvement

Comments

@YaLTeR
Copy link
Contributor

YaLTeR commented Nov 17, 2019

#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).

@emersion emersion added the enhancement New feature or incremental improvement label Nov 18, 2019
Tommoa added a commit to Tommoa/dots that referenced this issue Dec 3, 2020
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.
@emersion
Copy link
Member

@YaLTeR
Copy link
Contributor Author

YaLTeR commented Dec 11, 2020

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:

  • The minimum time from DRM buffer swap to successful flip (an estimate hopefully generic enough to take into account e.g. varying GPU workload).
  • The maximum time from start of compositing to buffer swap.
  • (for per-surface 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. :)

@emersion
Copy link
Member

emersion commented Feb 8, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or incremental improvement
Development

No branches or pull requests

2 participants