summaryrefslogtreecommitdiffstats
path: root/video/out/wayland_common.h
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2020-04-09 11:17:03 -0500
committerDudemanguy <random342@airmail.cc>2020-04-20 21:02:02 +0000
commit055a490cef384922d77367d25cecb813cafa8024 (patch)
treecdaf6146698eeda892c7f4967be89b04971ffc14 /video/out/wayland_common.h
parenta09c7691d7ecaf49666d16f5276b9e7a14197c37 (diff)
downloadmpv-055a490cef384922d77367d25cecb813cafa8024.tar.bz2
mpv-055a490cef384922d77367d25cecb813cafa8024.tar.xz
wayland: use mp_time deltas for presentation time
One not-so-nice hack in the wayland code is the assumption of when a window is hidden (out of view from the compositor) and an arbitrary delay for enabling/disabling the usage of presentation time. Since you do not receive any presentation feedback when a window is hidden on wayland (a feature or misfeature depending on who you ask), the ust is updated based on the refresh_nsec statistic gathered from the previous feedback event. The flaw with this is that refresh_nsec basically just reports back the display's refresh rate (1 / refresh_rate * 10^9). It doesn't tell you how long the vsync interval really was. So as a video is left playing out of view, the wl->last_queue_display_time becomes increasingly inaccurate. This led to a vsync spike when bringing the mpv window back into sight after it was hidden for a period of time. The hack for working around this is to just wait a while before enabling presentation time again. The discrepancy between the "bogus" wl->last_queue_display_time and the actual value you get from the feedback only happens initially after a switch. If you just discard those values, you avoid the dramatic vsync spike. It turns out that there's a smarter way to do this. Just use mp_time_us deltas. The whole reason for these hacks is because wl->last_queue_display_time wasn't close enough to how long it would take for a frame to actually display if it wasn't hidden. Instead, mpv's internal timer can be used, and the difference between wayland_sync_swap calls is a close enough proxy for the vsync interval (certainly better than using the monitor's refresh rate). This avoids the entire conundrum of massive vsync spikes when bringing the player back into view, and it means we can get rid of extra crap like wl->hidden.
Diffstat (limited to 'video/out/wayland_common.h')
-rw-r--r--video/out/wayland_common.h3
1 files changed, 1 insertions, 2 deletions
diff --git a/video/out/wayland_common.h b/video/out/wayland_common.h
index 0c27472e3f..4d26b0130d 100644
--- a/video/out/wayland_common.h
+++ b/video/out/wayland_common.h
@@ -35,7 +35,7 @@ struct vo_wayland_sync {
int64_t ust;
int64_t msc;
int64_t sbc;
- int64_t refresh_usec;
+ int64_t last_mp_time;
bool filled;
};
@@ -75,7 +75,6 @@ struct vo_wayland_state {
int reduced_height;
bool configured;
bool frame_wait;
- bool hidden;
int timeout_count;
int wakeup_pipe[2];
int pending_vo_events;