[RFC] Sub-surface protocol and implementation v1

[Pekka Paalanen]

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?

> > 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.

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?

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.

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.

Sans input region, what else would a contentless surface need a size
for?

> > 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.

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