On Wed, 17 Jun 2015 09:51:04 -0700 Bill Spitzak <spit...@gmail.com> wrote:
> On Wed, Jun 17, 2015 at 9:35 AM, Bill Spitzak <spit...@gmail.com> wrote: > > > 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. > > > > Want to apologize for the top-posting. That is because I am forced to use > the gmail web api now, which seems to encourage it. I think this email is > correctly formatted, with the quoted text at the top and with irrelevant > parts edited out. > > In response to another email, the reason the result is the order given is > that place_below(A,B) is implemented as "put A at the start of the list". No, that really should not be how the code works: http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.c?id=1.8.0#n3423 As you can see, it is indeed list operations like I said. You take the given surface first out of the list, and then add it back after the given reference surface in the list. Judging from these two functions, the list is ordered as the head being the top, and the tail being the bottom. So, as far as I understand the code, it really is "put the surface immediately below the reference surface". Looking at Arnaud's code and the specification for the initial ordering, the original order as surfaces are created is B, R, G. The parent B is created first, then R is set as child to B, and G is set as another child to B, which should lead to B, R, G. (bottom to top) > The first statement produces the list R,G. The second statement then first > adds B to the list, producing either R,G,B or R,B,G or B,R,G. Then it moves > G to the start of the list, producing G,R,B or G,B,R. Arnaud's code: surf[BLUE] = surface_create(ctx, NULL, 100, 100, 0, 0, 0xff0000ff); if (!surf[BLUE]) die("failed to create root surface"); surf[RED] = surface_create(ctx, surf[BLUE], 100, 100, -100, -100, 0xffff0000); surf[GREEN] = surface_create(ctx, surf[BLUE], 100, 100, -50, -50, 0xff00ff00); #if 0 wl_subsurface_place_below(surf[GREEN]->subsurface, surf[BLUE]->surface); wl_subsurface_place_below(surf[RED]->subsurface, surf[GREEN]->surface); #else wl_subsurface_place_below(surf[RED]->subsurface, surf[GREEN]->surface); wl_subsurface_place_below(surf[GREEN]->subsurface, surf[BLUE]->surface); #endif I can't see how you come to your conclusion, would you care to explain? > If place_below(A,B) was implemented as "put A before B in the list" then > the second statement would produce R,G,B or G,B,R. Although it is possible > to produce the expected result, this still allows an unexpected order. I really don't understand what the ambiguity is. As far as I understand, there is no room for interpretation in the specification. That certainly was the intent, anyway. It says what the ordering is when a wl_subsurface is created, and it says what happens on place_above/below. Then, again, I wrote the spec, I know what I mean, so I'm blind to any ambiguities there might be. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
