On Fri, 26 Apr 2013 11:38:12 -0500 Jason Ekstrand <[email protected]> wrote:
> On Fri, Apr 26, 2013 at 9:14 AM, Jason Ekstrand > <[email protected]>wrote: > > > pq, > > > > On Fri, Apr 26, 2013 at 7:09 AM, David Herrmann > > <[email protected]>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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
