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 firstname.lastname@example.org
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.