Re: Why is SVG rendering so slow?

On 7/15/17 9:28 PM, Joseph Orbegoso Pea wrote:
> I want to make animated SVG graphics (as in having a single SVGSVGElement and animating attributes of thousands of descendant elements). For example, make I want to make a force-directed graph with thousands of nodes.
> 
> It is nearly impossible to do this by animating SVG elements.
> 
> In contrast, I can use a library like Two.js to achieve the same things. In fact, Two.js has an SVG interpreter that can read an SVG from DOM and create a drawing from it which can then be animated with SPEED.
> 
> Why is the native SVG implementation so slow compared to concepts like Two.js.

First, a clarification: it looks like Two.js is just a layer of
abstraction on top of the native SVG implementation -- it's not a
different thing, as far as I can tell (you can see what it's doing if
you right-click one of its circles and choose "inspect") Also, your own
"native SVG" animation isn't that much more bare-metal than the others
-- it's animating in JS (with requestAnimationFrame).  So, all of the
examples here are using JS-driven animation.

The key difference for performance is *what attribute you're animating*
to move the circles around.  Your two.js example is animating the
"transform" attribute, and browsers have optimizations for
transform-only changes (by putting the transformed thing into its own
"layer" with some dedicated graphics memory, so that we can simply tweak
that layer rather than repainting from scratch when it moves).

In your "native" example, you're animating the cx and cy attributes, and
those do not have that optimization -- so we have to redraw all of the
circles from scratch on every movement. (I don't know offhand if that's
something we could optimize like "transform" -- it's possible we might
be able to.)

So I expect that if you adjust your "native" demo to use the transform
attribute, you'd get better performance. If there's still a signifcant
benefit to using Two.js after that, you could drill in using devtools to
see what Two.js is doing under the hood in more detail -- it's likely
that the Two.js developers have studied how to structure their
animations to get the best results from browsers.

> 
> Here's three examples, comparing native SVG, Pixi.js, and Two.js. Both Pixi and Two win, while SVG is the slowest:
> 
> - https://jsbin.com/nohovowupa/edit?js,output (Two.js, fastest, 10000 circles)
> - https://jsbin.com/vizuwemibe/1/edit?js,output (Pixi.js, slower, 2000 circles)
> - https://jsbin.com/xocarayepi/edit?js,output (native SVG, slowest, 1000 circles and barely chugging)
> 
> By observing those examples, you can infer this: if it can be done in JavaScript, then it can certainly be done in native CPP.
> 
> 
> But why isn't it? What's taking browser vendors (f.e. Mozilla) so looooong to achieve this performance?
> _______________________________________________
> dev-tech-svg mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-svg
>