Performance approaches for WebGL

[maxkfranz]

Carrying on the discussion from : #3321

[KonradHoeffner]

Current baseline for SNIK Graph (4365 nodes, 6665 edges)

CPU	GPU	resolution	webgl	RAM	FPS	selection possible	TexRows	Browser
Intel Core i9 12900k	-	4k	true	14.3 GB	16	no	default	Firefox
Intel Core i9 12900k	-	4k	true	6.5 GB	20	no	256	Firefox
Intel Core i9 12900k	-	4k	true	5.0 GB	57/91*	no	256	Chromium
Intel Core i9 12900k	-	4k	false	3 GB	33	yes	256	Chromium
Intel Core i9 12900k	-	4k	true	6.4 GB	16	no	2048	Firefox
Intel Core i9 12900k	-	4k	true	6.6 GB	16	no	4096	Firefox
Intel Core i9 12900k	-	4k	false	4.7 GB	25	yes	default	Firefox
Intel Core i9 10900k	Nvidia 3070	4k	true	7 GB	42	no	default	Firefox
Intel Core i9 10900k	Nvidia 3070	4k	false	3.3 GB	16	yes	default	Firefox
Intel Core i3 1115G4	-	full HD	true	OOM	-	-	default	Firefox
Intel Core i3 1115G4	-	full HD	false			yes	default	Firefox

In my opinion the most urgent need right now is optimizing memory consumption because it can crash the browser, especially on machines with no separate GPU (so the system RAM is used as video RAM), on Firefox and with the default setting for TexRows.

[mikekucera]

We are investigating using texture compression. In theory that should greatly reduce memory consumption. This approach is non-trivial though and may take some time to implement. In the meantime set webglTexRows as high as you can until labels start to look blurry.

[mikekucera]

Follow up on texture compression...

• I created a prototype version of the WebGL mode that uses the basis universal library to compress textures at runtime in the browser.

• The code is available in the feature/gpu_tex_compress branch.

• Here are my initial findings. (Disclaimer: I am not an expert with WebGL or texture compression, I may have missed something.)

• This solution is complex:

  • Requires running a wasm module in a web worker.
  • Adds asynchronicity and message passing to the renderer.
  • Adds large dependency on Basis Universal that we have to host somewhere.

• Compression is slow.

  • Compressing dozens of textures for an EM network can take a minute or more.
  • This kills responsiveness. For example if a user selects a node it needs to show the selected style immediately, having to compress the texture in real time won’t be responsive.
  • For Cytoscape Web the user might be trying out different styles. Would have to recompress all textures every time the user changes a style property.

Conclusion:

• I do not recommend this approach.

[mikekucera]

While working on the texture compression stuff I found a memory leak in the WebGL renderer. I discovered that OffscreenCanvas objects actually use GPU memory, and they weren't been freed when they could be.

Fixing this memory leak frees up a significant amount of GPU memory.

Testing on the SNIK Ontology Graph application on chrome on my macbook:

• Cytoscape.js 3.31.0 WebGL mode with default settings:
  • 8.5 GB GPU memory
• With memory leak fixed:
  • 5.1 GB
• With memory leak fixed and webglTexRows increased from 12 to 24:
  • 1.8 GB

So, fixing the memory leak, and changing to default settings to use fewer textures, seems to get us quite far actually.