-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
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:
What was lost during svg->canvas migration:
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. |
Thank you very much! |
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!
The text was updated successfully, but these errors were encountered: