Sub-surface protocol

[John Kåre Alsaker]

On Thu, Dec 13, 2012 at 11:47 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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 could also go the other way and add a child pointer, but linked
lists require more operations to do things like raise a surface above
another.

> 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.
I don't see why we have to be able to change the surface type.
Creating a new surface for each purpose is cheap. I'm not against
being able to do that, I just don't see it as a requirement.

>
> 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.
Floating windows can have interactions with the shell (animations,
etc) while subsurfaces are a way to offload rendering work from the
clients and represent a single window.

>
> 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.
We should probably have a way to atomically update multiple wl_surface
anyway (which could be shared for subsurfaces and floating windows).
Too bad atomicity wasn't added generically to the wayland protocol. We
wouldn't have to add complexity to the code or protocol.

> 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.
Do you have an example of an UI which require the client to be in
control of the stacking order? If that's really desired it probably
won't hurt if is shared the stacking order protocol with subsurfaces.

>
> 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.
That's mostly wl_surface things which will "just work" for subsurfaces.

>
> 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.
Most existing toolkits alters and redraws for the maximized state or
even resizes already.

I think we all agree that clipping and perhaps eventually scaling,
which the compositor can do more efficiently has nothing to do with
subsurface and should be added to wl_surface.

>
> 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.
I'm not sure what you mean by that.