Feature/gpu

[mikekucera]

Associated issues:

• Initial, experimental WebGL rendering support #3305
• Performance enhancements using the GPU #3261

Notes re. the content of the pull request. Give context to reviewers or serve as a general record of the changes made. Add a screenshot or video to demonstrate your new feature, if possible.

• This PR adds a WebGL rendering mode to the Canvas renderer. This improves the frame rate for large networks.
• The WebGL mode is opt-in. It must be enabled when creating the cy object...

cy = cytoscape({
  container: document.getElementById('cy’),
  elements: [ /* … */ ],
  style: [ /* … */ ],

  renderer: {
    name: 'canvas',  // still uses the canvas renderer
    webgl: true, // turns on WebGL mode
    showFps: true,  // (optional) shows the current FPS at the top-left 
    webglDebug: true, // (optional) prints debug info to the browser console

    // additional options (provisional, may change in future releases)
    webglTexSize: 4096,
    webglTexRows: 24, 
    webglBatchSize: 2048,
    webglTexPerBatch: 16,
});

All node and label styles are fully supported. Nodes should look exactly the same with the WebGL renderer. The existing Canvas renderer is reused by the WebGL renderer. Nodes are rendered off-screen to a “sprite sheet” using the Canvas renderer and then used as textures by the WebGL renderer. This allows nodes to look the same while leveraging hardware acceleration. Each node only needs to be drawn to the sprite sheet once, then offloaded to video memory where it can be rendered repeatedly by the GPU. This approach also has the advantage that future contributions of new visual styles to the Canvas renderer should automatically work with the WebGL renderer as well.

Creating the sprite sheets does take some time when the network is first loaded. The preview release does not have a progress bar for this initial load time, so keep in mind that if your network doesn’t show up right away that just means it needs a few seconds to load.

Edge rendering has some limitations. It would not be advantageous to use the same sprite-sheet strategy for edges that is used for nodes. The strategy for this first release is to render straight edges as long skinny rectangles, and bezier edges as a sequence of straight segments that approximate a curve.

• Only straight-line, haystack and bezier edges are supported. Other less frequently used edge types such as taxi or segmented edges will show up as bezier edges.
• Dashed lines, overlays and underlays are not supported.
• Edges can only have one label in the centre. Source and target labels are not supported yet.
• Only triangle shaped edge arrows are supported. Other arrow shapes will show up as triangles. Hollow arrows are not supported.
• Only solid colours are supported, no colour gradients. The source and target arrows and the edge line can have different colours though. Opacity is fully supported.

Checklist

Author:

• The proper base branch has been selected. New features go on unstable. Bug-fix patches can go on either unstable or master.
• Automated tests have been included in this pull request, if possible, for the new feature(s) or bug fix. Check this box if tests are not pragmatically possible (e.g. rendering features could include screenshots or videos instead of automated tests).
• The associated GitHub issues are included (above).
• Notes have been included (above).

Reviewers:

• All automated checks are passing (green check next to latest commit).
• At least one reviewer has signed off on the pull request.
• For bug fixes: Just after this pull request is merged, it should be applied to both the master branch and the unstable branch. Normally, this just requires cherry-picking the corresponding merge commit from master to unstable -- or vice versa.

[maxkfranz]

Thanks, Mike. I'll take a look today

[maxkfranz]

This looks great. I'll just note this for later: The current approach looks like it draws the overlays as a layer on top of everything else.

Currently, in the canvas-only mode of the renderer, the overlays are drawn in the z-index order. This doesn't make a difference for most use cases, but it might be different for cases like compound networks.

Some people use the overlays as a highlight for many elements, but most people just use it to show the active state (usually one element).

It's fine as-is, and it's a good trade-off -- but we might want to do something about it in future. Some options for future:

• Note that WebGL handles overlays differently in the documentation.
• Change the WebGL approach to be like the canvas renderer.
• Change the canvas approach to be like the WebGL approach.

[maxkfranz]

@mikekucera, looks good to merge

[maxkfranz]

@d2fong. Hi, Dylan. Just wanted to bring this to your attention re. the overlays. Whatever approach we take in future could be informed by what works best for Cytoscape Web. Does/will Cytoscape Web use overlays for things like highlighting/selections/search?

[mikekucera]

The current approach looks like it draws the overlays as a layer on top of everything else.

I'm pretty sure that's not the case.

It draws elements in z-index order, and for each node it draws underlay, body, label, overlay in that order. The code is here:

https://github.com/cytoscape/cytoscape.js/blob/ba83c4ec3abc63cb1ccd53c9671ec990536ee802/src/extensions/renderer/canvas/webgl/drawing-redraw-webgl.js#L450C9-L453C14

[maxkfranz]

Not enough sleep. My mistake

[mikekucera]

No worries. Merging now.