On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone <[email protected]> wrote: > Hi Jason, > > On 29 March 2013 16:55, Jason Ekstrand <[email protected]> wrote: >> >> A few quick thoughts, more to come. First, your get_export_surface has >> two new_id arguments. I don't think that's intended. > > Oops, thanks! >> >> Second, we currently have no way for a client to retrieve data from a >> buffer. This will be a problem for client-side compositing. > > Yeah, we need to define API here. For EGL, it'd be a matter of the EGL > implementation sending an event in between register_buffer and > buffer_available, such that when you called eglCreateImageKHR(egl_dpy, > EGL_WAYLAND_FOREIGN_BUFFER_WL, buffer), it would be able to supply an > EGLImage. To go to a SHM buffer would almost certainly require a round > trip, in order to ensure synchronisation with GL. (Which would hopefully be > done by the client rather than the compositor, especially if it involves > ReadPixels ...)
Ok, I guess I can see that working. It still seems somewhat ill-defined to me, but maybe that's because I just don't know mesa internals well enough. One question worth answering: Why don't we just have a wl_embeded_compositor interface and make the web pages or whatever clients to this? It could be a really simple interface. It really doesn't take that much work to set up the basics for a compositor. If you're worried about having to write code to handle inputs, you'll have to do that yourself anyway if the client is planning to composite the foreign surface itself. I'm not seeing a whole lot of benefit over the nested compositors approach particularly when you think about the complexity we're adding. > But yeah, this is why I split the events: one to provide the new_id for the > buffer, another to let the client know it was available for use, and then > all manner of private protocol in between to actually enable those target > APIs to use the buffer. > > Thanks for taking a look! > > Cheers, > Daniel > >> >> On Mar 29, 2013 11:06 AM, "Daniel Stone" <[email protected]> wrote: >>> >>> Hi Jonas, >>> >>> On 17 March 2013 09:13, Jonas Ådahl <[email protected]> wrote: >>>> >>>> A logical surface is a special kind of surface that never gets its own >>>> buffer attached, or opaque region set etc. It is obtained by using a >>>> surface handle that can be shared in some way between clients. A handle >>>> is a server wide unique identifier retrieved from the server given a >>>> real surface. Currently a logical surface is limited to only be usable >>>> as a sub-surface. >>> >>> >>> I've been thinking about exactly the same thing, but with additional >>> complications to the usecases. There are two I think we need to support: >>> - export a surface from client A such client B can create a subsurface >>> with it >>> - export a surface from client A such that client B can act as its own >>> compositor, i.e. being notified of incoming buffers and being able to import >>> them >>> >>> The latter is required for things like WebGL where you end up rendering >>> to a transformed surface. >>> >>> I do really like the acquire_handle vs. release_handle semantics, but >>> I've gone a slightly different way here. For the exporting client (let's >>> call it the child), the surface becomes a new surface role, which is only >>> capable of being exported; it can't, e.g., be a shell surface at the same >>> time. For the importing client, it gets a new surface type which can either >>> be used as a child to construct a new surface, or provide the importing >>> client with notifications that a new buffer has been attached and is >>> available for usage. >>> >>> If used in the latter mode, in theory new buffers could be used as >>> EGLImages or SHM buffers, as well as being attachable to an existing >>> surface. To support resizes, the surface would still need an out-of-band >>> notification that a resize was beginning, as well as the target size, but >>> the dx/dy/width/height parameters in buffer_available should hopefully be >>> enough to provide the acknowledgement from the exporter to importer that the >>> resize has been completed. In this sense, it works quite similarly to the >>> wl_subsurface parent vs. independent commit modes. >>> >>> I've gone the separate object route rather than sharing objects, because >>> I think that way is seriously painful, and is wide open for abuse, with >>> multiple clients stepping on each others' toes in an X11 fashion. I think >>> having the clean separation is really useful, and has the minimum potential >>> for anything to go wrong. >>> >>> So it's a little more complicated (and comes without a proof of concept), >>> but I think hopefully should cover everything. Any comments? >>> >>> Cheers, >>> Daniel >>> >>> _______________________________________________ >>> wayland-devel mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
