This fixes weird freezes because of frame_redraw_callback() not being
called from the main thread when it should with weston's toy toolkit.
It's also safer to know that frame_redraw_callback() will always be
called from our display thread... Otherwise it could be called after
the sink has been destroyed for example.
We are not supposed to redraw until we receive a frame callback and this
is especially useful to avoid allocating too many buffers while the
window is not visible, because the compositor may not call wl_buffer.release
until the window becomes visible (ok, this is a wayland bug, but...).
This is achieved by adding an extra reference on the buffers, which does
not allow them to return to the pool. When they are released, this reference
is dropped.
The rest complexity of this patch (hash table, mutex, flag, explicit release calls)
merely exists to allow a safe, guaranteed and deadlock-free destruction sequence.
See the added comment on gstwaylandsink.c for details.
This is the initial implementation, without the GstVideoOverlay.expose()
method. It only implements using an external (sub)surface and resizing
it with GstWaylandVideo.
The reference to the sink is not really needed anyway in waylandpool,
what matters basically is that the display is active as long as the
pool is active, so we really want to reference the display object
instead of the sink.
Wayland interface could offer two buffers pixels formats: WL_SHM_FORMAT_XRGB8888 and WL_SHM_FORMAT_ARGB8888.
Update waylandsink to support them and check if the format is really available.
https://bugzilla.gnome.org/show_bug.cgi?id=702112
Defer certain canvas particulars to the player (or the Wayland
compositor). Before this change, a fullscreen canvas was always
requested. This may not be desirable in all cases.
https://bugzilla.gnome.org/show_bug.cgi?id=690442
- bump wayland version to 0.95.0 which will lead to stable 1.0 release
- avoid memcopy and use propose_allocation for GstBufferPool allocation
- using WaylandBufferPool
- shm: Allocate shm buffers through new wl_shm_pool interface
(the shm buffer allocation is a two step process now: first
allocate a wl_shm_pool, then allocate a buffer from the pool)
https://bugzilla.gnome.org/show_bug.cgi?id=681453
