<div dir="ltr">Hi Jason,<div class="gmail_extra"><br><div class="gmail_quote">On 29 March 2013 16:55, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir="ltr"> A few quick thoughts, more to come. First, your get_export_surface has two new_id arguments. I don't think that's intended.</p></blockquote><div style>Oops, thanks!</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir="ltr">Second, we currently have no way for a client to retrieve data from a buffer. This will be a problem for client-side compositing.</p></blockquote><div style>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 ...)</div> <div style><br></div><div style>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.</div> <div style><br></div><div style>Thanks for taking a look!</div><div style><br></div><div style>Cheers,</div><div style>Daniel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir="ltr"><span class="HOEnZb"><span style="color:rgb(80,0,80)">On Mar 29, 2013 11:06 AM, "Daniel Stone" <</span><a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a><span style="color:rgb(80,0,80)">> wrote:</span><font color="#888888"><br> </font></span></p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> <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></div></div><div class="im">_______________________________________________<br> wayland-devel mailing list<br> <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">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></div></blockquote></div> </blockquote></div><br></div></div>