Proposal to change subsurface extension

[Pekka Paalanen]

On Thu, 13 Jun 2013 14:03:26 +0200
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> > On Thu, 13 Jun 2013 12:35:36 +0200
> > John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
> >
> > > I propose the we should change the commit behavior to having
> > > commit on the toplevel wl_surface
> > > commit itself and all it's subsurfaces atomically. Commiting on
> > > subsurfaces should be a no-op.
> >
> > When a component is running asynchronously, constantly sending new
> > state to a sub-surface, how do you guarantee, that a toplevel commit
> > uses a consistent set of state for the sub-surface?
> >
> We either introduce libwayland functions to send requests as a group
> (which basically just holds the wl_display mutex) or hold a mutex
> while we're playing with pending surface state.

I think that is simply not feasible.

> > > That is to allow eglSwapBuffers to be used in subsurfaces, should
> > > you manage to get it to be non-blocking.
> > > This isn't a huge loss since clients only need to atomically
> > > commit all surfaces anyway.
> >
> > No, they don't. We want a component to be able to run independently
> > in normal circumstances when it does not absolutely require
> > synchronization to any other surfaces forming the window.
> >
> > Playing a video should not require the decorations to be committed
> > for each video frame.
> >
> We don't need to avoid synchronization. It's simply desirable.
> However you do realize that almost every call into libwayland
> requires synchronization anyway? All rendering, memory management,
> resizing will require synchronization. Why are you so reluctant to
> introduce some insignificant synchronization given how much it
> simplifies the protocol? It's not for performance since libwayland is
> filled with synchronization and probably many other operations.
> It's because it's too hard to use, since resizing will require much
> more complex and expensive synchronization to work.

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.

Waking up another thread for doing something on behalf of current
thread is the bad thing. For resizing that cannot be avoided, but
fortunately applications are resizing so briefly that it is almost
never.

There is no need to synchronize rendering at all. The only need for
synchronization is for resize-like operations, where several surfaces
need to change atomically.

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.

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

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

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


- pq