Stacking subsurface siblings

Pekka Paalanen ppaalanen at
Thu Jun 18 00:14:26 PDT 2015

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

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

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

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,

	surf[GREEN] = surface_create(ctx, surf[BLUE], 100, 100, -50, -50,

#if 0
	wl_subsurface_place_below(surf[GREEN]->subsurface, surf[BLUE]->surface);
	wl_subsurface_place_below(surf[RED]->subsurface, surf[GREEN]->surface);
	wl_subsurface_place_below(surf[RED]->subsurface, surf[GREEN]->surface);
	wl_subsurface_place_below(surf[GREEN]->subsurface, surf[BLUE]->surface);

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

Then, again, I wrote the spec, I know what I mean, so I'm blind to any
ambiguities there might be.


More information about the wayland-devel mailing list