<div dir="ltr"><div>The problem is that the way it works is *not* a tree, but some kind of list.<br><br></div>As described the following code:<br><br><div>wl_subsurface_place_below(RED->subsurface, GREEN->surface);<br></div><div>wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);<br></div><div><br></div><div>Produces the order GREEN, RED, BLUE instead.</div><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 7:20 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 16 Jun 2015 23:47:03 +0800<br>
Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
<br>
> On Tue, Jun 16, 2015 at 04:46:55PM +0200, Arnaud Vrac wrote:<br>
> > Hi,<br>
> ><br>
> > I'm wondering if a behaviour of weston related to subsurfaces is either a<br>
> > bug or intended. The protocol description is not clear on what happens in<br>
> > the following cases:<br>
> ><br>
> > Suppose I have a shell surface (BLUE) and two subsurfaces (RED, GREEN). I<br>
> > want to stack them to I get RED, GREEN, BLUE from bottom to top.<br>
> ><br>
> > If I do:<br>
> ><br>
> > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);<br>
> > wl_subsurface_place_below(RED->subsurface, GREEN->surface);<br>
> ><br>
> > It works, but if I do:<br>
> ><br>
> > wl_subsurface_place_below(RED->subsurface, GREEN->surface);<br>
> > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);<br>
> ><br>
> > The order is GREEN, RED, BLUE instead.<br>
> ><br>
> > Logically the sibling relative order should be kept in the second case, but<br>
> > it's not. The protocol is not clear on what should happen, what is the<br>
> > expected result ?<br>
><br>
> The protocol says "This sub-surface is taken from the stack, and put<br>
> back just above the reference surface, changing the z-order of the<br>
> sub-surfaces." Considering this, if you first placed a surface below<br>
> another, placing again, that relationship may have been broken by the<br>
> new operation. In other words, the "tree" is not moved, just the<br>
> subsurface you placed.<br>
<br>
</div></div>Something here makes my brain hurt...<br>
<br>
Let's start with a stack from bottom to top:<br>
B, R, G (or equally: B, G, R)<br>
<br>
> > wl_subsurface_place_below(RED->subsurface, GREEN->surface);<br>
<br>
Take R out:<br>
B, G<br>
Put R below G:<br>
B, R, G<br>
<br>
> > wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);<br>
<br>
Take G out:<br>
B, R<br>
Put G below B:<br>
G, B, R<br>
<br>
But that's not what you got.<br>
<br>
I used to think of the stacking of parent with its immediate children<br>
as an ordered list of { parent, immediate children }. I can't recall<br>
the design discussion since it was years ago, but that's what we ended<br>
up with.<br>
<br>
<a href="http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.h#n945" rel="noreferrer" target="_blank">http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.h#n945</a><br>
<br>
Unfortunately I don't think I can dive into this right now.<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div>