5 ms·

SVG has the opposite performance profile of Canvas. SVG hits a performance ceiling as number of elements increases. Canvas, since it's rasterized image can han

SVG has the opposite performance profile of Canvas. SVG hits a performance ceiling as number of elements increases. Canvas, since it's rasterized image can handle a rasterized representation of millions of SVG elements. However as Canvas dimension increase, it will hit a performance ceiling.

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 ago
    But you can also embed a raster image in SVG.
    - jordache 9y ago
      The context of the discussion is to leverage SVG's DOM based approach to render on screen elements
  - TazeTSchnitzel 9y ago
    Software rasterisation is slow and power-inefficient, and does not scale particularly well with screen size.
    - jordache 9y ago
      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.
- abritinthebay 9y ago
  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
  - TazeTSchnitzel 9y ago
    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.
- deleted 9y ago
  [deleted]
aidos 9y ago
(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/ https://www.countfire.com/product-demo/
- vbuwivbiu 9y ago
  that's not 100k unique elements though, it's 100k instances of a set of <100 unique elements using <use> isn't it ?
  - aidos 9y ago
    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%28150k%29.gif?dl=0 https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
    - vbuwivbiu 9y ago
      performance degrades to <10fps above 2k nodes (2k random circles in an svg) for me regardless of browser
      - aidos 9y ago
        What are you doing with them? Animating them?
        9y ago
ygra 9y ago
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/Sierpinski_carpet_6.svg https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...
btbuildem 9y ago
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.

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 ago
  But you can also embed a raster image in SVG.
  - jordache 9y ago
    The context of the discussion is to leverage SVG's DOM based approach to render on screen elements
- TazeTSchnitzel 9y ago
  Software rasterisation is slow and power-inefficient, and does not scale particularly well with screen size.
  - jordache 9y ago
    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.
abritinthebay 9y ago
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
- TazeTSchnitzel 9y ago
  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.
deleted 9y ago
[deleted]

aidos 9y ago

(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/ https://www.countfire.com/product-demo/

vbuwivbiu 9y ago
that's not 100k unique elements though, it's 100k instances of a set of <100 unique elements using <use> isn't it ?
- aidos 9y ago
  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%28150k%29.gif?dl=0 https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
  - vbuwivbiu 9y ago
    performance degrades to <10fps above 2k nodes (2k random circles in an svg) for me regardless of browser
    - aidos 9y ago
      What are you doing with them? Animating them?
      - 9y ago

ygra 9y ago

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/Sierpinski_carpet_6.svg https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...

btbuildem 9y ago

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.