[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