Performance Tips for Large-scale 2D graphing

[Azdalen]

We're working on a 2D graph visualization engine using Pixi as the underlying graphics library. Our demands are going to get pretty crazy later on, but for now, we want to reliably be able to smoothly render & interact with ~100k Nodes/Edges which will be composed of Sprites and/or Graphics (but scaling to ~1M+ later on is not out of the question) I think things like Viewport/Z culling (assuming Pixi is not doing one of those already behind the scenes) would be good and perhaps faking non-active nodes/edges with a RenderTexture/ParticleContainer? Due to interactivity needs, things like ParticleContainer may not be a one-stop solution as it doesn't seem to support interactivity; but perhaps using our own Interaction manager (quadtree/kdtree) would sidestep that limitation.

I guess what I am asking is, what are the communities recommendations when they need to show a large number of potentially interactive objects (Sprites/Graphics) on the screen at once? 

[ivan.popelyshev]

>  ~100k Nodes/Edges
Its not easy to join the club of 100k bunnies - you need your own high-level algorithms to work with pixi low-level smoothly.

As an example - I'm working on complete implementation of Adobe Flash using PixiJS and mozilla shumway.

My scope is ~500 vector elements with filters that can be cached and ~10000 animations played on GPU.

`renderAdvanced` in PixiJS Container takes 50 lines, and its relatively sparse. Mine version of element renderer is about 2000 lines if I count all extra components I added for it. Its covered with hundreds of tests.

Cache that tracks whether particular subtree wasnt changed is like React,except  it can work on 60FPS and doesn't allocate memory like crazy. I implemented it based on all experience of Mozilla Shumway that was coded by~ ten people by 3 years and failed.

Super-fast scene tree that doesn't iterate through all elements each frame to check if matrices has to be computed and which elements belong to which layer (z-indexing) - that's a huge problem. I made it using my algorithm expertise, which i trained in programming competitions.

z-culling is another thing that is difficult architecturally, you can just take random gpu optimization and put it inside a scene tree. I don't know any other projects besides mine that use z-culling in 2d which seriously helps on old graphics cards like Intel HD 3000.

There's also antialiasing for graphics - it doesn't exist in WebGL on RenderTextures, it exists only on WebGL2 and requires serious architectural changes to avoid huge memory consumption. I solved it due to undocumented feature that suddenly exists in all browsers, and I also implemented all that architectural nightmare on top of other optimizations - caches, filters, e.t.c. PixiJS version https://github.com/gameofbombs/pixi-blit/ will be released in a month or so, I focused on my private fork, cant share it yet.

Interaction optimizations are based on bounds which based on super-fast scene tree. One step sideways and you'll have so many bugs that'll take year to debug. PixiJS bounds bugs exist after 8 years of coding. They are usual problem. I know how to make effective pixel-perfect interaction based on injection of mouse coords in shaders, but i dont know how to add something better like quad-tree without affecting code style badly, which, again, leads to big number of bugs.

Now, you want 100k Graphics on scene with all those features, where Adobe Flash dealt with 10000. I think, with the scope you are asking, your project costs 1M$  

Most of my work will be open-source, it will open doors for projects like you asking for, but right now you need to hire a team and spent more than a million $ on 2 or so years to get the product.

> I guess what I am asking is, what are the communities recommendations when they need to show a large number of potentially interactive objects (Sprites/Graphics) on the screen at once? 

Write your own stage tree, its not that hard to just copy @pixi/display ,  @pixi/sprite , @pixi/graphics and pixi5-svg and go on.

> but scaling to ~1M+ later on is not out of the question

In your dreams. Ask https://phase.com/ how is their project going

[ivan.popelyshev]

Oh, and Welcome to the forums! 

I really hope you'll join club of 100k bunnies soon with the scope you are trying to achieve

[ivan.popelyshev]

Of course you can give more info about the project and what type of nodes do you want and do you want filters on them or what, it all affects the choice of algorithms you need.

I cant even recommend any particular things like "Sprites are faster than Graphics" because all pixi elements have different balance in different versions, its completely different in v4 and v5, and performance of Graphics is changed every three months, e.t.c.

As for interaction, just look at https://github.com/pixijs/pixi.js/blob/dev/packages/interaction/src/TreeSearch.js and estimate if it can survive 100k elements with 10 clicks per second. This class, like many more things in pixi are supposed to be overwritten by your own high-level algos.

I think you need a better ladder:

1. 10k elements

2. 50k elements

3. 200k elements

4. 500k elements

5. 1m.

And you dont start the next stage before you implement previous, because it gets even worse every time and you need something that works already. You need to implement everything you want at 10k first. It wont be good if you hit 100k and then sudden "ugh, guys, we need z-index" will smash your architecture in pieces.

Edited November 30, 2019 by ivan.popelyshev

[ivan.popelyshev]

Here is 2000 elements on screen and changing. That'as a hecking fast tree. Not related to pixi, just as example that people are amazed even at 2000.

And my tree handles 10k but each element is an animated cow with 10 quads or so

 

Edited November 30, 2019 by ivan.popelyshev

[Azdalen]

Thanks for the suggestions, lots of food for thought.