Proposal to change subsurface extension

[John Kåre Alsaker]

On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Libwayland does not synchronize, it only protects the queues for the
> very short moment each time they are modified. It does not cause one
> application component to stall and wait for another component to wake
> up, realize there is something to do, and then do it. Libwayland also
> does not force other threads to wake up, if one thread wants to do
> something. And with the fd locking patches for libwayland-client, that
> will actually be true all the way.
>
The sort of synchronization required is exactly the same as what is needed
by libwayland-client. It needs to send some bytes to the compositor without
being interrupted by other threads. My point here holds unless
libwayland-client gets a communication channel per thread (instead of per
wl_display).

It is very much about performance, and also about avoiding the need for
> component APIs to have a hook for "I want to update my output now"
> which crosses thread boundaries.
>
I'd say adding a mutex (or reusing one in libwayland-client) is probably
faster than doing the additional work required by the compositor in the
current implementation, both being insignificant.


> > If you absolutely can't tolerate any synchronization in that case
> > (which we won't be able to avoid at the libwayland level anyway) a
> > simpler solution is to let wl_surface.commit atomically commit itself
> > and all children recursively. You then commit to two separate
>
> Committing children is a no-go, unless you have a mechanism to
> guarantee a consistent snapshot of the child surface state.
>
Each thread gets it's own wl_surface and possible children. It's up to each
thread to make sure their tree of surfaces is consistent. Each thread would
call commit on their wl_surfaces. You'd only call commit on the top-level
surface when resizing.


> > wl_surfaces in the main and the component thread both of which have
> > the top-level wl_surface as a parent. However to do this we need a
> > way to map a surface without a buffer (or use a transparent one...)
> > since the top-level wl_surface can't have content. It also won't
>
> Funny how no toolkit developer has brought that "problem" up yet.
>
I'm not quite sure which problem you refer to here. The problem of using a
mapped wl_surface with no content to group up wl_surfaces belonging to
separate threads as is rather unique to my solution.

The problem of using a mapped wl_surface with no content and an input
region of non-infinite size is a more general one, which I suspect you're
referring to. I assume you have solved that by clipping the input region to
the extends of the surface and children and moving the content of one of
the subsurfaces into the parent. That solution won't work for my proposal
since it would require synchronization when committing the parent. I
instead have to pick between using a 1x1 buffer (ugh), explicit map/unmap
requests (ugh) and introducing a wl_empty_buffer (meh). I prefer the
wl_empty_buffer option. It also allows me to have input region to be
clipped to the surface content without including children, although I don't
see any reason to do that.


> > allow eglSwapBuffers to work in subsurfaces (if we could even
> > guarantee that it's non-blocking), but that will be rectified by the
> > wl_egl_window_* additions we discussed.
>
> You have pretty high hopes it would go through... shall see, when you
> have an implementation.
>
It's too nice and useful to not go through. It's very easy to implement in
the current form. The question is if we want something more advanced...


>
>
> - pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130613/a6e236bd/attachment.html>