[RFC Weston 00/10] Sub-surfaces v2

[Pekka Paalanen]

On Wed, 6 Mar 2013 12:58:58 -0800
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On 22 February 2013 07:07, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > The biggest improvement over v1 is that we have some thought-out
> > commit behaviours. It is possible to resize a window so that all
> > surfaces stay in sync on screen, and it is also possible to have
> > sub-surfaces running on their own (i.e. without commit the
> > parent surface, too).
> >
> 
> One thing I noticed is that a subsurface is defined to be mapped as soon as
> it has a valid buffer attached, and its parent is mapped.  Presumably this
> means that if:
>   - the parent window is already mapped
>   - the child is brought into being, and attaches a buffer as part of this
>   - a subsurface is created for the child
> 
> then the subsurface will be mapped before the parent has had a chance to
> either repaint itself, or even call set_position.  So maybe that's
> something we need to look at for the embed (as opposed to decoration) case,
> either with an explicit map request, or just adding 'and set_position has
> been called' to the list of map conditions.

I think the parent-cached commit mode, which also happens to be the
default, takes care of that:
1. main surface A created and mapped, as usual, is on screen
2. create wl_surface B
3. make B a sub-surface, with A as its parent, gets parent-cached
commit mode
4. start feeding frames continously to wl_surface B, calling B.commit
and all
5. send wl_subsurface.set_position for B
6. update A, and A.commit

You can do steps 3-5 in any possible order, and it is guaranteed that
the surface B will be mapped only at step 6.

To have an effective attach (on B), you have to B.commit, but what
B.commit does depends on the commit mode, so it is not effective
until the parent is committed while in parent-cached mode.

Also, a wl_surface without any role will not get mapped under desktop
shell. Is it ok to rely on the shell like this, or should we support
shells that map "anonymous" surfaces?

OTOH, is it really too much to require, that you create the
wl_subsurface before committing the first buffer to the
sub-surface's wl_surface?

> It's also undefined what the commit_mode is for a new wl_subsurface object
> - and having the commit mode initially set to parent-cached might be enough
> to get around the map issue.  Also, if the commit mode is parent-cached,
> changes are made which are put into the cache, and commit mode is then
> changed to immediate before the parent is committed, will the cached
> changes be committed? It's about the only semantics I can think of which
> really make sense for this.

Yes, I flush the cache always, when a commit-to-current-state happens.
I should add a mention about that.

I'm very happy you saw that corner case from the spec ;-)

> This might all be fixed in the implementation, but it's not clear from the
> spec.

Default commit mode is mentioned here:
http://cgit.collabora.com/git/user/pq/weston.git/tree/protocol/subsurface.xml?h=subsurface-v2#n207

But maybe better move it to the general description.

> - Input events still very much unexplored. The demo just punts
> >   them.
> >
> 
> At the very least, we're going to need flags on enter/leave events to note
> when the pointer left towards a subsurface.

Why exactly?

The client will receive an enter for the sub-surface as the very next
thing.

If it is about the race of an app repainting between leave and enter,
we have the same problem elsewhere, too, and should solve it globally,
and I'd like krh's input on that. I can imagine we will hit the same
problem in some shell use cases, too, e.g. keyboard focus entering a
menu or tooltip surface.


Thanks,
pq