summaryrefslogtreecommitdiffstats
path: root/audio/out
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-09-15 18:42:09 +0200
committerwm4 <wm4@nowhere>2014-09-15 19:19:01 +0200
commit8c002b79d361293bf5ad05df012bb1875d41bd73 (patch)
tree0e7960383ff4278cfaa5f8418ea558eb9752d521 /audio/out
parent930c61b64c58d5b951abeb5de143c00520b89eba (diff)
downloadmpv-8c002b79d361293bf5ad05df012bb1875d41bd73.tar.bz2
mpv-8c002b79d361293bf5ad05df012bb1875d41bd73.tar.xz
x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for map
Some window managers can prevent mapping of a window as a feature. i3 can put new windows on a certain workspace (with "assign"), so if mpv is started on a different workspace, the window will never be mapped. mpv currently waits until the window is mapped (blocking almost all of the player), in order to avoid race conditions regarding the window size. We don't want to remove this, but on the other hand we also don't want to block the player forever in these situations. So what we need is a way to know when the window manager is "done" with processing the map request. Unfortunately, there doesn't seem to be a standard way for this. So, instead we could do some arbitrary communication with the WM, that may act as "barrier" after map request and the "immediate" mapping of the window. If the window is not mapped after this barrier, it means the window manager decided to delay the mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS property on the mpv window, and we receive a PropertyNotify event. If that happens, we always continue and cancel waiting for the MapNotify event. I don't know if this is sane or if there's a better mechanism. Also, this works only for WMs which support this message, which are not many. But at least it appears to work on i3. It may reintroduce flickering on fullscreen with other WMs, though.
Diffstat (limited to 'audio/out')
0 files changed, 0 insertions, 0 deletions