diff options
author | Dudemanguy <random342@airmail.cc> | 2022-06-10 11:49:38 -0500 |
---|---|---|
committer | Dudemanguy <random342@airmail.cc> | 2022-06-19 18:13:55 +0000 |
commit | 3d459832a88a9bd2835b339cf6ca98f84aad0115 (patch) | |
tree | aa1700e19dfd03239d08d2e4ac22d9a00565606e /wscript | |
parent | ceade3493045898a30f0da1bbb639552447ffcdf (diff) | |
download | mpv-3d459832a88a9bd2835b339cf6ca98f84aad0115.tar.bz2 mpv-3d459832a88a9bd2835b339cf6ca98f84aad0115.tar.xz |
x11: support xorg present extension
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
Diffstat (limited to 'wscript')
-rw-r--r-- | wscript | 1 |
1 files changed, 1 insertions, 0 deletions
@@ -534,6 +534,7 @@ video_output_features = [ 'xscrnsaver', '>= 1.0.0', 'xext', '>= 1.0.0', 'xinerama', '>= 1.0.0', + 'xpresent', '>= 1.0.0', 'xrandr', '>= 1.2.0'), } , { 'name': '--xv', |