Sub-surface protocol

[Bill Spitzak]

I see no reason for extra objects. What I would do is add a "parent" to 
the normal surface. If it is NULL then it is a "main" surface. If it 
points at another surface then it is a subsurface or a floating window. 
The "parent" can be changed arbitrarily. We must be able to change an 
existing surface from being a "main" to a "subsurface" to a "floating 
window" at any time, so making them different types is not acceptable.

If the parent is another "subsurface" that controls the ordering, in an 
obvious manner without any additional api!

FLOATING WINDOWS:

PLEASE consider reusing this code for "floating windows". THEY ARE THE 
SAME THING!!! The only difference is that the compositor can insert 
other surfaces between floating children and the parent.

This would allow all work done to make subsurfaces not blink and to move 
in lock-step also be used for floating windows, which would address a 
deficiency in all existing window systems. It will also force the 
floating window api to allow the client to be in final control of the 
stacking order, a deficiency in all existing window systems.

Conversely floating windows have a lot of stuff figured out for focus 
and event handling, like grabs, and cooperation between tasks and 
threads. All of this is needed for subwindows so it makes sense to reuse it.

CLIP:

Main windows need clip as well. This is so they can draw edge 
decorations that are clipped off when the window is maximized, rather 
than having to alter their drawings depending on maximization.

More important surfaces should be able to inverse-clip (the clip is 
bigger than the image) for cases where the shell api needs a particular 
size but the client knows that a portion is not visible. We need this to 
clip off any number of edges less than 4 (for maximize 
horizontal/vertical), and to allow subwindows to be used to add the 
borders to a main window that is actually smaller than it tells the shell.