This adds a protocol that aims to make it possible to update multiple surfaces atomically. An intended use case is to update a xdg_popup together with its parent, but it can be used for any other reason, including replacing the synchronization included in the subsurfaces protocol.
It works by adding surfaces to a "transaction" object that will, as long as a surface belongs to it, cache any committed state. To apply all the cache state atomically, the client calls the wp_transaction.commit request, causing all the cached state to be applied atomically.
This level of synchronization works on a "lower" level than subsurfaces, as in, a transaction object will consume the state the subsurface defines as being applied, caching it until the wp_transaction.commit request is done.
Signed-off-by: Jonas Ådahl jadahl@gmail.com
I've implemented support in mutter and gtk so far, and will add a weston implementation as soon as we've agreed upon various elementary things, like naming and basic semantics.
One detail that I'll raise up front that needs some further thought is the semantics when a surface is removed from a transaction object. The alternatives I see are
- When a surface is removed from a transaction object, any cached state is applied
- When a surface is removed from a transaction object, any cached state is merged back into the pending state
- When a surface is removed from a transaction object, any cached state is dropped
- When a surface is removed from a transaction object, cached state is applied only if there was a wl_surface.commit since the last wp_transaction.commit
In the current wording, I've gone with alternative 2, simply because it enables clients to "move" a surface from one transaction to another without any implicit wl_surface.commit like behavior. One could argue that it'd be enough to just not commit any cached state before removing, but if removing is implicitly a commit, it may interfere with a ack_configure commit. Another option would be 4., where one explicitly states that it's effectively a no-op from a state application point of view. Anyhow, I'm open for suggestions.