Daniel, A few quick thoughts, more to come. First, your get_export_surface has two new_id arguments. I don't think that's intended. Second, we currently have no way for a client to retrieve data from a buffer. This will be a problem for client-side compositing. --Jason Ekstrand 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
