Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reasons to choose canvas? #12

Open
wirekang opened this issue May 20, 2024 · 2 comments
Open

Reasons to choose canvas? #12

wirekang opened this issue May 20, 2024 · 2 comments

Comments

@wirekang
Copy link

Hi, we are considering to migrate to elkjs from dagre. I saw your comment(kieler/elkjs#141 (comment)), this is great demonstration for us. I'm wondering why did you choose the canvas for rendering rather than svg? Since we need to support animations in our graph, svg is proper choice for us due to ease of css-transition. But I want to know are there any limitation that blocking svg or advantages when using canvas. Thank you!

@AngryLoki
Copy link
Owner

Hi, actually the first version from 2016 used svg. It was based on D3.js, which was mostly monolithic and SVG-based back then.

In the first version there were no direct graphs, and only force-based layouts were supported, which meant many redraws, until springs are stable.

Later on D3 added support of canvas (well, maybe it is more precise to say that it become media-agnostic). Rewriting wikidata-graph-builder with canvas significantly improved performance due to multiple reasons:

  1. with SVG every graph node was DOM node with its own hover/click handlers, and DOM manipulation is generally slower than js objects
  2. as there is no "hover over text" events for canvas, to detect hovering, I used shadow canvas, where each block of text is replaced with rectangle. After that, calculating node under cursor is trivial. Meanwhile, SVG used more precise calculation for each letter (but it was slow)
  3. elkjs and other similar libraries may freeze UI when launched in the main thread, so I looked for solutions which can work in WebWorker. And given that coordinate calculation was done within WebWorker, why not to draw canvas there too? Such thing is not be possible with SVG. It allowed to fully eliminate data transfer between main window and worker: data is fetched, transformed, layout-ed and drawn fully inside WebWorker.

What was lost during svg->canvas migration:

  1. precision of click on text
  2. right-click -> save svg (but it did not work great anyways, as I used CSS properties that were not compatible with editors like inkscape)

However, when your graph is not force-based (and you don't care about FPS for redraw), and unprocessed data is small, SVG should still work fine.

@wirekang
Copy link
Author

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants