wayland/window: Add API to overwrite surface frame requests
This is useful when clients use subsurfaces independently of GDK. For example if a client creates a subsurface that covers a GdkWindow entirely. If this subsurface is opaque, Wayland compositors may not emit callbacks for the surface of the GdkWindow any more. Adding the covering subsurface via this new API ensures the GdkWindow will continue to update in this case.
This is an attempt to provide a solution for a problem clients face if they try to manage their own subsurface on top and without knowledge of GDK, Firefox being the prime example. If such a subsurface covers the GDK surface, compositors may choose to not send surface frame callbacks, leaving GDK frozen if it asked for one 1.
One workaround for this, which is what Firefox currently does, is to not mark the subsurface as opaque. However, this has serious performance implications for the compositor - in case of Mutter, it means at least 100% blitting overhead, usage of slow alpha passes and no usage of more advanced fast paths like direct page flips or overlay planes. As blitting can take up a significant part of the frame time, especially on low-bandwidth GPUs on big monitors (4K), finding a solution for this case would increase FPS for some users, while reducing power consumption for most.
The proposed approach gives a lot of leg space to the consumer, taking into account scenarios where the GDK surface might not be covered by a single surface but by several - something that is planned for Firefox and already used on other platforms (MacOS/Win10).
Alternative approaches considered previously include:
- creating a new Wayland protocol which would group surfaces together in regards to frame callbacks -> increased complexity in the compositor for no obvious reason (from the compositor point of view).
- forking GDK into Firefox -> not feasible ATM
- ditching the subsurface approach in Firefox -> not feasible ATM, would probably require rewriting big parts of FF for Linux
- overwriting libwayland symbols, filtering and rewriting requests from GDK accordingly -> feasible but freaks out people who look at the code
- leaving things as they are -> see above, significant performance penalty, getting bigger as Wayland compositors get better
For a working example, see https://phabricator.services.mozilla.com/D102835 Note that Firefox needs to lock the surface before commiting, in order to be thread-safe.
cc: @jadahl, @ebassi, @matthiasc
P.S.: please take this as a very humble request, born out of desperation :/ I'd hope that things can be done better in a GTK4 world, with this being, well, a hopefully good enough while not too ugly intermediate solution