summaryrefslogtreecommitdiffstats
path: root/video/out/vulkan/context_wayland.c
diff options
context:
space:
mode:
authordudemanguy <random342@airmail.cc>2020-01-30 11:19:22 -0600
committerDudemanguy <random342@airmail.cc>2020-01-31 00:40:44 +0000
commitb926f189388918e623ebda65d6a47a7ab00b9cfc (patch)
tree8f808c4ce6cd17913d011486860ad8272b7c3d6a /video/out/vulkan/context_wayland.c
parent6c2cc20a53618d3de90674d15c737586a041424b (diff)
downloadmpv-b926f189388918e623ebda65d6a47a7ab00b9cfc.tar.bz2
mpv-b926f189388918e623ebda65d6a47a7ab00b9cfc.tar.xz
wayland: remove wayland-frame-wait-offset option
This originally existed as a hack for weston. In certain scenarios, a frame taking too long to render would cause vo_wayland_wait_frame to timeout which would result in a ton of dropped frames. The naive solution was to just to add a slight delay to the time value. If a frame took too long, it would likely to fall under the timeout value and all was well. This was exposed to the user since the default delay (1000) was completely arbitrary. However with presentation time, this doesn't appear to be neccesary. Fresh frames that take longer than the display's refresh rate (16.666 ms in most cases) behave well in Weston. In the other two main compositors without presentation time (GNOME and Plasma), they also do not experience any ill effects. It's better not to overcomplicate things, so this "feature" can be removed now.
Diffstat (limited to 'video/out/vulkan/context_wayland.c')
-rw-r--r--video/out/vulkan/context_wayland.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/video/out/vulkan/context_wayland.c b/video/out/vulkan/context_wayland.c
index a9540411db..83d4617057 100644
--- a/video/out/vulkan/context_wayland.c
+++ b/video/out/vulkan/context_wayland.c
@@ -111,7 +111,7 @@ static void wayland_vk_swap_buffers(struct ra_ctx *ctx)
}
if (!wl->opts->disable_vsync)
- vo_wayland_wait_frame(wl, wl->opts->frame_offset);
+ vo_wayland_wait_frame(wl);
if (wl->presentation)
wayland_sync_swap(wl);