I'm not sure if this is surprising. Even the proprietary Macromedia Flash showed us in the late 90s that vector graphics are more computationally expensive than raster equivalents.
SVG is nice because it gives us additional flexibility -- it's resolution independent (so you don't need to redraw your image by hand when higher-DPI displays come out) and allows for animation[0]. But if you don't need those things (and you probably don't for your sprites) then they'll just slow you down.
Is it not feasible to load a vector graphic into a raster equivalent on first load? Startup time would, predictably, be slower, but just moving something around the screen would then be equivalent. (Obviously, some actions could trigger a redraw of the vectors, but I would think this would actually be a limited set of interactions.)
Yes, this is feasible and Flash did this (optionally).
Flash supported this as a trade-off via the cacheAsBitmap attribute on elements. Basically you'd set that to true if you knew the sprite was just going to be translated around in x/y and not scaled or rotated. It wasn't on as the default for new sprites because this mode would actually bite you in the ass if the sprite was going to scale/rotate nearly each frame because the cost of recreating the "cached" version would then be added to the render time without actually ever being useful.
So it is a good idea in practical usage to make this an optional feature, though I think Flash could have been smarter about it (like soft-default to caching and only override that once it sees a scale or rotate taking place).
SVG 1.1 spec defines suspendRedraw() and unsuspendRedraw() methods which seem to have somehow similar purpose, though those can be applied only on <svg> elements, are supported only by Firefox and are going to be deprecated in SVG 2.0.
This is not true or at least it is more complicated than you suggest.
The computationally complex bit is triangulating the image. If you can do that the graphics card will have an easier time drawing the vectors than it will shuffling all those textures around. In fact you could send all your vectors in one draw call.
What we need is browsers caching SVGs as geometry not pixels.
I will note that Flash also had some really terrible redraw logic; if you had a largely static image with something animating in the upper left and lower right corners, the dirty rectangle would cover the whole thing.
Around the Flash Player 10 days, I remember seeing a presentation from someone at Adobe that showed off their debug feature that allows developers to see dirty rectangles. The demo showed that the renderer would use up to two dirty rectangles when redrawing. In your example with two corners, it wouldn't be one giant rectangle that filled the full stage. It would be two smaller rectangles, as one might expect. However, once something was moving in a third corner, one of the two rectangles would need to expand.
Again, this was probably 3-5 years ago, and older versions of Flash Player may have been less optimized. This may be one of the many optimizations they made to Flash Player after Apple decided it wasn't fast enough for iPhones.
Those things shouldn't slow you down at all if you aren't using them: this is a browser optimization issue. The browser knows that the SVG has not changed in any way, and can with absolute accuracy discern that it can simple blit the pre-rendered raster.
Browsers have not optimized SVG at all, painfully clear when the simplest retained dynamic SVG graphic is magnitudes slower than building entirely new framebuffers from scratch for every frame, ala canvas. It is trivial to see that the former should see dramatic optimizations that make it a significant winner, but in actual practice that just hasn't happened.
So it's a classic chicken/egg thing. No browser maker does anything to optimize SVG because few use it. Few use it because it's so unoptimized.
The findings of this post remain the same in either case, and is completely correct, but it shouldn't be this way. It isn't right that this test favors PNG.
I think this captures the state of the world more accurately. Every time that someone discovers how cool SVG would be if it did what the documentation said it did in browsers, they follow up with "but this actually sucks in real browsers". If the early reports of IE10 support hold up this might change.
It was my hope that retina screens would be the force to finally put real SVG support into browsers (and by real I mean both standards compliant and accelerated) because they benefit so much from line content using SVG.
In some ways though, this reminds me of the arguments about the speed difference between static languages and dynamic languages being an "interpreter optimization issue". Well, yeah, but, the reason these things are slow is because optimizing them is kind of hard. I think the SVG spec was more designed for correctness than it was for speed.
I'm saying this from experience because I've actually been working on a library for supporting a subset of SVG in OpenGL because I wanted to use vector graphics for games, and it's not impossible or anything, but I will say I have a great deal of respect for projects that manage to get this fast. The SVG spec is not hardware friendly in the least bit. Almost every filter operation assumes a new clean render target, which is conceptually clean and fine, but it's murderous on fill rate and texture memory, and that's just the tip of the iceberg of things that translate poorly to modern hardware.
>Well, yeah, but, the reason these things are slow is because optimizing them is kind of hard.
Optimizing all cases is most certainly hard. Optimizing the most common cases -- the lowest hanging fruit -- is attainable (which is exactly what has happened and continues to happen with dynamic typing languages, since you point that out, and has happened substantially to the DOM, which itself is as complex or more complex than SVG but its layout optimization was obviously prioritized).
In this case we're talking about static SVGs that -- with no change in zoom, context, or content (ergo nothing that would change their actual rendering at all) -- are completely rebuilt on every translation. This is true generally in the browser rendering engines of SVG, where compositional elements that could see caching are instead from scratch on each and every render.
This SVG/Canvas thing reminds me of this visualization[1] I did last month or so which originally made heavy use of SVG, because it was just about good enough on Chromium (and it made sense for d3js and hexbons)... but when I tested it under Firefox, it was just unusable.
So I recoded it to use canvas instead (with a switch to allow using one or the other) and there is just comparison, it's much faster everywhere. I've had reports that the SVG version was working fine on IE10 though, but couldn't test it because there's no IE10 for Linux of course.
It quickly becomes frustrating to make complex visualizations when SVG makes a lot of things much easier, but you constantly hit the limits of SVG performance on the common browsers.
Amen. Discovered this two years ago. FF without Direct2D (i.e. XP) sucks greatly for SMIL SVG animations. It is such a shame as many complex things were trivial with the SMIL/SVG API's, but FF and Chrome have a long list of bugs and missing API implementations which they apparently don't care to correct.
No browser maker does anything to optimize SVG because few use it.
You said something like that multiple times in your post, but IE seems to handle a lot of SVG work much better than Firefox or Chrome, and has done since at least version 9.
SVG is nice because it gives us additional flexibility -- it's resolution independent (so you don't need to redraw your image by hand when higher-DPI displays come out) and allows for animation[0]. But if you don't need those things (and you probably don't for your sprites) then they'll just slow you down.
[0] http://en.wikipedia.org/wiki/SVG_animation