Looking for Efficient Rendering Tips

[pongstylin]

First, a bit of context.  Most of the animations in my app involve moving a piece on a game board from point A to point B or showing a piece attacking another piece.  Each frame for a piece is composed of multiple sprites.  With a few exceptions, the sprites for a given piece type are all contained within a single spritesheet - one spritesheet per piece type.  I made sure the spritesheet itself uses POT dimensions although each frame has arbitrary dimensions.

Before running a move or attack sequence that involves one or more pieces on the board, I pre-compile the frames for the entire animation.  Conceptually, this involves building an array of PIXI container objects for each piece.  Each container in the array is the root of a tree of containers and sprites that provide a complete picture of the piece in a single frame.  All tints, color-matrix filters, positions, and scaling are pre-applied.  At that point, drawing a frame involves swapping out the root containers for each piece involved in the animation and then rendering the stage.  The rest of the stage remains unchanged.  Once the animation ends, all of the pre-compiled containers and sprites are destroyed and not reused in whole or in part in subsequent animations.

If you have more questions regarding the context, let me know.  So while I ensured the stage manipulation during animation execution is very efficient, I want to make sure stage rendering is efficient as well.  As things stand right now, rendering the stage can take 10 milliseconds on my laptop even if nothing about the stage has changed.  Even though the game runs at 12fps allowing for 83ms of rendering time, I've suffered from intermittent skipped frames when playing the game on my phone.  I haven't proven yet that the skipped frames on my phone are caused in part due to long stage rendering times, but I figured I would see if there is an opportunity for improvement there.  Any best practices you can think of or short-comings with the approach I'm taking?

Edited April 14, 2020 by pongstylin

[vasilii]

My mind - not destroy sprites and containers, save it in object by type (cache) and use again.  

[pongstylin]

Just now, vasilii said:

My mind - not destroy sprites and containers, save it in object by type (cache) and use again.  

Remember that they are pre-compiled.  So building them has no impact on executing an animation.  Are you suggesting that display objects previously seen in stage rendering, but had been removed from the stage, would render faster than fresh display objects when added back to the stage?  If so, how does that work?

[vasilii]

) Create new Animated sprite - very hard operation.  )) You have 100 units, and anyone has animations run, shoot, stay. You must create 300 animated sprites, and use addChild or removeChild. Maybe I'm wrong. it helped me

 

Edited April 14, 2020 by vasilii

[pongstylin]

Yes, earlier you said to cache it by piece type.  But caching it by piece is more practical since 2 pieces of the same type can't share the same cached display object.  I had considered it but didn't want to use the additional memory unless it is proven to be helpful.  For proof, I just need to understand why it would be helpful.  After all, when building these display objects, I'm using cached textures.

[vasilii]

I can only share my experience. It helped me. Give it a try.

[ivan.popelyshev]

Sounds good.

Capture 10 seconds profile and i'll tell you what can be wrong  There are so many ways to do that stuff, and when someone does a sophisticated algorithm -  usually its small details that matter.

One of that kind of things - pixi GC. it removes all atlases that werent used for a minute or more from videomemory (on GPU). So, when you pre-render piece which resoruces was removed from videomemory, pixi executes texImage2D which can be slow on mobiles. You can switch off that GC easily (renderer.textuGC.mode = PIXI.GC_MODES.MANUAL) , however that also means you'll have to manage videomemory yourself.

Destroying containers & stuff doesnt matter really, its all about Texts and RenderTextures - they hold canvas or webgl resource and should be destroyed! Texts are removed from videomemory by GC but RenderTexture isn't, so make sure you destroy it.

I can give many advices like that, but really, profile matters more. Maybe you evaded most of the rocks in this river, we need to determine which ones scratched your boat.

Edited April 14, 2020 by ivan.popelyshev