wp_buffer_release_flushed protocol
Before 2017, most compositors would queue but not flush wl_buffer.release
events. The reasoning for this is that, in most cases, the release event would shortly be followed by a surface frame event, so we could potentially avoid a client wakeup by dispatching the two together.
This proved to not be the case, especially with eglSwapInterval(0)
, and some cases clients can demand with Vulkan WSI. Weston (before 4.0), Mutter (between 3.26.0 and 3.26.1), and wlroots (around the same time), now send the release event as normal so it gets flushed immediately.
In order to deal with the old behaviour, Mesa's EGL and Vulkan WSI implementations will still spam the compositor with roundtrips in a tight loop when they get stuck for buffers, as the roundtrip's done
event is guaranteed to get flushed out.
On newer compositors, we could create and expose a wp_buffer_release_flushed
protocol, with no requests or events, letting the clients know that when waiting for a buffer-release event, they can just block in wl_display_dispatch_queue
, rather than hammering the compositor with round trips. This probably helps pathological situations: when the buffer queue is fully starved, entering into a tight multi-client loop is probably the opposite of helpful.
Cc other compositors implementing this behaviour: @derekf @jadahl @emersion @romangg