GPU support (?)

[pournaki]

First of all, thanks @vasturiano for creating this great library. I am using it to explore large-scale networks and was wondering about the necessary hardware to make the visualisations as responsive as possible. I am getting started with JavaScript, so please indulge me if my questions are naive.

When trying out the visualisation on a PC with a dedicated GPU (NVIDIA RTX 2060), I realized that the overall performance and fluidity did not really improve compared to my integrated graphics chip on the laptop (Intel Iris Graphics 550).

Is the performance of the library therefore mainly CPU-related? And if so, would it be possible to involve the GPU? A quick googling led me to Stardust. Would it be possible to somehow combine your library with this?

Thank you!

[vasturiano]

@pournaki thanks for reaching out.

The rendering part of the library is using HTML5 Canvas, which is mostly hardware accelerated using the GPU. If you are using Chrome as a browser, you can actually go to chrome://gpu/ to find out if your GPU is being used for Canvas.

If you don't see a performance difference with a more powerful GPU, chances are your bottleneck is not the rendering but the graph layout computation, which is utilizing the CPU. Does the fluidity increase after the graph has cooled down and the nodes are frozen into position? If so, that's an indication that it's mostly the force simulation engine in effect.

[pournaki]

Dear @vasturiano, thanks for your quick answer and please excuse my late one.

Meanwhile, I tested out a few different graph sizes on different operating systems. As you suggested. both chrome://gpu/ as well as the Win10 Task Manager indicate GPU usage while rendering the graphs, thank you for the tip. However, the fluidity does not necessarily increase after the graph has cooled down. Zooming in/out is still very clunky.

Another thing that I noticed is that the overall look of the canvas is very dependent on the operating system. While Linux and macOS seem to draw the edges in a more detailed way, they look a bit clunkier on Windows (see screenshot). This probably has to do with how HTML5 is rendered.

[zachboatwright]

@vasturiano I can confirm what Pournaki reported. It looks like that after the graph cools down, neither the load on my CPU or GPU goes down unless I completely pause the simulation, but doing that also means that the graph can't be interacted with.

Do you have any suggestions for lowering the load the on GPU and CPU when the graph idles, while still being able to interact with the graph and have it reheat when moved? I'd be happy to make a PR if you can point me in the right direction. Thanks!

[vasturiano]

@SZBoatwright bypassing the canvas re-rendering could be achieved by adding a conditional to the clearCanvas and tickframe operations in this section: https://github.com/vasturiano/force-graph/blob/7d27f69984e38cfb1f001d562f0836399e812264/src/force-graph.js#L489-L493

The difficulty is that certain features would not be able to function properly without this canvas re-paint, like zooming, moving particles or even node dragging.

[zachboatwright]

@vasturiano Ah, so I'm guessing there would be no way to bypass canvas rerendering and then reactivate it on a click, scroll, etc so that the user wouldn't notice it?

[vasturiano]

I think a "smart default" logic for this would be difficult, given the range of scenarios that the lib can be used for. Not impossible though.

However, much of this functionality can already be achieved from the consumer side. For example, one could tie the onEngineStop event with a call to pauseAnimation. And then invoking resumeAnimation when a click/scroll event is detected.

So, perhaps there is a solution that works already with the current API by toggling the animation loop dynamically.