[RFC] protocol: Introduce logical surface protocol

Sat Mar 30 18:36:53 PDT 2013

Hi,

On 30 March 2013 20:40, Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone <daniel at fooishbar.org>
> wrote:
> > 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.
>

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.

> 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.

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.

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.

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?

Cheers,
Daniel

> > 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" <daniel at fooishbar.org> wrote:
> >>>
> >>> Hi Jonas,
> >>>
> >>> On 17 March 2013 09:13, Jonas Ådahl <jadahl at gmail.com> 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
> >>> wayland-devel at lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130331/0132e8e8/attachment.html>