Question: Why does Pixi v4 not include any kind of zOrder?

[lolrtz]

Why does any stable release version of pixi not have properties that change the z-order of sprites/containers? I see that the development v5 version has it. Why has it taken 5 major versions before someone realized that zOrder would be a good idea. I'm probably being ignorant but I would like an explanation because it seems pretty important when rendering graphics

[ivan.popelyshev]

Good question!

Its not the only thing that pixijs lacks of. There's no ADDED_TO_STAGE REMOVED_FROM_STAGE stuff from Flash, there's no StageAlign, many other things. All those problems PixiJS leaves to its users to solve, it is believed that they are game-dependant. Sometimes its better to not provide anything instead of getting many messages like "your stuff sucks because it doesnt solve my case".

The problem is that bad zIndex implementation can seriously affect performance. It also hurts versioning - when we provide new solution , old one has to be deprecated, and its better to avoid legacy code.

First universal solution was https://github.com/pixijs/pixi-display/  - and it can sort through the tree, not only in a single container.  At some point I added support of filters , masks and temporary renderTextures. While other renderers just moved to 3d-approach: "make it all flat and add layers". I actually improved Flash stage tree approach without hurting containers.

I also collected several code examples that people used for simple cases: https://github.com/pixijs/pixi-display/wiki#how-to-not-use-pixi-display

Based on all that info @themoonrat came up with simple implementation of sorting inside a single container that doesn't affect performance much.

Now we have all the spectre of sorting solutions. Its time to move to culling problem, I've collected many snippets

 

[[email protected]]

Hello ivan,

PIXIJS does have added to stage and removed from stage, notice the first two "added" and "removed".

//Events:
    //OMG PIXI have the famed ActionScript 2 "releaseOutside" !!! Pixi calls it "mouseupoutside".
    //"added","removed","click","mouseover","mousemove","mouseout","mousedown","mouseup","mouseupoutside","rightclick", "rightdown", "rightup", "rightupoutside"
    Sprite_1.on("click",()=>{
        //do something.
        });

[ivan.popelyshev]

@[email protected]

Its simple child add, not add_to_stage through the tree.

sprite.on('added', function() { console.log('stuff') };

container.addChild(sprite); //added here

stage.addChild(container); // but it has to be  added HERE

That PR was rejected: https://github.com/pixijs/pixi.js/pull/4586

[[email protected]]

Hello Ivan, I apologize if I get your second reply wrong, because it seems you were saying that is no way for a sprite to know it has been ADDED_TO_STAGE/REMOVED_FROM_STAGE.

The example I provided allows for that and it is built into PIXI.js :-D

 

Again if I understand incorrectly, I apologize.

[themoonrat]

I think what Ivan is trying to explain is that yes, there are events for a child being added to a parent, but it's just that.

If you have a parent, and then a child, and a child of the child.... there's a link between the child and child of the child, but no link between the parent and the child of the child. If the child got added to parent2 instead, the child of the child wouldn't know about it.

Which is fine for most occasions and usages. As Ivan said, the v5 solution is a basic way to automatically sort a container and it's children, and nothing else. But his pixi-layers solution is far more advanced and gives access to more powerful features at the expense of changing your usual thoughts on the order of rendering. 

An easy example is imagine you've got players who control tanks in a multiplier game, and each tank has the players name above it so you know who you are battling. Logically, you'd think of a container, that has the tank as a sprite, and a player name as a piece of text. This sounds fine, but tank #2 comes along, has been added to the world container second, so appears over the top of the first tank AND appears over it's player name too! So you want ALL player names to appear over ALL tanks. Ok, well you've got a choice... either player names all sit on a different container separate to all tanks, so you now have to move the names in sync with the sprite, with no parent / child relationship at all.... or you use something like pixi-layers which can let you keep the sprite and player names logically together, but it does magic in the background to change the rendering order away from the default simple render tree.

So that also helps explain why it's not been included before. It's easy to polyfill in your own simple solution, and requirements on what the solution should be differs. How advanced do you make this? pixi-layers solves real problems but can only solve them by breaking the usual easy-to-understand rendering order. Which then effects easy-to-understand interaction order, then filter order... and so on!

So yeah, I based a simple v5 solution on ivan's advice for v4, which just sorts containers automatically in a way that could already done, and it's opt-in, to hopefully not effect any previous custom solutions.