Clarify on commit ordering vs. actually carrying out the update
It was unclear to me if it is allowed to delay and change the order of the actual update of a surface with respect to the commit ordering of unrelated surfaces.
A compositor might want to delay the surface updates until the attached buffer is ready to be used to prevent frame misses.
To minimize the effects of this delay on other clients, the time when unrelated surfaces visibly update might change from the order in which the surface states were committed.
Here surfaces are unrelated if they are not updated atomically together, such as synchronized subsurfaces or through the transactions_v1 protocol.
The reordering could be observable with a screenshot extension or to the user.
Therefore, this seems like a protocol violation as requests are ordered, and commits don't allow such delayed updates with reorders. At least, this is how I interpreted the docs.
However, compositors like Mutter already implement such behavior through MR. It seems reasonable to allow this and add some clarification to wl_surface.commit
that updates can be delayed and reordered for unrelated surfaces.