Window stacking / raising design

[Pekka Paalanen]

On Mon, 16 Jan 2012 19:14:20 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen suggested I come up with a design for the Wayland 
> compositor to control window stacking and raising.

Thank you for writing down your ideas.

> I am pretty familiar with the failures of existing window management in 
> this area and would certainly like to see Wayland do this correctly, and 
> not copy the mistakes of the past.

...

> MAPPED / UNMAPPED
> 
> I am unclear if Wayland will provide any atomic grouping of client 
> requests so that the user never sees any intermediate state of these 
> requests.
> 
> If not, it looks like the ability to make an "unmapped" window is 
> needed. This is because the code to add a surface to wayland is complex 
> and it would otherwise have to be embedded into the "raise" request, so 
> that new dialogs can be added as part of the raise and not temporarily 
> appear in the wrong order.
> 
> Setting up a surface "unmapped" would have no visual effect until that 
> window id is used in a raise request.

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.

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.

Our definitions of window type/state/role are still subject to change,
right now we only have a window type for everything.


Thanks,
pq