[PATCH weston v3 01/13] protocol: add sub-surfaces

[Pekka Paalanen]

On Fri, 26 Apr 2013 11:38:12 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Fri, Apr 26, 2013 at 9:14 AM, Jason Ekstrand
> <jason at jlekstrand.net>wrote:
> 
> > pq,
> >
> > On Fri, Apr 26, 2013 at 7:09 AM, David Herrmann
> > <dh.herrmann at gmail.com>wrote:
> >
> >> Hi Pekka
> >>
...
> >> > How's this?
> >> >
> >> http://cgit.collabora.com/git/user/pq/weston.git/commit/?h=subsurface-wip2&id=0dce7236606e0a433390c970560c3050247c4e60&context=6
> >>
> >> Perfect, that solves all my concerns.
> >>
> >
> > My thoughts were basically the same as David's and those changes
> > solve my concerns as well.  I'm still not sure I'm 100% happy with
> > how it requires you to build strange trees in certain cases.  That
> > said, I think it looks pretty good and certainly good enough to go
> > into weston so we can all start playing with it.  I'm hoping I can
> > get sub-surfaces implemented in my java compositor soonish.
> > Looking good! --Jason Ekstrand
> >
> 
> Pekka asked me to send an e-mail with a little clarification as to
> what I meant by "strange trees".  Consider an EGL video surface with
> SHM CSD (see attachment).  To make things more complicated, let's say
> that the video surface is controlled by an external library or (worse
> yet) is a foreign surface controlled by a different process.  Due to
> current commit behavior and the way commits cascade, the EGL surface
> (which really is the primary surface in this case) can't be used as
> the primary surface.  Instead, you would have to use one of the
> decoration surfaces as the parent surface (again, see the picture).

Thank you, that makes your concern crystal clear.

> One solution to this would be to allow some sort of surface that
> contains no actual pixels but gets mapped anyway.  Right now you can
> hack this with a 1x1 transparent buffer or something similar.
> However, I would rather not see such hacks common place.  One way to
> achieve this would be to have some sort of empty buffer that has a
> size but no data.  Then you could attach one of these empty buffers
> to a surface to get it mapped.

I consider a special empty wl_buffer with fake size a hack, just like
the 1x1 completely transparent wl_buffer, except worse, because it needs
more special protocol to create.

> The other advantage of an "empty buffer" is that, if it's used as the
> main window, could be the full size of the window instead of being
> 1x1.  This simplifies the problem of handling input across
> subsurfaces as you can have the parent surface handle them.  It would
> also allow us (if we wanted) to clip subsurfaces to the parent
> surface without causing any major problems. Not that we necessarily
> should, but it would leave open the option.

The 1x1 buffer could be scaled to any size with a generic crop & scale
extension, but that of course is yet another optional extension to
depend on.

Let's see how others feel about this, is the awkward surface structure
too bad.

Like I said in another email, I'm starting to think we are now
beginning to accumulate hacks on top of hacks, because the original
design turned out to be not flexible enough. We don't have an abstract
window object in the protocol, which might have provided the sub-surface
functionality in a straightforward way. A wl_window, defining what we
now call the surface-local coordinate system, having no content or size
on its own but attach point for an arbitrary number of wl_surfaces,
being the item for role assignment.... but doing that in the shell level
of the protocol instead of core would be problematic for re-usable
components like video sink elements, since it does not provide nesting
with wl_surfaces.

Or maybe we'd need both... a shell level window object--a replacement
for wl_shell_surface, which would not be just an additional interface
to a wl_surface, but an object on its own right. And then wl_subsurface
that I've been developing, to support shell-agnostic nesting.

*sigh* *shrug*


Cheers,
pq