<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 29, 2013 at 5:16 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 29 Apr 2013 09:40:56 +0200<br> <div><div class="h5">David Herrmann <<a href="mailto:dh.herrmann@gmail.com">dh.herrmann@gmail.com</a>> wrote:<br> <br> > Hi Pekka<br> ><br> > On Mon, Apr 29, 2013 at 8:58 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>><br> > wrote:<br> > > On Fri, 26 Apr 2013 11:38:12 -0500<br> > > Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br> > ><br> > >> On Fri, Apr 26, 2013 at 9:14 AM, Jason Ekstrand<br> > >> <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>>wrote:<br> > >><br> > >> > pq,<br> > >> ><br> > >> > On Fri, Apr 26, 2013 at 7:09 AM, David Herrmann<br> > >> > <<a href="mailto:dh.herrmann@gmail.com">dh.herrmann@gmail.com</a>>wrote:<br> > >> ><br> > >> >> Hi Pekka<br> > >> >><br> > > ...<br> > >> >> > How's this?<br> > >> >> ><br> > >> >> <a href="http://cgit.collabora.com/git/user/pq/weston.git/commit/?h=subsurface-wip2&id=0dce7236606e0a433390c970560c3050247c4e60&context=6" target="_blank">http://cgit.collabora.com/git/user/pq/weston.git/commit/?h=subsurface-wip2&id=0dce7236606e0a433390c970560c3050247c4e60&context=6</a><br> > >> >><br> > >> >> Perfect, that solves all my concerns.<br> > >> >><br> > >> ><br> > >> > My thoughts were basically the same as David's and those changes<br> > >> > solve my concerns as well. I'm still not sure I'm 100% happy<br> > >> > with how it requires you to build strange trees in certain<br> > >> > cases. That said, I think it looks pretty good and certainly<br> > >> > good enough to go into weston so we can all start playing with<br> > >> > it. I'm hoping I can get sub-surfaces implemented in my java<br> > >> > compositor soonish. Looking good! --Jason Ekstrand<br> > >> ><br> > >><br> > >> Pekka asked me to send an e-mail with a little clarification as to<br> > >> what I meant by "strange trees". Consider an EGL video surface<br> > >> with SHM CSD (see attachment). To make things more complicated,<br> > >> let's say that the video surface is controlled by an external<br> > >> library or (worse yet) is a foreign surface controlled by a<br> > >> different process. Due to current commit behavior and the way<br> > >> commits cascade, the EGL surface (which really is the primary<br> > >> surface in this case) can't be used as the primary surface.<br> > >> Instead, you would have to use one of the decoration surfaces as<br> > >> the parent surface (again, see the picture).<br> > ><br> > > Thank you, that makes your concern crystal clear.<br> > ><br> > >> One solution to this would be to allow some sort of surface that<br> > >> contains no actual pixels but gets mapped anyway. Right now you<br> > >> can hack this with a 1x1 transparent buffer or something similar.<br> > >> However, I would rather not see such hacks common place. One way<br> > >> to achieve this would be to have some sort of empty buffer that<br> > >> has a size but no data. Then you could attach one of these empty<br> > >> buffers to a surface to get it mapped.<br> > ><br> > > I consider a special empty wl_buffer with fake size a hack, just<br> > > like the 1x1 completely transparent wl_buffer, except worse,<br> > > because it needs more special protocol to create.<br> > ><br> > >> The other advantage of an "empty buffer" is that, if it's used as<br> > >> the main window, could be the full size of the window instead of<br> > >> being 1x1. This simplifies the problem of handling input across<br> > >> subsurfaces as you can have the parent surface handle them. It<br> > >> would also allow us (if we wanted) to clip subsurfaces to the<br> > >> parent surface without causing any major problems. Not that we<br> > >> necessarily should, but it would leave open the option.<br> > ><br> > > The 1x1 buffer could be scaled to any size with a generic crop &<br> > > scale extension, but that of course is yet another optional<br> > > extension to depend on.<br> > ><br> > > Let's see how others feel about this, is the awkward surface<br> > > structure too bad.<br> > ><br> > > Like I said in another email, I'm starting to think we are now<br> > > beginning to accumulate hacks on top of hacks, because the original<br> > > design turned out to be not flexible enough. We don't have an<br> > > abstract window object in the protocol, which might have provided<br> > > the sub-surface functionality in a straightforward way. A<br> > > wl_window, defining what we now call the surface-local coordinate<br> > > system, having no content or size on its own but attach point for<br> > > an arbitrary number of wl_surfaces, being the item for role<br> > > assignment.... but doing that in the shell level of the protocol<br> > > instead of core would be problematic for re-usable components like<br> > > video sink elements, since it does not provide nesting with<br> > > wl_surfaces.<br> ><br> > Just as a side-note: a wl_window object doesn't really help here.<br> > Assume you have an independent client library that provides two<br> > sub-surfaces that ought to be displayed right next to each other (like<br> > a video-screen with a video-list-sidebar). You have two choices here:<br> ><br> > 1) make the video-screen the parent of the sidebar<br> > 2) provide two independent sub-surfaces to the caller<br> ><br> > Maybe the example isn't chosen well enough, but in my eyes both<br> > solutions seem wrong. Instead, a dummy wl_surface that can be used by<br> > the library as explicit parent would solve this case in a nice way.<br> ><br> > And always keep in mind that windows are not static. So in Jason's<br> > case, switching the window to fullscreen causes the decorations to be<br> > hidden and a client would have to de-couple the video-screen from the<br> > parent and instead make it the main-window (while fullscreen).<br> ><br> > So a wl_window object would again require a wl_subwindow object and it<br> > would basically just be a wl_surface with a transparent buffer. So why<br> > not add a call to bind a dummy 100% transparent buffer to a surface.<br> > This allows clients to insert invisible parent windows anywhere they<br> > want so it is easier to move/change/restack sub-surfaces. And it<br> > allows compositors to handle these surfaces as special surfaces to<br> > avoid overhead.<br> <br> </div></div>I am sad to realize, that even how ugly it is, dummy wl_surfaces are<br> probably the best way to deal with it. To organize a tree of surfaces...<br> <br> For the shell, you want a wl_surface that is not really a surface, so<br> you can plug and unplug decoration surfaces at will, without giving the<br> primary commit control to any real surface, that might not be in your<br> direct control.<br> <br> So, if we go on that path, could we do without dummy wl_buffers?<br> Could we just remove all the mapping rules from the sub-surface<br> protocol? Then the dummy surfaces would not need any wl_buffer. The<br> problem is, the main surface could not be dummy, as it needs to get<br> mapped by shell, which is triggered by committing a non-NULL wl_buffer.<br></blockquote><div><br></div><div>Really, I think what we need to fix this problem is simply an invisible surface. I don't really care if this is implemented with an invisible buffer or with some sort of "map without buffer" or "attach invisible" request on wl_surface. There are a lot of different ways to do it, but they all achieve the same thing. I don't really want to do any of this 1x1 stuff because that will make a hack a standard code path.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm starting to question the starting points of this whole design:<br> independent library components obviously cannot be independent due to<br> the input protocol, if they ever want input. Trying to make<br> application<->plugin APIs simpler by complicating the protocol.<br> Arbitrary nesting with arbitrary and independent actors (components) on<br> each level.<br></blockquote><div><br></div><div>Yeah, we may want to just say that the main surface gets all the input (That means it has to be full-sized, but if we have invisible surfaces, that's not a problem). Then we can just let the client make the input cascade (the toolkits all do anyway).<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Maybe we should not have wl_surface.commit, or the implicit<br> "roles" for wl_surfaces, that create unobvious error cases. We would<br> have wl_shell_surface.commit; wl_pointer_surface.commit;<br> wl_drag_surface.commit; The ability to attach an arbitrary number of<br> surfaces to a wl_shell_surface, and just one to the others. No nesting,<br> since input does not go to surfaces anyway, it just references them. ...<br> <br> Have I been solving a right problem to begin with?<br></blockquote><div><br></div><div>Yes, but perhaps we should only bother solving it for visual output, not input. That might make it more sensible.<br></div><div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Was it incorrect to assume, that the protocol can be extended piece by<br> piece?<br></blockquote><div><br></div><div>I actually think your "roles" concept is great. As long as we restrict to one role per surface, it should work ok.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Am I getting too existential? Someone hit me with a large trout. :-p<br></blockquote><div><br></div><div>Yes, you are. Done (see IRC).<br></div><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote"> --Jason Ekstrand<br></div></div></div>