3 ms·
Hard to imagine that pure-HTML SVG is really slower than Canvas which relies on JS..
by thehappypm 3y ago
Hard to imagine that pure-HTML SVG is really slower than Canvas which relies on JS..
- TeMPOraL 3y agoEspecially if we're talking using "many hundreds or even thousands of them" on a page.
- Lockal 3y agoIt is, it is! SVG is DOM, with event handling on every node, with attempts to apply CSS rules. Canvas for non-interactive charts is just "draw once and forget". It is a sequence of moveTo + lineTo, then you have a bitmap and nothing else. Extremely basic graphics, modern JS engines will handle it in the blink of an eye. I don't even mention the fact that article suggests to return each SVG sparkline in a separate request.
- thehappypm 3y agoGuess it depends on your definition of performance.
- klysm 3y agoCanvas is faster _because_ it relies on JS. It’s a much dumber and stateful API - the browser has to do much less work.
- fuzzy2 3y agoAh, but Canvas does not rely on JS. You would update it using JS, yes. When you don’t update it, it’s just another image. Browsers are quite good at images. In the end, I think it’s down to the complexity of the graph and the dimensions (in pixels, because images need memory, too).
- thehappypm 3y agoHow do you draw an image on a canvas without JS?
- fuzzy2 3y agoYou don’t. My point is: After drawing, the canvas is “inert”. Rendering to the canvas once is probably more or less as expensive as rendering the SVG once. However, the SVG will probably be rendered a lot more than once. The page developer cannot control it either, the browser decides what’s best.