summaryrefslogtreecommitdiffstats
path: root/DOCS/man/options.rst
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 /DOCS/man/options.rst
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 'DOCS/man/options.rst')
-rw-r--r--DOCS/man/options.rst9
1 files changed, 0 insertions, 9 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index 64ec47dfa7..7b00c51f9c 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -4986,15 +4986,6 @@ The following video options are currently all specific to ``--vo=gpu`` and
Currently only relevant for ``--gpu-api=d3d11``.
-``--wayland-frame-wait-offset=<-500..3000>``
- Control the amount of offset (in microseconds) to add to wayland's frame wait
- (default 1000). The wayland context assumes that if frame callback or presentation
- feedback isn't received within a certain amount of time then the video is being
- rendered offscreen. The time it waits is equal to how long it takes your monitor
- to display a frame (i.e. 1/refresh rate) plus the offset. In general, staying
- close to your monitor's refresh rate is preferred, but with a small offset in
- case a frame takes a little long to display.
-
``--wayland-disable-vsync=<yes|no>``
Disable vsync for the wayland contexts (default: no). Useful for benchmarking
the wayland context when combined with ``video-sync=display-desync``,