Z-index

[danielribeiro]

There is no way to control z-index now (beside removing and adding everything in the right order). It would be nice to have control over the z-index conceptual property in a concrete and easy way.

[mikechambers]

Check out Container.addChildAt():

http://easeljs.com/docs/symbols/Container.html#addChildAt

(Stage extends Container).

Does this do what you are looking for?

Also, if you re-add an existing child to the stage, it will move it to the top of the z-index.

i.e.

var a = new DisplayObject();
var b = new DisplayObject();

stage.addChild(a);
stage.addChild(b);//b is on top
stage.addChild(a);//a is on top

[danielribeiro]

Yes, but this is not anywhere as simple as
a.zindex++

Not only CSS and html and javascript can set zindex, but so does flex.

[mikechambers]

Maybe I am missing something, but the Flex example looked similar to the EaselJS API:

idParentCanvas.setChildIndex(idChildCanvas, newIndex );

Could you suggest the API you think would work better, and we could consider that.

[danielribeiro]

The last example goes like this:

    private function changeZIndex( direction:int ): void {
        var newIndex:int = idParentCanvas.getChildIndex(idChildCanvas) + direction;

        if( newIndex >= 0 && newIndex < idParentCanvas.numChildren ) {
            idParentCanvas.setChildIndex(idChildCanvas, newIndex );
        }
    }
    <mx:Button label="Move Up"  x="10" y="10" click="changeZIndex(1);"/>
    <mx:Button label="Move Down"  x="92" y="10" click="changeZIndex(-1);" />

So, taking out the horrible xml verbose noise, it can be simpler.

[gskinner]

Having worked extensively with both relative and absolute depths, I would much prefer to stick with relative depths. They have less overhead, and are (in general) easier to work with. That said, we do provide sortChildren, which would make it fairly straightforward to implement a z-index system if you'd like one.

The changeZIndex example above is functionally identical to addChildAt, with a range check added. This is what it would look like in EaselJS:

if (index >= 0 && index < container.getNumChildren()) {
    container.addChildAt(child, index);
}

[danielribeiro]

Yes, but if I have 5 types of N elements, on the screen, each having a different z-index, adding another element will take O(N), O(NlgN) if sorting is needed (well, can be back to O(N) using linear time sorting algorithms). Using a better data-structure, such as a Hash the takes a z-index and points to a list of elements, changing the z-index of any element and adding/removing any element would take only O(1).

But ignoring performance, it keeps the user design simpler. For instance, you can do all easeljs does in pure canvas. It is just not simple. Or convenient.

[enriko-riba]

I know this is rather old but this issue is a real showstopper for more complex scenes.
As mike pointed out it is possible to emulate a dynamic Zindex via addChildAt() but that would require the user to maintain a separate Zindex property, handle all stage.add/remove (to fixup indices), sort on each frame or maintain a dirty flag and sort only after Z has changed.
While all this can be done it is very cumbersome, not maintainable and feels kinda hacky.

Is it possible that everyone is coding platformers where the Zindex is only marginally important?

EDIT:
The desired behavior is:

1. allow assigning an arbitrary Z index (range 0-max value - not limited to a contiguous sequence from 0-numOfChildren-1)
2. internally resort objects based on Z index (before next tick but only after a Z has changed)
3. take care when inserting new objects that the Z list updated accordingly (so an expensive sort is not done on every addChild)
4. render stage objects based on the Z index list

[gskinner]

while conceptually different than what CSS devs are used to, relative depths is more flexible, vastly more efficient (for the reasons stated by enriko), and easier to extend & maintain.