4 ms·

Canvas is faster, as it basically is just a bitmap, while an SVG chart with a million points would correspond to at least a million DOM elements.

castell 11y ago
3 years ago, I benchmarks it with thousands of lines: SVG was faster than Canvas in Internet Explorer 10, probably due their extensive long history with their VML legacy rendering. But SVG was a lot slower in Chrome and Firefox than Canvas probably due graphic card accelerated Canvas implementation. SVG wasn't supported in Android 2.3.x. From my experience back then working directly with raw-SVG in HTML5 wasn't a great experience SVG is based on XML after all. Working with raw-Canvas meant implementing a basic render loop myself which refreshes the area and the Text related API is a bit complicated and slow.
- ygra 11y ago
  SVG performance in IE (since IE9) has really been and is stellar, indeed. Chrome caught up mostly by now and at least at work the difference between Chrome and IE for certain tasks is that Chrome spends more time rendering and IE spends more time JavaScripting. Firefox SVG performance has been disappointing, mostly and mobile browsers are often better off with canvas as well since performance is generally constrained there. SVG performance in IE doesn't date back to VML, though. They just made hardware-accelerated rendering a major feature of their browser back then, while no one else was doing it properly. Similar to how Chrome started with JITting JavaScript to make it fast and everyone else caught up on that afterwards.
ygra 11y ago
You don't necessarily need a million DOM elements. Data points could mean points of a single plot, in which case you have a single path element with lots of points. Generally you can almost always bunch things together in a single path to reduce the number of DOM elements (with other tradeoffs, of course).

castell 11y ago

3 years ago, I benchmarks it with thousands of lines: SVG was faster than Canvas in Internet Explorer 10, probably due their extensive long history with their VML legacy rendering. But SVG was a lot slower in Chrome and Firefox than Canvas probably due graphic card accelerated Canvas implementation. SVG wasn't supported in Android 2.3.x. From my experience back then working directly with raw-SVG in HTML5 wasn't a great experience SVG is based on XML after all. Working with raw-Canvas meant implementing a basic render loop myself which refreshes the area and the Text related API is a bit complicated and slow.

ygra 11y ago
SVG performance in IE (since IE9) has really been and is stellar, indeed. Chrome caught up mostly by now and at least at work the difference between Chrome and IE for certain tasks is that Chrome spends more time rendering and IE spends more time JavaScripting. Firefox SVG performance has been disappointing, mostly and mobile browsers are often better off with canvas as well since performance is generally constrained there. SVG performance in IE doesn't date back to VML, though. They just made hardware-accelerated rendering a major feature of their browser back then, while no one else was doing it properly. Similar to how Chrome started with JITting JavaScript to make it fast and everyone else caught up on that afterwards.

ygra 11y ago

You don't necessarily need a million DOM elements. Data points could mean points of a single plot, in which case you have a single path element with lots of points. Generally you can almost always bunch things together in a single path to reduce the number of DOM elements (with other tradeoffs, of course).