Hi Pekka On Mon, Apr 29, 2013 at 8:58 AM, Pekka Paalanen <[email protected]> wrote: > 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.
Just as a side-note: a wl_window object doesn't really help here. Assume you have an independent client library that provides two sub-surfaces that ought to be displayed right next to each other (like a video-screen with a video-list-sidebar). You have two choices here: 1) make the video-screen the parent of the sidebar 2) provide two independent sub-surfaces to the caller Maybe the example isn't chosen well enough, but in my eyes both solutions seem wrong. Instead, a dummy wl_surface that can be used by the library as explicit parent would solve this case in a nice way. And always keep in mind that windows are not static. So in Jason's case, switching the window to fullscreen causes the decorations to be hidden and a client would have to de-couple the video-screen from the parent and instead make it the main-window (while fullscreen). So a wl_window object would again require a wl_subwindow object and it would basically just be a wl_surface with a transparent buffer. So why not add a call to bind a dummy 100% transparent buffer to a surface. This allows clients to insert invisible parent windows anywhere they want so it is easier to move/change/restack sub-surfaces. And it allows compositors to handle these surfaces as special surfaces to avoid overhead. Regards David _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
