> 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.