Window stacking / raising design
spitzak at gmail.com
Wed Jan 18 10:39:00 PST 2012
Pekka Paalanen wrote:
> Unmapped surfaces never occlude anything, since they are invisible. In
> your case, if you first raise W, then map B, you might see a full W,
> and then B appearing on top of it. No any other surface content can
> flash inside W. Is the temporary showing of full W before B appears
> on top a problem?
The problem I am trying to solve is when W is below unrelated surface C,
and the raise action must also make dialog box B appear. The areas of B,
C, and W all intersect.
If W is raised first, the area of intersection of W and C will be
changed to show W. When B is mapped, a portion of this area will be
changed a second time to show B. Thus the intersection area has more
than one transition, which violates Wayland's design goal of having
perfect update everywhere.
> I wonder, how does it work, if a client has several mapped surfaces,
> and wants to rearrange them all by raise. On which buffer attach would
> we execute the raise?
It would have to delay until all of them are attached. I guess
internally the server would still have to have an "unmapped" state on
the surface but it would not last long.
The compositor is also allowed to finish the raise if the client does
something unexpected. It is possible that it will finish the raise on
any action from the client other than an attach.
> Currently, unmapping is done by destroying the surface, since we have
> no protocol to hide a surface. Hmm, to think of it, I'm not sure what
> happens, if you try to attach a NULL buffer to a surface, maybe we just
> don't handle that.
It seems that there is a surface id that can be preserved even when
there is no attached buffer. This is the state the surface is in after
the compositor allocates the id but no attach has been done. It may be
useful to return to that state. I think that destroying the surface is
also ok, however.
More information about the wayland-devel