[RFC] Sub-surface protocol and implementation v1

[John Kåre Alsaker]

On Wed, Jan 9, 2013 at 10:53 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 8 Jan 2013 21:50:20 +0100
> John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
>
>> My goals for a subsurface implementation are these:
>> - Allow nesting to ease interoperability for client side code.
>> - Allow a surface without any content to have an input region and let
>> the content be presented in a number of adjacent subsurfaces. This
>> would simplify input handling by a lot.
>> - Allow clients to commit a set of surfaces.
>>
>> On Tue, Jan 8, 2013 at 8:50 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > Hi John,
>> >
>> > thanks for the comments, I have some more questions about your
>> > suggestions.
>> >
>> >
>> > On Mon, 7 Jan 2013 16:56:47 +0100
>> > John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
>> >
>> >> On Fri, Dec 21, 2012 at 12:56 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > we started a discussion about sub-surfaces in Wayland in [1].
>> > ...
>> >> > - how should commits work in parent vs. sub-surfaces?
>> >> 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?
>> We don't want to keep another copy of the surface state around and
>> using dummy surfaces and nesting we can commit a set of surfaces as we
>> please.
>
> Not having to keep another copy of state, yes indeed. Committing a set
> of surfaces however has some corner cases. How do we avoid committing a
> sub-surface that is just in the middle of updating its state, when
> committing the parent? Is it easy enough to avoid in applications?
We use a dummy root surface, with a number of children surfaces which
the client can choose commit.

>
>> > 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.
>> A dummy parent would simply be a surface without content. It would be
>> mapped (by the shell, it should be left out when rendering). It would
>> have the size of it's children, or we could add a way to specify the
>> size of a surface without buffers, which could be shared with a
>> scaling implementation. I'm not very clear on what sizes are used for
>> though.
>
> Yeah, this would be a major change from the current behaviour in the
> protocol.
>
> Currently, a surface becomes mapped, when a) it has content, and b) the
> shell agrees, i.e. a proper window type has been set via wl_shell. For
> sub-surfaces, the condition b) instead requires, that the
> immediate parent surface is mapped. Therefore if parent gets unmapped,
> all its direct and indirect sub-surfaces are unmapped, too, so there is
> an easy way for a client to hide a whole window.
I though it was required to interact with the shell in order to get a
visible surface.

>
> If we allow surfaces to be mapped without content, we need some protocol
> to map it, either in addition or replacing the trigger "attached a
> wl_buffer and committed". That might be a new request. Logically, it
> should also have a counterpart, an unmap request, that works regardless
> of surface content.
>
> Hmm, on another thought, maybe we should just ignore mapped or not for
> sub-surfaces, and simply go with the main surface, which is managed
> directly by the shell. Maybe this is what you were after all along?
Yes, the entire surface group should be mapped/unmapped at once, and
the shell should only interact with the root surface.

>
> That leaves only the problem of size of a contentless sub-surface.
> Input region outside of the wl_surface is ignored, so some size is
> needed to be able to have an input region.
>
> Sure, a contentless surface over a compound window would be a handy
> trick to normalize all input to the compound window into the same
> coordinate space, but I don't think its convenient enough to warrant
> the protocol complications. I'm going to implement input event
> coalescing from sub-surfaces in the toytoolkit, and it doesn't look
> too hard so far.
Handling enter/leave mouse request doesn't look very fun. Also it
wouldn't complicate the protocol very much. The surface's size could
be inferred from it's children or set explicitly. That probably has to
be done for surfaces without content and input region too. I'm not
sure what size is used for besides clip the input region of surfaces.

>
> Actually, since I'm only aiming for the GL or video overlay widget case
> for starters in toytoolkit, I could simply set the input region to
> empty on the sub-surface, and so the main surface beneath would get all
> input.
That is quite a simple case with one sub-surface :)

>
> Sans input region, what else would a contentless surface need a size
> for?
Given that I don't know what size is used for besides clipping the
input region, I can't answer this.

>
>> > Do you have a use case for this?
>> Dummy surface are a useful way to group surfaces. Without them, when
>> deleting the first surface in a group (which would be the parent
>> instead of the dummy surface), you'd have to delete all the surfaces
>> in the group and recreate all but the first. With re-parenting this is
>> less crazy, but still requires quite a few operations.
>
> But if you destroy the first surface of a group (i.e. the main surface
> of a compound window), you are destroying the whole window. Why would
> any sub-surfaces need to be survivable? After all, sub-surfaces have no
> purpose without the window which they form.
My example was where the parent was a sub-surface, but it appears it
won't work at all without a dummy root surface.

>
> I still haven't noticed concrete examples where dummy surfaces would be
> useful. OTOH, it's starting to look like dummy surfaces would pose no
> problems or additional protocol or behavioral changes as long as they
> are sub-surfaces. In other words, the protocol semantics would already
> support dummy sub-surfaces, without explicit enablement.
>
>
> Thanks,
> pq