Talk about renderChildren again.

[finscn]

One year ago , I created a PR #3108 .

I want to add the standalone methods about rendering & updating children.
The reason is that user could override them for controlling which sprite/how render the sprite by themself .
example:

There is a DisplayObject-Tree:

containerA
|_____ spriteA
|_____ spriteB
|_____ spriteC
|_____ subContainerA
|_____ ... some other sprites else ...

Sometimes , I want to decide that render which sprite/how render the sprite by myself, like this :

if ( condition1 ） {
    spriteA.renderWebGL(renderer);
    spriteB.renderWebGL(renderer);
} else if ( condition2 ） {
    spriteB.renderWebGL(renderer);
    spriteC.renderWebGL(renderer);
    spriteA.renderWebGL(renderer);
} else  if ( condition3 ）  {
    spriteC.renderWebGL(renderer);
    subContainerA.renderWebGL(renderer);
} else {
    subContainerA.renderWebGL(renderer);
}

The logic above can't be solved by children.sort.
If we extract the method about rendering children , user could override the renderChildrenWebGL & renderChildrenCanvas, it's easy.
there is another use case for custom remove :

container.renderChildrenWebGL = function(renderer) {
    // In one game loop , the render is the last thing about an entity normally.
    // So we could remove the entity in render function.
    var i = 0,
        len = this.children.length;
    while (i < len) {
        var child = this.children[i];
        if (child._toRemove) {
            len--;
            this.removeChildAt(i, child);
            continue;
        }
        child.renderWebGL(renderer);
        i++;
    }
};

---

If no standalone renderChildren , users have to override renderWebGL , renderCanvas, renderAdvancedWebGL , it's complex , in especial renderAdvancedWebGL.
And if the logic in Container.prototype.renderWebGL/renderAdvancedWebGL changed , users have to re-override them again.

But the logic of renderChildrenWebGL & renderChildrenCanvas is very clear , and they won't be
changed.

One year ago , @englercj refused my PR , the reason is performance .
In the past year , I've tested many games (more than 20 games , and more than 100 test-cases) , I found this PR is not the hotspot of performance, even never affected performance.
(BTW, I found the updateTransformChildren is needless , I and my friends never used it).

In the real game , we could use many sprites , but the count of container is not big at the same time( in one game tick), so the 1 function-call won't take the performance down.

So I hope you could think the PR again, please, thank you.

[ivanpopelyshev]

Yeah, agree on renderWebGL, we certainly have to decouple it somehow.

[ivanpopelyshev]

renderChildrenWebGL , remove child in render is VERY bad idea, we need special phase for it for sure. even updateTransform isn't good for it.

I agree that something must be done there but your solution is not enough :(

[finscn]

@ivanpopelyshev , I know the example about remove children is very bad . But the performance of JS is worse.
when there are many children (example in a particle system , more than 10000 children), use a standalone phase for removing , we have to use one more for/while-loop , it's so bad.

So , when I use JS to create a game , for performance , I would do some bad things.

OK, whatever , the example about remove children is not the key point of this PR.

[themoonrat]

@finscn Is this an issue you wish to keep open, or would you like to raise a new issue with another plan of attack? Thanks!

[finscn]

@themoonrat , I don't know anything about v5 and pixi-display / pixi-layer repo , so I can't answer your question now.

[ivanpopelyshev]

@finscn im working on a way to override pixi container methods in a plugin, and your input is significant. Lets close this one, I'll address it later :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.