[RFC] protocol: Introduce logical surface protocol
Daniel Stone
daniel at fooishbar.org
Fri Mar 29 09:04:57 PDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130329/cb53f89b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logical-surface.xml
Type: text/xml
Size: 8448 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130329/cb53f89b/attachment.xml>
More information about the wayland-devel
mailing list