Open mfburnett opened 9 years ago
Thanks Mackensie, much appreciated. I'll let Kurtis figure out how to incorporate this advice.
@mfburnett great advice! :+1:
big fan of transforms over js postitioning, investigating that with D3 force layouts
We are also going to incorporate clustering and that alone should help with node count and repaints, was considering using react and native svg and then just trying to utilize d3 layouts without d3 rendering, any thoughts on this approach?
D3 for math and React got rendering works.. On Thu, Jul 23, 2015 at 10:55 AM Kurtis Kemple notifications@github.com wrote:
@mfburnett https://github.com/mfburnett great advice! [image: :+1:]
big fan of transforms over js postitioning, investigating that with D3 force layouts
We are also going to incorporate clustering and that alone should help with node count and repaints, was considering using react and native svg and then just trying to utilize d3 layouts without d3 rendering, any thoughts on this approach?
— Reply to this email directly or view it on GitHub https://github.com/adrianco/spigo/issues/47#issuecomment-124183009.
@kkemple agree on the decision to cluster - pulling in my friend @jaxgeller who has a lot more experience with react than me to weigh in with thoughts on your approach
My friends and I have been playing around with spigo, and so far it's been great. One thing we’ve noticed is that for higher node visualizations, performance becomes a major problem. For migrations/9, I was unable to even use the graph as the frame rate became less than 5 per second.
After timelineing the graph and looking at the styles, I was able to conclude that paint times were the largest contributor of poor performance. After diving deeper, I would suggest that instead of manipulating positioning on the nodes and tool-tips, I would manipulate it using transforms so it renders in its own layer. http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
You might want to look into debouncing the scroll events with requestAnimationFrame, so you’re not doing too much scripting into one frame (16ms).
After that, you could try to reduce the amount of nodes on the screen with some kind of clustering, as this would ease rendering performance as well. You could do cool things with clicking to see subnodes to still be able to show all the nodes if you wanted to.