In my experience, canvas 2D also has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.

For example, try drawing hundreds of coloured rectangles per frame. Easy, right? If you're using WebGL, or any sensible graphics API, yes. If you're using canvas, the web-browser will parse and re-parse your colour expression CSS n times per frame. Enjoy your 100% CPU usage.

> has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.

Well you can generate your imagery programmatically and then render it to canvas as a raster image. Canvas is not purely for implementing a web based drawing app.

But you can also embed a raster image in SVG.

The context of the discussion is to leverage SVG's DOM based approach to render on screen elements

Software rasterisation is slow and power-inefficient, and does not scale particularly well with screen size.

when you are faced with between rendering hundreds of thousands of SVG DOM element vs in memory generation of a final raster image, the latter will always be more performant.

That’s not exactly surprising - you’re describing a problem with basically every graphics engine.

Rasterizing expensive operations before drawing to screen is usually job one of a rendering pipeline

Real graphics APIs can handle dynamic geometry efficiently, have a batching mechanism, and don't force you to express colours through CSS strings.

Rasterising ahead-of-time is all well and good, but it's not something you should have to employ just to draw simple polygons.

I wouldn't say the opposite, just ... different.

Basically, canvas performance depends a lot on how many pixels you draw and how you draw them (blitting an image vs. drawing a gradient are very different things, obviously).

SVG performance depends on how many things in the DOM are changed at the same time (and then it's mostly dependent on how well the browser can avoid redraws – that's an area where we frequently encounter bugs when either too much or too little is redrawn). A large static image¹ manipulated only via affine transforms performs quite well; an image containing lots of different things that all vary constantly is bad. But as long as the viewport isn't too large, canvas can be a viable alternative to SVG if the visualization is simple.

¹ Unless written like this one: https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...

(Edit moved to here from the wrong thread)

This comes up on each SVG thread and I post the same comment each time (so excuse me if you've heard this from me before).

We render SVG that contain beyond 100k nodes in the browser and find that it works fine. You need to be careful with your manipulations and we've developed a couple of tricks to keep things snappy, but the final experience is great.

Here's a demo of it in action with a smaller SVG

https://www.countfire.com/product-demo/

so with your 100k node ceiling. Have you tested across different OSs/CPUs/Browsers? Have you found tremendous variety in performance?

There's not a specific ceiling. This morning I did a quick test with 400k nodes and we sometimes get 2-3 million or more.

We only use chrome because Firefox struggled in the initial testing. Having said that, I haven't tried in anything other than chrome in ages and I'd wager the situation has changed a lot in the last couple of years.

Only use Chrome? Your product only supports Chrome?

That's one of the issue i have with SVG browser implementation varies so much. Our product that is performant in Chrome sucks in IE11

Yeah, for the moment we only support chrome. I know it's not ideal, but it sure is nice not having to worry about cross browser issues :-)

What's the slow bit in IE? Is it the svgs?

that's not 100k unique elements though, it's 100k instances of a set of <100 unique elements using <use> isn't it ?

No, in our case they're all unique elements - unfortunately for me! That demo example is actually much smaller though (2k nodes).

Here's an example with over 150k nodes [1]. To be honest, we would normally doctor documents that had this many nodes to make the experience smoother for users. You'll notice that it's a bit sluggish when you zoom in and out, but panning is the same speed regardless of number of elements, and updating elements within the document is fast too.

[1] https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...

performance degrades to <10fps above 2k nodes (2k random circles in an svg) for me regardless of browser

What are you doing with them? Animating them?

nothing - only changing the transform matrix on the root <g> for pan/zoom

Can you move it further up and are you using 3D?

do 3d css transforms make that much difference ?

You can use something like `transform:translateZ(0px)` to force a subsection of the dom to exist on its own rendering layer. Then you can transform the parent nodes and they'll move the lower layer around as if it were a static picture that they don't need to redraw. I'm not sure how well this works within an svg, but you can certainly use it to do your transformations outside the svg.

ok i dug out the project I was thinking of and I was wrong - performance is fine at 10k nodes. adding translateZ causes a slight delay after changing the transform matrix while it re-renders the bitmap, and you see the switch - thanks for the advice

Choice between SVG and Canvas comes down to a balance between performance and interactivity, IMO. It is very easy to attach events and create interactions with a SVG object -- much harder to do that in Canvas (basically, you have to keep track of everything that was drawn). The flipside is, Canvas it effectively a bitmap, doesn't care what the pixels are, so the complexity is a constant regardless of what is drawn. SVG renderers will start to bog down once there are "too many" elements.