These are chat archives for pixijs/pixi.js

14th
Jun 2018
Thomas
@Thomas-Kuipers
Jun 14 2018 07:43
Yes the lines do update often, on every frame. Nodes can be dragged, which causes other nodes to also update their position because they attract/repel each other (I'm using d3 force layout for calculating node positions).
I am using sprites for nodes. I'm creating a new sprite for every node on every frame, based on a texture. If you have thousands of nodes, there are probably just 5 textures or so, because most nodes look identical (a circle with an icon in it). The texture is then shared between all those nodes. I should probably also pool these sprites right? Now I'm only pooling the textures. Reusing the sprites is on my todo list, but at the moment rendering the lines is the biggest bottleneck. What do you mean by using different zones? How the graph currently works is that dragging one node on the graph affects all other nodes of the entire graph, so I'm not sure if splitting it into different zones is relevant? If it's useful I'm definitely ready to split the graph into multiple chunks, whatever it takes ;)
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:02
i know there were many projects with graphs and nodes and edges on pixi, but nobody posted optimizations for them.
if you cant imagine how to divide your space into chunks, then think about it for a month :)
the trick with chunks is easy: when you modify something, it modifies only several parts of buffers and reupload is faster.
Thomas
@Thomas-Kuipers
Jun 14 2018 08:14
can chunking still be useful if all of the data changes each frame anyway? or do i need to first figure out a way that some parts of the graph dont get updated on every frame?
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:22
why does it change every frame? scrolling?
Thomas
@Thomas-Kuipers
Jun 14 2018 08:24
When a user drags a node, the node position updates, thus all the lines connecting the nodes also update. Even when the user releases the node, it might still float in space for a while until it settles down and stops moving. And not only does the node being dragged change position, it also causes all the other nodes to update their position because of the attract/repel force between the nodes.
That version is a bit outdated though
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:25
you sure there will be thousands of nodes on screen?
Thomas
@Thomas-Kuipers
Jun 14 2018 08:25
in some use cases yes
we can think of use cases with 100k nodes even
our goal is to support as many as we can
10k would be a very nice milestone
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:26
i still think that nodes are your problem.
are nodes in the same graphics?
ugh, actually, i have one idea
graphics use static buffers
you can change it to dynamic with hacking
let me look...
Thomas
@Thomas-Kuipers
Jun 14 2018 08:27
sounds great!! thanks
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:27
but make sure that nodes aren't in the same graphics
Thomas
@Thomas-Kuipers
Jun 14 2018 08:27
no they're not
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:28
because for every circle on clearing it runs a tesselation
Thomas
@Thomas-Kuipers
Jun 14 2018 08:30
im actually generating node rendertextures on canvas because of lack of anti aliasing support in something (dont remember exactly what that was, its been while). From a few rendertextures im generating thousands of sprites, which are added to their own node display group.
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:44
here you go
you can slo try switch DYNAMIC_DRAW to STREAM_DRAW
Thomas
@Thomas-Kuipers
Jun 14 2018 08:46
okay ill give it a shot! one sec
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:50
now that i think of
whenever you use moveTo, lineTo it calls up earcut to triangulate that shit, even if its two points
oh, it updates indexBuffer too
Thomas
@Thomas-Kuipers
Jun 14 2018 08:50
image.png
it seems that after the patch it's only updating the lines once and not uploading the new line data
same for DYNAMIC_DRAW and STREAM_DRAW
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:52
here, new one
Thomas
@Thomas-Kuipers
Jun 14 2018 08:53
still the same
i put it in a branch line-performance on github, the pixi code is in this file: https://github.com/dutchcoders/marija-web/blob/line-performance/src/app/graph/graph.tsx
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:57
oops, sorry
Thomas
@Thomas-Kuipers
Jun 14 2018 08:58
ah the lines are updating now! let me check the performance
hmm it seems to be a bit slower than it was
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 08:59
try STREAM_DRAW instead?
Thomas
@Thomas-Kuipers
Jun 14 2018 08:59
it's now spending lots of time on createVertexArrayOES and deleteVertexArrayOES
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:00
oh
oh shit
i think i know whats wrong
Thomas
@Thomas-Kuipers
Jun 14 2018 09:00
same with STREAM_DRAW
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:01
im thinking...
Thomas
@Thomas-Kuipers
Jun 14 2018 09:01
:)
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:02
Thomas
@Thomas-Kuipers
Jun 14 2018 09:03
now it seems to be similar to the original situation
most time spent on bufferData
i'm not sure if it's less or more, hard to say, seems roughly similar
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:04
well, we've tried :)
nothing can be done on low level then
Thomas
@Thomas-Kuipers
Jun 14 2018 09:04
hmm okay
any other ideas?
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:05
yep. spend a month understanding webgl
make thing better than graphics that suits your needs. i dont know how
you have to experiment
wait
Thomas
@Thomas-Kuipers
Jun 14 2018 09:05
haha pixi helped me to avoid that until now, but soon ill have to get into webgl myself im afraid ;)
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:05
did you actually remove nodes from that graphics?
Thomas
@Thomas-Kuipers
Jun 14 2018 09:06
the nodes are not in that graphics object
theyre in a different display group
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:06
what i dont understand is why is it trying to get new WebGLGraphicsData each time, and takes it from the pool
if you have fixed number of those lines, it doesnt have to do that
however, it doesnt relate to amount of data uploads
Thomas
@Thomas-Kuipers
Jun 14 2018 09:07
well i'm doing a .clear() on the graphics object on the beginning of every frame, and then i draw the line again from scratch
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:07
move to Mesh
the only problem - mesh does not support wireframe
you have to add it yourself
Thomas
@Thomas-Kuipers
Jun 14 2018 09:08
wireframe?
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:08
or GL.Lines
you have to study both webgl and pixi internals
you still need pixi for architecture , you have to change its behaviour , which webgl operations does it call
Thomas
@Thomas-Kuipers
Jun 14 2018 09:09
so you're saying that drawing lines via mesh would be a solution?
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:09
it would be "cleaner"
less operations
Thomas
@Thomas-Kuipers
Jun 14 2018 09:09
because then only the coordinates need to be updated? instead of uploading the whole line to webgl again?
Ivan Popelyshev
@ivanpopelyshev
Jun 14 2018 09:09
and easier to understand the code
"whole line" are coordinates.
no, just , you need basic mesh functionality
graphics does a big number of things
you wont be able to debug and patch it as fast as I am doing it
mesh is easier
Thomas
@Thomas-Kuipers
Jun 14 2018 09:11
hmm okay
i'll try to look into it
anyway, thanks so much for your help Ivan! really appreciated