[RFC] protocol: Introduce logical surface protocol

[Jason Ekstrand]

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" <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/20130329/7da293a2/attachment.html>