1. 13
  1.  

  2. 6

    Always love to see neat hacks like this but… What is going on here, is this an alternate SVG renderer written in Javascript targeting canvas? If so how could that possibly be faster than the browser’s native implementation? I believe it might be, but how and why?!

    I remember talking to Mike when he got started on Protovis, long before D3. And I was like “SVG? Does that still work? I thought it was dead”. It’s amazing how that tech has come back and been so useful.

    1. 2

      Thanks for engaging! Basically the library directly renders the visualization with a virtual DOM, skipping the standard SVG rendering process which is slow due to the complexities of SVG. So it’s not rendering a real SVG, but rather a visualization of what the SVG would display. It’s very easy to prove it’s faster than the browser’s implementation, because you see these examples showing with and without SSVG

      Personally, I’m a huge fan of SVG, and working with another person to showcase more capabilities of SVG like the ability to live-draw vector-based animations and textures.

      1. 4

        the library directly renders the visualization with a virtual DOM, skipping the standard SVG rendering process which is slow due to the complexities of SVG

        Ok, but why? Is it just a deficiency in the browser’s svg implementation? Is it that svg is expensive to parse compared with the js you generate? Or what?

        1. 6

          Looking at the technical limitations section of the site, it seems like this just implements a subset of SVG. In Pareto principle terms, it implements the 20% of the solution that solves 80% of the problem.

          1. 1

            That still doesn’t answer the question: why isn’t the browser just as fast for that subset?

            1. 2

              Because the built-in renderer adds every node to the real DOM,with all the (in)validation loops and performance cliffs that entails.

        2. 2

          Thanks for the explanation!

          Have you done much testing with Firefox? A lot of the examples don’t render with SSVG turned on. Donut does render but is slower; 45 FPS with SSVG on, 90 FPS with SSVG off. Chrome is the opposite: 66 with SSVG on, 37 with it off.

          I imagine dynamic SVG performance is very complicated. Neat to see an alternate approach!

          1. 2

            You’re right, not a lot of testing on Firefox. I can see how it can be hit-or-miss. That’s something we should work on.

      2. 3

        Hrm… I’m not seeing a significant difference in the demos (to be fair, I run a fairly non-standard Firefox + Linux setup which may not have been tested), and I soon realized the main hero “example” is actually a pre-made video 🤨

        1. 2

          I had one demo go faster with normal SVG, one made no difference, third was faster with SSVG. Firefox on Linux.