mpv/video
Dudemanguy d7f3d1fff7 wayland: refactor dispatching events
This was originally just a bugfix for a race condition, but the scope
expanded a bit. Currently, the wayland code does a prepare_read ->
dispatch_pending -> display_flush -> read_events -> dispatch_pending
routine that's basically straight from the wayland client API
documentation. This essentially just queues up all the wayland events
mpv has and dispatches them to the compositor. We do this for blocking
purposes on every frame we render. A very similar thing is done for
wait_events from the VO.

This code can pretty easily be unified and split off into a separate
function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call
this function in a while loop (which will break either on timeout or if
we receive frame callback from the compositor). wait_events needs to
just check this in case we get some state change on the wakeup_pipe
(i.e. waking up from the paused state).

As for the actual bugfix part of this, it's a slight regression from
c26d833. The toplevel config event always forced a redraw when a surface
became activated again. This is for something like displaying cover art
on a music file. If the window was originally out of view and then later
brought back into focus, no picture would be rendered (i.e. the window
is just black). That's because something like cover art is just 1 frame
and the VO stops doing any other additional rendering. If you miss that
1 frame, nothing would show up ever again. The fix in this case is to
always just force a redraw when the mpv window comes back into view.

Well with the aforementioned commit, we stopped doing
wl_display_roundtrip calls on every frame. That means we no longer do
roundtrip blocking calls. We just be sure to queue up all of the events
we have and then dispatch them. Because wayland is fundamentally an
asynchronous protocol, there's no guarantee what order these events
would be processed in. This meant that on occasion, a
vo_wayland_wait_frame call (this could occur multiple times depending on
the exact situation) would occur before the compositor would send back
frame callback. That would result in the aforementioned bug of having
just a black window. The fix, in this case, is to just do a
vo_wayland_wait_frame call directly before we force the VO to do a
redraw. Note that merely dispatching events isn't enough because we
specifically need to wait for the compositor to give us frame callback
before doing a new render.

P.S. fix a typo too.
2021-05-28 16:11:01 +00:00
..
decode options: Make validation and help possible for all option types 2021-03-28 19:46:27 +03:00
filter vf_sub: restore OSD if removed 2021-05-07 15:01:15 +02:00
out wayland: refactor dispatching events 2021-05-28 16:11:01 +00:00
csputils.c csputils: add mappings for DCI-P3 (ST.431-2) and P3-D65 (ST.432-1) 2020-12-30 20:03:54 +02:00
csputils.h csputils: add MP_CHROMA_TOPLEFT 2020-12-02 01:36:29 +01:00
cuda.c
d3d.c
d3d.h
fmt-conversion.c
fmt-conversion.h
hwdec.c
hwdec.h
image_loader.c
image_loader.h
image_writer.c build: address AVCodec, AVInputFormat, AVOutputFormat const warnings 2021-05-01 22:07:31 +02:00
image_writer.h
img_format.c
img_format.h
mp_image.c
mp_image.h
mp_image_pool.c
mp_image_pool.h
repack.c
repack.h
sws_utils.c sws_utils: work around libswscale corrupting memory yet again 2020-09-17 15:24:27 +02:00
sws_utils.h sws_utils: work around libswscale corrupting memory yet again 2020-09-17 15:24:27 +02:00
vaapi.c
vaapi.h
vdpau.c
vdpau.h
vdpau_functions.inc
vdpau_mixer.c
vdpau_mixer.h
zimg.c csputils: add MP_CHROMA_TOPLEFT 2020-12-02 01:36:29 +01:00
zimg.h zimg: add slice threading and use it by default 2020-07-15 22:59:17 +02:00