These are chat archives for pixijs/pixi.js

13th
Jun 2018
Thomas
@Thomas-Kuipers
Jun 13 2018 10:26
Hey everyone. I'm working on the open source graph visualisation tool marija.io (demo at demo.marija.io). I'm using Pixi to render the graph. I'm working on optimising the performance. At the moment we can handle around 1500 nodes and then it gets to below 30FPS. It appears that the links between the nodes are biggest bottleneck at the moment and I'm not sure how to optimise that further. I have 1 graphics object for all of the links (let's say around 2500 lines when we have 1500 nodes). On every frame I clear the graphics object and then for every line I use moveTo and lineTo. I also set the property nativeLines to true on the graphics object, which helped slightly. When I look at the Chrome performance debugger I notice that pixi-gl-core/src/GLBuffer.js is taking the most time for operations, I think it's responsible for uploading data to WebGL. Does anyone know of any ways to draw a huge amount of lines fast? The more the better, if we could draw graphs with 100k nodes that wouldn't even be overkill. I'm willing to sacrifice some quality as well if it's necessary.
Mark Knol
@markknol
Jun 13 2018 11:57
I would say maybe create custom pixel shader which draws lines based on line points on one texture?
Thomas
@Thomas-Kuipers
Jun 13 2018 15:06
Can you point me to an example of that?
Mark Knol
@markknol
Jun 13 2018 15:21
not really
btw do the lines update often?
Mark Knol
@markknol
Jun 13 2018 15:26
otherwise you might draw it once in a RenderTexture
and update that texture when needed
Ivan Popelyshev
@ivanpopelyshev
Jun 13 2018 16:08
i dont think nativeLines are problem
use sprites for nodes instead, and it'll be faster
also chunking, divide it into separate graphics for different zones. Each zone can hold a ParticleContainer, so when it updates it'll only reupload partially
i can tell a number of possible optimizations, but it depends on whether you are actually ready to separate your graph on multiple chunks or not