Clarifications around wl_surface.frame and opaque subsurfaces
The spec says:
A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
If compositors implement this strictly (AFAIK only Mutter does ATM), clients using subsurfaces to build an UI have a hard time using wl_surface.frame
, as they often need to request a frame for every (partly) opaque subsurface individually.
Consider e.g. a client that use subsurfaces as overlays - examples here are Firefox and the Gstreamer Wayland sink - and has a big parent surface that is supposed to handle input. wl_surface.set_input_region()
provides a decent way to make the subsurfaces not consume input events. The same unfortunately is not true for wl_surface.frame
. If the client wants a single source for frame callbacks, it can not just request them on the parent surface, as each opaque subsurface may block them.
GTK3 now has a workaround for such issues, allowing multiple callbacks to be requested via gdk_wayland_window_add_frame_callback_surface()
. This however adds overhead and complexity both in the application and the compositor1.
I wonder if we can find a more elegant solution for this problem. The most obvious solutions that came to my mind so far came are:
- Change the core spec to state that surfaces occluded by descendant subsurfaces should still receive callbacks.
- Add a new protocol that allows to make "recursive" callbacks in some way.
I'd happily work on 2. if that's deemed the best solution, but first wanted to hear opinions if a core spec change is not more straight forward (or other ideas come up). So - I'd be supper happy about comments :)
CC: @jadahl, @pq, @daniels, @emersion, @zzag