Jump to content

Looking for Efficient Rendering Tips


Recommended Posts

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 by pongstylin
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

) 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 by vasilii
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ivan.popelyshev
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...