[RFC] Sub-surface protocol and implementation v1

[Bill Spitzak]

Pekka Paalanen wrote:

>> Commit should work the same way. It should commit itself and all it's
>> children. Furthermore it should commit all reordering of it's
>> immediate children.
> 
> Could you give some rationale why this is preferred to any other way,
> for instance sub-surface commit needing a main surface commit to apply
> all the pending state?

This allows a subsurface to be run by an async client that updates it 
without the code running the parent surface having to do anything. Think 
video playback, we sure don't want the video playback to rely on parent 
clients responding to some signal and then calling commit() on wayland 
to get the next frame displayed.

Obviously some clients do want "sync" but since they must be aware of 
and talk to the parent, it seems logical that they are the ones that 
should be modified to not call commit() on their own surfaces.

> How would we implement the dummy parent? There is no concept of a dummy
> surface in the protocol yet, and currently mapping a sub-surface
> depends on mapping the immediate parent.

It does seem like a surface without a buffer would work.

If you require a buffer you MUST make normal and subsurfaces the same 
class, so a client can always make a working arrangement by choosing one 
of the surfaces to be the main one, changing it if that surface has to 
disappear. I think this ability should be supported anyway, even if 
dummy surfaces are.

> As for nesting in itself, it would be simple to just allow it, I think,
> and I have not found any good reason to forbid it yet.

Nesting also specifies the stacking order in an obvious way, including 
"don't care about the order" which other proposals don't support, and 
removes the need for any other api for this.

> Yeah, I have a feeling it would make sense as an orthogonal interface.
> It will be a huge change in any case, since surface size cannot be
> determined by a wl_buffer alone anymore.

I see no problem with the size being specified using a region just like 
the input and opaque areas are now. There can be a fallback to using the 
buffer size if the client does not set it.

> Regarding sub-surfaces, there is the question of whether clipping
> should be controlled within the sub-surface update-commit cycle or
> decoupled from it

If there is clipping then the parent sets it, and changes do not happen 
until a commit on the parent. There must be a way to say "no clipping" 
(which probably means the compositor clips to the output).

Possibly the buffer is intersected with the "size" of a surface, which 
would be controlled by the child, but this is further intersected with 
the clip from the parent.

>>> - should we forbid reparenting?

Reparenting is a REQUIREMENT. The reparented surface is raised to be 
above the new parent if it is below it. Effect requires a commit by the 
new parent.

> Yes, I am fixing the keyboard focus thing right now. I did the server
> part, but now fixing toytoolkit to work right with it is a heavy task.

Please make it so code managing the focus/etc for popup windows and 
menus is reused. This is one area where child windows are far ahead of 
subwindows.