How/when does Pixi exactly render the canvas?

[Shockblast Apps]

I have tried looking at the Pixi source code trying to figure out why it is supposed to be the best HTML5 renderer on the web. But unfortunately I can not really figure it out. It seems to work with a Stage object where every sprite is attached to it via nodes so it can check when it needs to rerender the canvas.

 

However, when it rerenders the canvas it still needs to repaint the background and thus have to redraw every sprite on the screen again. So how does this differ from naive rendering which sort of does the same?? I can not really figure out how Pixi.js has optimized the drawing calls to a canvas HTML5 game.

 

I am trying to figure out the design principle of Pixi.js in order to find ways to improve the FPS in my game without porting everything to Pixi.js.

[rich]

It doesn't really do that much when it comes to canvas (as opposed to WebGL), but the key take-homes would have to be:

 

1) Position coordinates are rounded-up to avoid interpolation

 

2) Invisible parent-child hierarchies are skipped

 

3) It uses affine transformations. In most "naive" rendering loops if a sprite has rotation or scaling set it will lock the canvas context, apply a transform for that one sprite, then restore the context again at the end. This is an expensive process to go through if you've a large number of sprites (or complex transforms) as it happens every single frame. Pixi uses a single setTransform for every sprite, for positioning, rotation and scaling in one single hit, so doesn't need to save state every time.

 

If there is one element from pixi you want to copy, that would be the one that would net you the most speed. But it will most likely require you to re-think entirely how your game objects are set-up and the display relationships between them all, with local/world transform iteration. In short, it's most likely a big change.

 

There aren't really many other optimisations you can make. I've seen various implementations: back buffers, dirty rects, etc. But in the end most rendering speed gains are down to how carefully the developer packed together their textures and shared use of them, rather than little internal tweaks.

[Ezelia]

For me Pixi is the best renderer for HTML5 not for it's performance but for it's API and the fact that it use WebGL for fast rendering and fallback to Canvas2D.

 

as rich said, in the end, performance is more related to the way you handle your assets, and organise your code than the code optimisations inside engine code (still it's important to avoid costy mistakes).

for a game  I'm developing for a client, I started with Pixi the moved to my custom renderer and gained about 10% of FPS on mobile, this was a special case cause the game requires lot of graphics and animations.

[Shockblast Apps]

Hey guys, thanks for answering my question It seems that my code is doing the costly transformations in my game and it is a bit too late to change that now. I'll keep it in mind for my next game though and see if I can organize everything better.