Stacking subsurface siblings

[Pekka Paalanen]

On Wed, 17 Jun 2015 09:51:04 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On Wed, Jun 17, 2015 at 9:35 AM, Bill Spitzak <spitzak at 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