Jump to content

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


Recommended Posts

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

Link to comment
Share on other sites

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 ;)


Link to comment
Share on other sites

Hello ivan,

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

    //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"
        //do something.

Link to comment
Share on other sites

@[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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...