4 ms·
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
by TazeTSchnitzel 9y ago
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.
- jordache 9y ago> 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.
- icebraining 9y agoBut you can also embed a raster image in SVG.
- jordache 9y agoThe context of the discussion is to leverage SVG's DOM based approach to render on screen elements
- TazeTSchnitzel 9y agoSoftware rasterisation is slow and power-inefficient, and does not scale particularly well with screen size.
- jordache 9y agowhen 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.
- abritinthebay 9y agoThat’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
- TazeTSchnitzel 9y agoReal 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.
- deleted 9y ago[deleted]