This seems like a good idea because it removes a bunch of code duplication with the surface/buffer code paths going forward.
Sway patch: https://github.com/Nefsen402/sway/commit/f6902930501a91ae392674007a9677c3aa62727b
Requires: !3496 (merged)
There are multiple breaking changes:
- Because surfaces are no longer a first class citizen for scenes, there is no longer a
WLR_SCENE_NODE_SURFACEenum. Subsequently, the public getter function
- Surfaces are now built on
wlr_scene_buffer. This means that the
wlr_scene_surfacestruct no longer has a reference to a scene node, but instead the buffer it is based on.
- Functions that use to iterate across surfaces in a scene are gone. They are now replaced with variants that iterate over scene buffers. 06c42c14
wlr_scene_render_outputis now private. It was not a good fit for the API, and it lets us send the wlr_scene_output all the way through so that the
wlr_scene_bufferpresentation signal would get that object type to be consistent with the other signals.
wlr_scene_buffer->surface so that compositors can easily get back the surface. This was the easiest thing leading to the least code churn regarding chasing these breaking changes. The internal wlroots code makes no use of this property.
If we don't like this, there are two ways we can move forward:
- Break all clients even more by removing this property and adding getters on wlr_scene_buffer that replace all missing functionality that compositors still need. This is a lot of work, and may not be thing thing we want anyway.
Add boilerplate that compositors need to do to track these surfaces. A listener function can be added on the wayland server to track all created surfaces. Then the- This won't work as the listener the wayland server provides doesn't give us access to the
wlr_scene_node->datavalue can be populated the way that compositors like. We can't just populate this value for compositors because then it becomes impossible to differentiate a surface and another value the compositor assigns to the data paramater.