Window stacking / raising design

[Bill Spitzak]

On 01/17/2012 02:32 AM, Pekka Paalanen wrote:

> I think we already have the unmapped feature. In Wayland terms:
>
> 1. A client creates a surface.
> 	The surface is initially unmapped, and not visible.
>
> 2. The client sets the window type (role) of the surface.
> 	Still nothing visible happens.
>
> 3. The client creates a buffer in certain size.
> 	This is the pixel storage, for now unrelated to the surface.
>
> 4. The client renders into the buffer.
>
> 5. The client attaches the buffer into the surface.
> 	This step is where all the work in the compositor happens. If
> 	the surface was unmapped, it becomes mapped. The buffer size
> 	sets the surface size (possible scalings taken into account),
> 	and the surface becomes visible.
>
> This is an example, you could do 3,4 first, then 1,2, then 5.
>
> The raise could happen between 2 and 5.

The problem I am trying to solve is where there already is a window W on 
the screen, and raising it also has to map a dialog box B that should be 
above it.

If the portion of W that will be obscured by B is currently obscured by 
some other window, then the user will see a "flash" of that window when 
it is raised before B is mapped. This is IMHO unacceptable for Wayland.

I agree that the current Wayland idea of equating "a buffer is attached" 
with "mapped" is really nice, which is why I don't like adding a mapped 
state to windows. But your idea means that it may not be necessary:

> Maybe we could use this scheme in a wider sense: all changes to window
> state are cached in the compositor, and applied on the next buffer
> attach. That is what I already proposed for the fullscreen case. I'm not
> sure how it would fit with your multi-surface raise request, though.

That would work. If a raise names an unattached window, the raise is 
deferred until that window is attached to a buffer.

This would actually make your fullscreen results better, for windows 
with dialog boxes, and remove the need for my idea of putting panels 
below normal windows:

1. Client sends request for fullsize for window W
2. Compositor sends configure notify for fullscreen window size
3. Client makes new buffer and draws it for this full size
4. Client sends raise request for W and dialog box B. But this is 
deferred due to the outstanding configure notify. (If the client does 
not send a raise, the compositor can pretend it sent one only for the 
fullscreen window W)
5. Client attaches W. At this point, atomically, W is raised above the 
panel and other windows and resized and B is put atop it.

UNMAPPING:

I now think unmapping is not a problem so it would not have to be part 
of the raise command. Instead the client just does not put the unmapped 
windows in the raise command, and it unmaps the windows *after* the 
raise command is completed. This will not cause any "blink" because no 
portion of these windows that is unexposed will become exposed (to be 
really perfect the client needs to unmap them in back to front order)