Doubling SVG Frame Rates at Khan Academy | Hacker News Reader

Doubling SVG Frame Rates at Khan Academy

princeton.edu

53 pointsspicyj14 comments

On this particular example from the article:

https://www.khanacademy.org/math/basic-geo/basic-geo-coordin...

I would definitely not recommend using individual <svg> nodes. Instead what I did was wrote some basic wrapper functions to decompose and re-compose the internal attributes of <path>. If you get a chance to read the spec you'll see that you get the option of assigning RELATIVE or ABSOLUTE coordinates, which makes it very easy to do a simple editor like what you've done within a single <svg> node.

That's what we had originally, but you lose out on the ability to take advantage of GPU hardware acceleration (in current browsers, at least; there's no actual technical reason preventing GPU acceleration for SVG drawing that I know of).

I am probably assuming several things about how that would be implemented. I personally decided to abandon the idea of using Raphaeljs because it appeared to assume too many things about how I was going to be interacting with the SVG objects on the canvas.

I found that (for my purposes) working directly with the objects was a huge win in terms of performance.

Haven't looked enough at it, but I've been meaning to dig in to http://snapsvg.io/ to see if it is any better. Apparently done by the same guy behind Raphaeljs

I recently ran into some performance-related issues in SVG, but have cleaned up substantially by using requestAnimationFrame()

https://developer.mozilla.org/en-US/docs/Web/API/window.requ...

It's not the "be all end all" solution, but helped my project enough to where performance issues were no longer noticeable.

Just a question - why don't you use SVG SMIL animation? It's perfectly fluid, HW accelerated, has declarative animation transforms, allows easings, draws in its local coordinate space, you can add interactive JavaScript events etc.

http://www.w3.org/TR/SVG/animate.html

Historically, our interactive diagrams rendered to VML for IE8 support in addition to the SVG used by modern browsers, so we couldn't use any SVG features that aren't shared by VML. We no longer support IE8, but our code is still mostly built around this assumption so it's nontrivial for us to take advantage of any native animation support. (In addition, these aren't animations per se; rather they're cases where we move elements of a diagram in response to a touch interaction, which (I believe) requires JS to power it regardless.)

SMIL is not perfectly fluid. SMIL is not inherently hardware accelerated. SMIL animations are slower than the same animations driven from JS in all major browsers except IE which doesn't support SMIL but does support JS. As the OP showed, JS animations are the way to go for SVG.

One might argue that an animation that doesn't even play is infinitely slow ;)

My experience says otherwise, SVG SMIL tends to be 10-20% faster with lower CPU load in recent browsers (Chrome/FF/Safari) than a JS-driven animation. YMMV though.

Wow, performance for SVG is really bad.

It depends very much on the browser. Ironically, IE is leading in that area, actually, and Firefox lags behind the other two by a great margin. It often looks like FF thinks it needs a complete repaint where a little recompositing would suffice which means that something as simple as moving a tiny thing in a large, complex visualization can have abysmal performance.

It also seems that, depending on the browser, they have dug themselves in the same hole as before. Moving the polygon or one of its nodes around triggers a layout in at least Chrome and IE, exactly what they wrote were trying to get rid of. Maybe the demo does not yet show their new implementation; I saw way too many SVG elements, but no CSS transform on them.

If the author is reading this - you can change the way you import fonts to protocol-relevant and your site will be fully SSL-compatible using the Princeton certificate, e.g.

  <link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Open+Sans">

And if the author is reading this - as much as the Princeton domain makes for a nice web address, your site will be taken down COMPLETELY the October after you graduate. (Source: Princeton alum. I disagree with the policy, but even if it were changed it would be unlikely to change soon enough to be relevant to you.) I'd migrate your content off-site sooner rather than later and set up permanent redirects - as well as adding a comment with the new location here in case people find this post on HN! Great content, I just don't want it to be lost!

Reply on news.ycombinator.com