summaryrefslogtreecommitdiffstats
path: root/.github
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2021-04-16 14:55:15 -0500
committerDudemanguy <random342@airmail.cc>2021-04-18 16:45:40 +0000
commit2a1a092bc99883c3fef0402fa06af0290fbb7d19 (patch)
tree34dd7242ad613b331c75ca997827e18bc1772c87 /.github
parent3239e41277173bace5ecc2a22910c4660642429c (diff)
downloadmpv-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 '.github')
0 files changed, 0 insertions, 0 deletions