Having two stages

[isfuturebright]

I'm thinking of taking the approach of defining two stages. One for sprites(animated objects) and other for static ones (like backgrounds). Would that make my game faster. Say rendering large but static images at a lower frame rate while small animated objects a higher one?

[ericjbasti]

I'm not sure about the 3d context, but it should definitely help with the standard Canvas 2d context. Generally speaking, drawing to the screen is the most expensive thing your script will do. So rendering a static background and only updating it when something changes will be a huge performance gain... and keep you from needing to worry about dirty-boxing.

[isfuturebright]

I tried setting two setInterval at different speeds but the screen keeps on blinking unless they're both at the same speed. 

[giraluna]

I think the recommended way to do layers is by using DisplayObjectContainers. With the stage object representing the top of the scene and DOCs nested inside it.

 

I wouldn't worry too much about static backgrounds until you run into performance issues. And if you do, PIXI has a lot of tricks like using a RenderTexture to take a static snapshot of a complex scene or by using SpriteBatches.

[isfuturebright]

How does RenderTexture and SpriteBatches work? How come they're faster?

[alex_h]

If you have a DisplayObjectContainer with lots of children with various transforms applied to them then this takes lots of draw calls each time the frame is rendered to draw to canvas. You can skip all of these draw calls by replacing the DisplayObjectContainer with a 'snapshot' of itself thus reducing it to a single draw call. To create this 'snapshot' you use a RenderTexture. This doesn't help if the children need to move around though, only if they are static. For moving around stuff you want to use a Sprite Batch.

 

Sprite Batches (AFAIK) only have an impact in WebGL mode, not canvas mode. I've not used them in Pixi but in Cocos2D or Starling, and I'm assuming they work much the same here. What you do is when you have a lot of sprites all coming from the same texture atlas, and all nested in the same DisplayObjectContainer parent, for example when using a particle system, you switch the parent to be a SpriteBatch rather than a DisplayObjectContainer. This again allows the GPU to render the whole unit  in a single draw call (or something along those lines... basically in a more optimised fashion - don't quote me on this   ) even though this time it is in motion, not a static image. It's all to do with the way textures are uploaded to the GPU, and hence only works with WebGL mode.

[isfuturebright]

Oh. I see. Thanks for the info guys!