<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2013 20:40, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
> Yeah, we need to define API here.  For EGL, it'd be a matter of the EGL<br>
> implementation sending an event in between register_buffer and<br>
> buffer_available, such that when you called eglCreateImageKHR(egl_dpy,<br>
> EGL_WAYLAND_FOREIGN_BUFFER_WL, buffer), it would be able to supply an<br>
> EGLImage.  To go to a SHM buffer would almost certainly require a round<br>
> trip, in order to ensure synchronisation with GL.  (Which would hopefully be<br>
> done by the client rather than the compositor, especially if it involves<br>
> ReadPixels ...)<br>
<br>
</div>Ok, I guess I can see that working.  It still seems somewhat<br>
ill-defined to me, but maybe that's because I just don't know mesa<br>
internals well enough.<br></blockquote><div><br></div><div style>Well, it's the counterpart to the server side: in the compositor, when we bind a wl_buffer with EGL_WAYLAND_BUFFER_WL, 'something' occurs such that the pointer to a Wayland buffer object magically becomes a valid bound EGLImage.  The details are completely implementation-specific; wl_drm passes a GEM handle, other implementations pass file descriptors or physical memory addresses, synchronisation is implementation-specific, etc etc.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One question worth answering: Why don't we just have a<br>
wl_embeded_compositor interface and make the web pages or whatever<br>
clients to this?  It could be a really simple interface.  It really<br>
doesn't take that much work to set up the basics for a compositor.  If<br>
you're worried about having to write code to handle inputs, you'll<br>
have to do that yourself anyway if the client is planning to composite<br>
the foreign surface itself.  I'm not seeing a whole lot of benefit<br>
over the nested compositors approach particularly when you think about<br>
the complexity we're adding.</blockquote><div><br></div><div style>It's a good question.  The main reason for me comes down to this: we have two totally valid usecases, one of which calls for the surface being embedded as a subsurface, and the parent process not being involved beyond that.  If we force the parent process to be involved, we're incurring unnecessary context switches and latency.  So I'm taking it as a given that we need a child buffer attachment to its surface needs to hit the real compositor with no added copies or even context switches.</div>
<div style><br></div><div style>However, the other totally valid usecase calls for in-client compositing through rendering APIs such as GL (e.g. embedding a WebGL scene or video with a CSS transform).  For that case, we need the client to essentially act as a subcompositor.  But getting all that plumbing in is a massive amount of work - especially for every browser which has to implement it - and it means that the two different usecases are hitting totally, totally different paths.  I don't think it'll be a net win in terms of either predictably working, long-term maintainability, or even conceptual clarity.</div>
<div style><br></div><div style>I'll happily accept that the two usecases are orthogonal though, and perhaps with some modifications to the subsurface protocol, we could split the protocols into a simple wl_foreign_subsurface (for the server compositing_mode), and wl_foreign_composited_surface (client compositing_mode) with all the client-side buffer handling.  Would that help?</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"><div class="HOEnZb"><div class="h5">
> But yeah, this is why I split the events: one to provide the new_id for the<br>
> buffer, another to let the client know it was available for use, and then<br>
> all manner of private protocol in between to actually enable those target<br>
> APIs to use the buffer.<br>
><br>
> Thanks for taking a look!<br>
><br>
> Cheers,<br>
> Daniel<br>
><br>
>><br>
>> On Mar 29, 2013 11:06 AM, "Daniel Stone" <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
>>><br>
>>> Hi Jonas,<br>
>>><br>
>>> On 17 March 2013 09:13, Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
>>>><br>
>>>> 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>
>>><br>
>>><br>
>>> I've been thinking about exactly the same thing, but with additional<br>
>>> complications to the usecases.  There are two I think we need to support:<br>
>>>   - export a surface from client A such client B can create a subsurface<br>
>>> with it<br>
>>>   - export a surface from client A such that client B can act as its own<br>
>>> compositor, i.e. being notified of incoming buffers and being able to import<br>
>>> them<br>
>>><br>
>>> The latter is required for things like WebGL where you end up rendering<br>
>>> to a transformed surface.<br>
>>><br>
>>> I do really like the acquire_handle vs. release_handle semantics, but<br>
>>> I've gone a slightly different way here.  For the exporting client (let's<br>
>>> call it the child), the surface becomes a new surface role, which is only<br>
>>> capable of being exported; it can't, e.g., be a shell surface at the same<br>
>>> time.  For the importing client, it gets a new surface type which can either<br>
>>> be used as a child to construct a new surface, or provide the importing<br>
>>> client with notifications that a new buffer has been attached and is<br>
>>> available for usage.<br>
>>><br>
>>> If used in the latter mode, in theory new buffers could be used as<br>
>>> EGLImages or SHM buffers, as well as being attachable to an existing<br>
>>> surface.  To support resizes, the surface would still need an out-of-band<br>
>>> notification that a resize was beginning, as well as the target size, but<br>
>>> the dx/dy/width/height parameters in buffer_available should hopefully be<br>
>>> enough to provide the acknowledgement from the exporter to importer that the<br>
>>> resize has been completed.  In this sense, it works quite similarly to the<br>
>>> wl_subsurface parent vs. independent commit modes.<br>
>>><br>
>>> I've gone the separate object route rather than sharing objects, because<br>
>>> I think that way is seriously painful, and is wide open for abuse, with<br>
>>> multiple clients stepping on each others' toes in an X11 fashion.  I think<br>
>>> having the clean separation is really useful, and has the minimum potential<br>
>>> for anything to go wrong.<br>
>>><br>
>>> So it's a little more complicated (and comes without a proof of concept),<br>
>>> but I think hopefully should cover everything.  Any comments?<br>
>>><br>
>>> Cheers,<br>
>>> Daniel<br>
>>><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>
><br>
</div></div></blockquote></div><br></div></div>