Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Repaint scheduling #4588
This PR establishes the necessary infrastructure to delay output renders and frame callbacks to reduce the visual latency between a surface committing new contents and the contents being shown on-screen. Additionally, it adds configurable constant delays to individual output renders, and to individual view frame callbacks. The way the code is structured makes it possible to subsequently add some kind of an adaptive mode which figures out the delays automatically for lowest possible latency with minimal dropped frames.
For more details on how this works see how it's done in Weston: this PR does pretty much the exact same thing, except it also adds frame callback delaying. Also see swaywm/wlroots#655 (comment) for my comments after implementing a proof-of-concept of this in rootston.
Currently undergoing dogfooding, thus far seems to work well. I have a test client which renders on frame callbacks and prints the delay from receiving a frame callback and the subsequent presentation time. Using this client, I was able to monitor a drop in latency from a little less than 2 frames on the default configuration to about half a frame on two different setups.
How to set up the constants:
Just found a crash that can happen on output disconnect. In the beginning of
output->wlr_output->block_idle_frame = false;
That's what the idea was for the next step; the properties even allow for a new value like "adaptive" for this potential future behavior.
I'm assuming you're talking about the output property here? I wonder why mpv behaves weirdly with this, maybe they do their own frame delaying which is interfering or something?
I've been noticing mpv freezing video output on me lately (until I move the mouse for example), but I haven't investigated whether it was related to max_render_time. In any case it seems like a bug in mpv if it stops rendering like that. My test client that renders only by subscribing to a frame callback from within the previous frame callback is able to continue rendering fine, even if max_render_time is set to a value that's too low.
After watching a couple hours of videos with max_render_time switched off without issues, I can say that it's most likely related. I'll note that I'm using mpv 0.29.1 with wayland, gpu-hq and display-resample. I still believe it's not a sway issue as everything else works fine.