[RFC] Sub-surface protocol and implementation v1

Bill Spitzak spitzak at gmail.com
Fri Jan 11 13:11:26 PST 2013

My understanding is the reason for the "dummy" surface is to control 
what surfaces are committed. If the rule is that commit commits all 
child surfaces, and you want a window with both "synchronous" and 
"async" child surfaces, you would instead make a dummy surface, and make 
the real surface and all the sync children one child, and all the async 
surfaces other children. Then 'commit' is never called on the dummy, 
instead it is called on the root of the sync tree.

However I really don't like this. What this is doing is definining a 
"commit hierarchy" of surfaces which is independent of the "stacking 
hierarchy" that controls what order they are in. There is also going to 
need to be a "transform hierarchy" and probably a "visibility hierarchy" 
to control when they are visible. The end result is a DAG with typed 
edges, something I do not think we want to communicate between clients 
and wayland because of the complexity.

I believe a *single* tree (not a graph) of surfaces is all that is 
needed. This mostly indicates stacking order: a child must be above it's 
parent. The commit, transform, visibility hierarchies can only be 
subtrees, controlled by bits on the surfaces that basically say "this 
surface uses it's own commit, transform, visibility".

What is most important is that at any moment the client can change the 
parent or any of these bits on any surface, and it can do this before 
any surface is raised, shown, or hidden. This allows the client to 
dynamically rearrange the tree to match behavior that is more 
complicated than can be described by the tree. Most clients will not 
have to do this very often.

Reparenting and removing any distinction between child and parent 
surfaces means that a client can fake a dummy surface internally and 
wayland does not need to support it. The client just rearranges things 
so that one of the visible "child" surfaces acts as the parent. A dummy 
surface with no visible children shows nothing so it does not have to be 
sent to Wayland at all.

So after messing around with designs that have a stacking list similar 
to what is being proposed, I still feel the best approach is the tree.

More information about the wayland-devel mailing list