[Question] About simple and Non-Container Sprite for performance and particle system

[finscn]

The WebGL is a fast renderer , but JS is still not fast enough for thousands of sprites , on mobile especially.

If supply a simple and Non-Container Sprite , Could it supply hight performance ?

[englercj]

Not sure what you are suggesting, but you can use the ParticleContainer instead of a Container and if all your sprites share a texture you will see a significant performance increase because all the transforms are happening on the GPU instead of the CPU.

[ivanpopelyshev]

If you have less than 5000 particles, standart container will be ok.

ParticleContainer has a limitation: you can't use more than 1 texture atlas for sprites inside, and you cant use containers inside of it.

[finscn]

@englercj ,

In current Sprite , if a sprite is NOT a container (most sprite is not container) ,
the code below is still run once :

for (i=0 , j=this.chlidren.length; i<j ; i++){
// ...
}

there are 4 steps :

set i 
read this.children.length
set j
check if  i<j

If you very care about function call ( is like at #3108 (comment) ) , I think you should care about these 4 steps , especially this.children.length.

I think most sprite is non-container in the game , A Sprite Class without any operation about children is a good solution.

.

[englercj]

Then feel free to create a non-container sprite for your project. The core sprite will remain as-is however. We've had this discussion many times over the past years and the community wants it to be a container.

You can easily create your own sprite that doesn't inherit from container if you feel it is important for you application.

[finscn]

@englercj , yes , your decide is very good .
I just mean I hope could add a new Non-Container Sprite , not change Current Sprite to Non-Container .

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