Hi, Again I fear we're drifting massively off-topic, but here we go ... On 3 May 2013 18:50, Bill Spitzak <spit...@gmail.com> wrote: > Daniel Stone wrote: >> Subsurfaces are being designed for in-process cases, such as a media >> player inside a browser. Foreign surfaces are intended for >> cross-process buffer/surface sharing, but I think nested compositors >> is actually better for the usecase I had in mind, which is WebKit2. >> So it would be nice if they weren't unnecessarily complex to >> implement. > > The final compositor is able to do the fully optimized compositing of > surfaces into the output frame buffer, including all the work various people > have done to not composite obscured areas. I fail to see how a nested > compositor can take advantage of this except by transmitting all the > individual surfaces to the final compositor.
If that's the goal, then yes. For some usecases however, doing the compositing before and sending one large buffer to the compositor is desirable. > This means that buffers and buffer allocation have to be transparently > passed through the intermediate compositors. I don't think this has been > addressed, and it seems really difficult compared to just reusing the > existing single connection to the server. Again, yes, sometimes. For most stacks, passing the allocation through is fairly trivial, as the allocation is client-driven anyway: the client creates the buffer and then just tells the compositor how to access it. EGL implementations can already proxy buffer allocation with zero interference from us, however: they already have a connection to the parent compositor's display, so they can just pass all allocation requests they might get, up the chain. We do need a little bit more API to support this, but nothing too catastrophic, and nothing more implementationally onerous than the stream-of-buffers foreign surface proposal demanded. > The proposal where the parent task creates subsurfaces and then does some > setup so the child task can draw them seems far more like what webkit is > going to want and use. I really don't think it is. >> I don't think having 'sub-extensions' makes anything more clear: in >> fact, exactly the opposite. > > I'm not describing this right. What I want is to be able to read the > documentation, and see a list of "all the things you can do to a > wl_surface". > > Currently one of the things you can do to a wl_surface is that you can find > the wl_shell object and ask it to create a wl_shell_surface object given a > wl_surface id, and then you can do things to this wl_shell_surface object. > However this is not listed under wl_surface, instead it is listed under two > other sections with no links to them (there are backward links but that is > pretty useless): wl_shell and wl_shell_surface. I think this is extremely > confusing and was probably one of the biggest obstacles I had trying to > figure wayland out. > > What I would like to see is that under wl_surface you see a section that > says something like "wl_scaler:". Listed under that are the methods that are > currently listed under wl_surface_scaler. The title "wl_scaler:" implies all > this information: the actual calling convention is to find the global > wl_scaler object, call a method called get_scaler_surface with the > wl_surface id, and that returns a new object called a wl_scaler_surface, and > you call the listed methods on *this* object. The documentation is now where > a user can find it, and a lot of boilerplate is elided. > > One thing that would help a lot is for there to be a standard as to whether > a wl_foo global object, when asked to create an object for a wl_bar object, > that the object is called wl_foo_bar and not wl_bar_foo. Currently the > wl_shell and wl_scaler disagree about this. Since wl_shell_surface is in > much more than wl_surface_scaler use I recommend standardizing on putting > the global object's type first. OK, so it pretty much looks like just cosmetic/documentation changes - none of which I'm against at all. Obviously we can't break existing protocol though (such as renaming wl_shell_surface to wl_surface_shell), but we can improve the documentation. I'm sure patches for that would be gratefully accepted. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
