diff options
author | Dudemanguy <random342@airmail.cc> | 2021-04-16 14:55:15 -0500 |
---|---|---|
committer | Dudemanguy <random342@airmail.cc> | 2021-04-18 16:45:40 +0000 |
commit | 2a1a092bc99883c3fef0402fa06af0290fbb7d19 (patch) | |
tree | 34dd7242ad613b331c75ca997827e18bc1772c87 /ta | |
parent | 3239e41277173bace5ecc2a22910c4660642429c (diff) | |
download | mpv-2a1a092bc99883c3fef0402fa06af0290fbb7d19.tar.bz2 mpv-2a1a092bc99883c3fef0402fa06af0290fbb7d19.tar.xz |
wayland: workaround hidden state detection badness
The wayland code uses a heuristic to determine whether or not the mpv
window is hidden since the xdg-shell protocol does not provide a way for
a client to directly know this. We don't render with the frame callback
function for various, complicated reasons but the tl;dr is that it
doesn't work well with mpv's core (maybe an essay should be written on
this one day).
Currently, the aforementioned heuristic considers a window hidden if we
miss more frames in a row than the display's current refresh rate
(completely arbitrary number). However, the wayland protocol does allow
for the display's refresh rate to be 0 in certain cases (like a virtual
output). This completely wrecks the heuristic and basically causes only
every other frame to be rendered (real world example: nested sway
sessions).
Instead let's slightly redesign this mechanism to be a little smarter.
For coming up with the vblank time (to predict when to timeout on the
wait function), instead use the vsync interval calculated using
presentation time. That is the most accurate measure available. If that
number is not available/invalid, then we try to use the vsync interval
predicted by the presentation event.
If we still don't have that (i.e. no presentation time supported by the
compositor), we can instead use the old way of using the expected vsync
interval from the display's reported refresh rate. If somehow we still
do not have a usable number, then just give up and makeup shit. Note
that at this point we could technically ask the vo for the estimated
vsync jitter, but that would involve locking/unlocking vo which sounds
horrifying. Ideally, you never reach here.
See https://github.com/swaywm/wlroots/issues/2566 for the actual target
of this fix. wlroots uses presentation time so in practice we are mostly
just using that calculated vsync interval number.
Diffstat (limited to 'ta')
0 files changed, 0 insertions, 0 deletions