Stacking subsurface siblings

[Bill Spitzak]

The problem is that the way it works is *not* a tree, but some kind of list.

As described the following code:

wl_subsurface_place_below(RED->subsurface, GREEN->surface);
wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);

Produces the order GREEN, RED, BLUE instead.

However if you describe this as a tree, then the first statement is linking
RED with GREEN (one is the parent and one is the child, which is which
depends on how you interpret this). The second statement is linking GREEN
with BLUE. This should not cause any kind of break of the link in the first
statement as it is a different pair of surfaces.

What is actually happening is a list rather than a tree. The first
statement is sorting RED before GREEN in a list. This produces a list of
either R,G,B or R,B,G or B,R,G (all of which satisfy the R<G requirement).
The second statement is sorting GREEN before BLUE in the list. This can be
satisfied with R,G,B or G,R,B or G,B,R. And you can arrive at any of those
three from one of the first three even if you limit the change to movement
of the G item. The rule actually appears to be that place_below(A,B) is the
same as "put A at the start of the list". But trying to alter that rule to
thinks like "insert A right before B in the list" does not help, you still
arrive at unexpected arrangements.

The list can be dealt with but the client pretty much has to resend the
entire stack when any subsurface is created or destroyed, or if it wants to
change the order. The client should use it's own rules to keep track of the
order of the surfaces, and when this changes it updates every single
surface. It should start at the "main" one, and place_below the one below
that, then place_below the one below that, etc, to the bottom-most one. And
it should place_above the one above it, then place_above the one above
that, etc, to the top-most one. You can do the below ones before or after
the above ones, but you must do the calls in the order of starting with the
main and working away, or you can get the wrong order.

This is related very closely to how to deal with modal windows. The only
difference between subsurfaces and modal windows is that the compositor can
put other surfaces between modal windows and whatever they are placed
above/below. I believe this list arrangement can be used to control modal
windows as well, the unexpected thing is that clients have to resend the
entire stacking order on any changes.

On Wed, Jun 17, 2015 at 7:20 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 16 Jun 2015 23:47:03 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
>
> > On Tue, Jun 16, 2015 at 04:46:55PM +0200, Arnaud Vrac wrote:
> > > Hi,
> > >
> > > I'm wondering if a behaviour of weston related to subsurfaces is
> either a
> > > bug or intended. The protocol description is not clear on what happens
> in
> > > the following cases:
> > >
> > > Suppose I have a shell surface (BLUE) and two subsurfaces (RED,
> GREEN). I
> > > want to stack them to I get RED, GREEN, BLUE from bottom to top.
> > >
> > > If I do:
> > >
> > > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);
> > > wl_subsurface_place_below(RED->subsurface, GREEN->surface);
> > >
> > > It works, but if I do:
> > >
> > > wl_subsurface_place_below(RED->subsurface, GREEN->surface);
> > > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);
> > >
> > > The order is GREEN, RED, BLUE instead.
> > >
> > > Logically the sibling relative order should be kept in the second
> case, but
> > > it's not. The protocol is not clear on what should happen, what is the
> > > expected result ?
> >
> > The protocol says "This sub-surface is taken from the stack, and put
> > back just above the reference surface, changing the z-order of the
> > sub-surfaces." Considering this, if you first placed a surface below
> > another, placing again, that relationship may have been broken by the
> > new operation. In other words, the "tree" is not moved, just the
> > subsurface you placed.
>
> Something here makes my brain hurt...
>
> Let's start with a stack from bottom to top:
> B, R, G (or equally: B, G, R)
>
> > > wl_subsurface_place_below(RED->subsurface, GREEN->surface);
>
> Take R out:
> B, G
> Put R below G:
> B, R, G
>
> > > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);
>
> Take G out:
> B, R
> Put G below B:
> G, B, R
>
> But that's not what you got.
>
> I used to think of the stacking of parent with its immediate children
> as an ordered list of { parent, immediate children }. I can't recall
> the design discussion since it was years ago, but that's what we ended
> up with.
>
> http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.h#n945
>
> Unfortunately I don't think I can dive into this right now.
>
>
> Thanks,
> pq
> _______________________________________________
> 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/20150617/d1921510/attachment-0001.html>