4 ms·

Doubling SVG Frame Rates at Khan Academy

53 points by spicyj 12y ago

lnanek2 12y ago
Wow, performance for SVG is really bad.
- ygra 12y ago
  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.
squared9 12y ago
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 http://www.w3.org/TR/SVG/animate.html
- spicyj 12y ago
  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.)
- progers7 12y ago
  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.
  - ygra 12y ago
    One might argue that an animation that doesn't even play is infinitely slow ;)
  - squared9 12y ago
    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.
philip1209 12y ago
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">
- btown 12y ago
  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!
datashovel 12y ago
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.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.
datashovel 12y ago
On this particular example from the article: https://www.khanacademy.org/math/basic-geo/basic-geo-coordinate-plane/basic-geo-shapes-on-a-plane/e/drawing-polygons 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.
- spicyj 12y ago
  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).
  - datashovel 12y ago
    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.
  - datashovel 12y ago
    Haven't looked enough at it, but I've been meaning to dig in to http://snapsvg.io/ http://snapsvg.io/ to see if it is any better. Apparently done by the same guy behind Raphaeljs

53 points by spicyj 12y ago

lnanek2 12y ago

Wow, performance for SVG is really bad.

ygra 12y ago
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.

squared9 12y ago

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 http://www.w3.org/TR/SVG/animate.html

spicyj 12y ago
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.)
progers7 12y ago
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.
- ygra 12y ago
  One might argue that an animation that doesn't even play is infinitely slow ;)
- squared9 12y ago
  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.

philip1209 12y ago

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">

btown 12y ago
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!

datashovel 12y ago

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.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.

datashovel 12y ago

On this particular example from the article: https://www.khanacademy.org/math/basic-geo/basic-geo-coordinate-plane/basic-geo-shapes-on-a-plane/e/drawing-polygons 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.

spicyj 12y ago
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).
- datashovel 12y ago
  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.
- datashovel 12y ago
  Haven't looked enough at it, but I've been meaning to dig in to http://snapsvg.io/ http://snapsvg.io/ to see if it is any better. Apparently done by the same guy behind Raphaeljs