Window stacking / raising design

[Bill Spitzak]

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.