<p dir="ltr">Daniel,<br>
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.<br>

--Jason Ekstrand</p>
<div class="gmail_quote">On Mar 29, 2013 11:06 AM, "Daniel Stone" <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Jonas,<div class="gmail_extra"><br><div class="gmail_quote">On 17 March 2013 09:13, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A logical surface is a special kind of surface that never gets its own<br>
buffer attached, or opaque region set etc. It is obtained by using a<br>
surface handle that can be shared in some way between clients. A handle<br>
is a server wide unique identifier retrieved from the server given a<br>
real surface. Currently a logical surface is limited to only be usable<br>
as a sub-surface.<br></blockquote><div><br></div><div>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:</div><div>  - export a surface from client A such client B can create a subsurface with it</div>

<div>  - 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</div><div><br></div><div>The latter is required for things like WebGL where you end up rendering to a transformed surface.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>So it's a little more complicated (and comes without a proof of concept), but I think hopefully should cover everything.  Any comments?</div><div><br></div><div>Cheers,</div>
<div>Daniel </div></div></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div>