summaryrefslogtreecommitdiffstats
path: root/audio
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-08-05 16:01:26 +0200
committerwm4 <wm4@nowhere>2016-08-05 16:04:57 +0200
commit088a0075c5eb44979181ec294a6681be148c2c4c (patch)
tree941d7eafc2a6e69cb050d29a7a3c199986bc3799 /audio
parent9f70117233c88b6cf4329c93e0d89f56f96acbac (diff)
downloadmpv-088a0075c5eb44979181ec294a6681be148c2c4c.tar.bz2
mpv-088a0075c5eb44979181ec294a6681be148c2c4c.tar.xz
w32_common: don't wait for GUI thread when polling for events
VOCTRL_CHECK_EVENTS is called on every frame. This is by design, and is supposed to check the event queue of the windowing API. With the decoupled GUI thread in w32_common.c this doesn't make too much sense, and the purpose of VOCTRL_CHECK_EVENTS is really reduced to checking event flags. Even worse, waiting on the GUI thread can interfere with playback, since win32 sometimes blocks the event loop (e.g. clicking the window title bar). Change the code such that we really only query the event flags. Use atomics to avoid having to add a new mutex. (We assume we always have real atomics available. The build system doesn't check this properly, and it could fall back to dummy atomics, which are not atomic.) Should help with #3393. Doesn't help if the core happens to send a synchronous request, most commonly via VOCTRL_SET_CURSOR_VISIBILITY or VOCTRL_UPDATE_PLAYBACK_STATE.
Diffstat (limited to 'audio')
0 files changed, 0 insertions, 0 deletions