Creative ways to improve performance of ParticleContainer

[hunterloftis]

I'm using a ParticleContainer to render a very dynamic map of tiles. The player can zoom and pan across a large tile-based world, and the tiles themselves can be animated or replaced at any time. The tiles are drawn with some back-to-front overlap and a few effects (shadows, reflections of the tile above). On a large monitor, a normal number of tiles to draw per frame is about 10,000, and it would be theoretically possible to draw 40,000 on an edge-case map.

At some point, every computer is going to hit a rendering limit. Sacrificing rendering fidelity in this application would be better than sacrificing framerate.

Does anyone have suggestions for how to essentially "guarantee" 60 fps with PIXI? Previously, using a 2d html canvas, I would draw the tilemap in columns and check between columns on the amount of time I had remaining in the frame. If there wasn't enough time budget, I'd draw subsequent columns later. This added significant complexity but did give me a reliable framerate.

I ran across the "ParticleRenderer" that seems quite new - would adding a new canvas and switching to that renderer for all the compatible parts of my image, then layering other PIXI renderers on top of it for non-particles, likely produce much benefit over the standard renderer?

Thanks!

[ivan.popelyshev]

> Does anyone have suggestions for how to essentially "guarantee" 60 fps with PIXI

No

There are many discussions about tilemap in the forum. Did you look in pixi-tilemap and explanations about it? "draw a window around camera, when camera touches it - clear tiles and draw again" kind of thing

[hunterloftis]

I don't mean, by the way, guarantee 60 fps and high quality - I'm looking for ways to, for example, amortize rendering over multiple frames in order to keep the overall framerate up.

I did look into pixi-tilemap, but what I'm rendering is somewhat more specific. Certain tiles need to overlap in certain ways, shadows need to work certain ways, reflections, etc. Plus, the map is fully dynamic and any tile can change at any time, so the "keep state until you hit an edge, then make a new state" strategy requires a lot of bookkeeping and is likely more expensive than the "clear and render each frame" strategy. That may be wrong and I'd be happy to hear why, but the work to implement the bookkeeping would be non-trivial so I'm not keen to test it right now.

[ivan.popelyshev]

I'm too tired to rewrite old things. Basically, there's a low-level algo (particlecontainer, pixi-tilemap, graphics, sprites, renderTexture) and high-level that is yours. There are many different combinations.

There's no guarantee on 60FPS, because I dont know which high-level do you use.

> would adding a new canvas and switching to that renderer for all the compatible parts of my image

Adding extra canvas is good only for old devices where webgl is software, not accelerated. My advice is to look in renderTexture's if you want something go static and for all dynamic use ParticleContainer or something else. 

In my biggest project I have a hybrid renderer that automatically moves objects between static and dynamic batches, and doesnt consume CPU resources at all if nothing is moving, pure GPU animations when possible. At the worst case it works like a collection of pixi sprites, all in between is gradual. Its possible to do those things if you know how all packaged renderers work. Just stumbling across ParticleContainer is not enough - you have to know the shader, have to look in FOR cycles, you have to profile your app and determine where is a bottleneck

There are just too many things to discuss in this topic. Please post some concrete information, then we can get into technical details.

Edited May 16, 2020 by ivan.popelyshev