diff options
author | wm4 <wm4@nowhere> | 2016-08-05 16:01:26 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-08-05 16:04:57 +0200 |
commit | 088a0075c5eb44979181ec294a6681be148c2c4c (patch) | |
tree | 941d7eafc2a6e69cb050d29a7a3c199986bc3799 /audio/out/ao_wasapi_utils.c | |
parent | 9f70117233c88b6cf4329c93e0d89f56f96acbac (diff) | |
download | mpv-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/out/ao_wasapi_utils.c')
0 files changed, 0 insertions, 0 deletions