That's just a browser problem: for such static graphics it shouldn't matter what the original image format is.
The browser will generate an internal bitmap for each decoded PNG image, and uses that for blitting/compositing. Any decent browser ought do the same for SVG icons as well (and just invalidate the bitmap when the SVG image size/rotation or page zooming changes). When compared to blitting, stroking and filling paths is expensive and so is PNG decoding.
Of course, SVG can be rotated and scaled and animated nicely, unlike PNG. That will obviously be slower if done every frame. But this isn't the case and shouldn't be the case for such static icons.
(Of course, the current state of affairs probably is as described on the demo page. But it doesn't need to be.)
That works for the sprite example, but it doesn't generalize to all SVGs.
The problem is SVG filters let you do some pretty cool compositing stuff, but you can't necessarily generalize those effects in a static image. For instance, you could blur elements on the page using an SVG blur filter overlayed over your html elements, but if you're just blitting from a static buffer (like with a PNG), it's going to be wrong, so now you're not just paying attention to if the SVG changes, you also have to pay attention to if anything underneath it or around it changed. It's not an impossible problem, but I think you could still call a browser decent if it doesn't bother with that sort of specialized optimization.
Ad far as I know there is no browser which implements the 'enable-background' part of the SVG spec, so the problem of SVG filters applying to HTML content underneath them does not exist in practice.
>The problem is SVG filters let you do some pretty cool compositing stuff
This is true for every single DOM element, which can layer and obscure and filter and be additive/subtractive and can have levels of translucency. This is not a novel problem with SVG, but it's one where the appropriate solution is a simple
if (isComplexCase) {
// do uglier, more processor intensive activities
} else {
// do things the short and simple way
}
The universe of possibilities on an artifact don't prescribe a baseline performance level unless you're actually using them.
And just to be clear, I don't fault the browser makers at all regarding this (any of us can contribute to Chromium/Webkit/Firefox), as they are simply optimizing their efforts towards the things that yield the biggest return, and optimizing SVG just isn't that critical. Yet this leads to a circular situation where we endlessly hear that you shouldn't use SVG because performance suffers.
SVG has the added problem of not knowing what size/detail it needs to be rendered to - while the image has a size it never knows to what scale it's going to be drawn. If we could provide hints we'd be able to cache a bitmap and scale it without the need to redraw. Even better would be to do away with the bitmap altogether and draw them as triangles.
I'd love to see some of the new vector map detail algorithms applied to SVG - the ones where you throw away any detail smaller than a pixel. Then we'd be able to zoom smoothly or (if the points need to be calculated and cached) progressively loading (and possibly streaming) detail.
It's quiet possible IE is doing the sensible thing and caching the images. It's really more a black mark on firefox and chrome than it is a commendation of IE.
That seems a little unfair. Presumably somebody on the IE team recognised the potential improvement here and wrote code to implement it. Isn’t that sort of attention to detail worthy of praise?
This demo is symptomatic of a general and irritating trend with modern Chrome and Firefox: the development teams seem to be very interested in doing enough to tick a box claiming they support a certain feature, but the quality of implementation can still be poor, sometimes to the point of being unusable as in this case. SVG is a common culprit, but for example typography in Chrome is another repeat offender.
It seems absurd that on a fairly high-spec PC I’m using to write this, Firefox running this simple SVG demo consumes more system resources than Maya doing production-quality 3D rendering. But something seems to have gone wrong with Firefox specifically a few months ago, because simply scrolling up and down a page now seems to be enough to ramp a workstation GPU up to full speed, and consequently just browsing a few pages using Firefox for half an hour can have the GPU fans running fast enough to be loud and the UPS showing a noticeably increase in power consumption for the workstation. Unfortunately, I’m not sure what could possibly explain this or exactly when it started happening, so it’s difficult to file any sort of useful bug report. :-(
>This demo is symptomatic of a general and irritating trend with modern Chrome and Firefox: the development teams seem to be very interested in doing enough to tick a box claiming they support a certain feature, but the quality of implementation can still be poor, sometimes to the point of being unusable as in this case. SVG is a common culprit, but for example typography in Chrome is another repeat offender.
That's development in general. Is it not? It's hard to find houses that don't have a focus on stuff like that. As averse as I am to it, I also have to admit it is a good thing. It's just embarrassing when the covers come off and the dirty hacks are revealed.
Which is why I found it odd to see such a decent UX from IE. Microsoft really never wanted to support SVG, so I didn't expect comparatively good support. There is a lot of stuff in WPF and presumably SilverLight that is analogous to SVG, so it isn't as if Microsoft doesn't know how to hardware accelerate geometry drawing.
Considering the vast majority of our time behind the computer is spent with software that uses 2D graphics, it is kind of ridiculous that we still don't properly exploit our graphics hardware for vector graphics.
Luckily the hardware vendors are already working on fixing this. Here's an example of a particularly problematic scene rendered using NVIDIA's GPU-Accelerated Path Rendering, compared to Skia, Cairo, QT and Direct2D:
(On a sidenote, I guess this is why IE10 is often faster at rendering SVGs than the other browsers: it uses Direct2D, whereas Firefox and Chrome use Skia).
Using graphics hardware should be more energy-efficient, so maybe we will finally see a change because of mobile devices with HD screens.
Just to throw this in: my iOS project Ejecta[1] also does all the Vector drawing on the GPU using OpenGL ES2. It's not as advanced as NVidia's implementation (e.g. Ejecta computes all bezier points on the CPU and just draws on the GPU), but it's still much faster than what Apple is doing in CoreGraphics.
Have you looked into using Loop-Blinn[1] for drawing Beziers? I'd love to be able to use the GPU for vector graphics and Loop-Blinn seems to solve the problem of drawing curves, but I'm still looking for a way to get coverage-based antialiasing when drawing straight lines with the GPU.
Anti-aliasing seem to be why we still prefer pixel art over vector art. I thought high-res would eliminate this problem (more pixels, less worry about artifacts), but apparently not yet.
The Loop/Blinn work is really cool, and of course we now have hull shaders to really exploit it. It is a problem many people are actively working on...e.g. with Direct2D, but doing everything on the GPU is currently infeasible given round trip times between the CPU and GPU. Great if you can render everything in one pass, not so great if you can't.
If you set the drawsAsynchronously or acceleratesDrawing property on a CALayer (the former is public and the latter is private), then the CGContext passed to you in -[CALayer drawsInContext:] or -[UIView drawRect:] will be GPU-accelerated in the same way. WebKit on iOS uses this to accelerate 2D rendering.
Having said this, don't go turning this on everywhere, like on every tiny little UILabel. That GPU-accelerated CGContext is rendered in an offscreen pass using render-to-texture so it is often faster to use the CPU. This property was more designed for, say, a full-screen drawing app on a retina iPad that uses a a single screen-sized CGContext for its drawing canvas, or for the Safari case where there are a number of same-sized CGContext tiles to draw into.
That is a really cool project, thanks for sharing!
> (e.g. Ejecta computes all bezier points on the CPU and just draws on the GPU)
I guess that's where the biggest gain comes from with NVIDIA: it's the only pure-GPU option right now, which probably eliminates quite a few bottlenecks. Freeing up the CPU is also never a bad thing.
Is Safari/native WebKit hooking straight up to Core Animation on OS X and iOS? I know when the Windows version was still around its WebKit was using Direct2D, even before IE did. I wonder what that would look like in the comparison.
> (On a sidenote, I guess this is why IE10 is often faster at rendering SVGs than the other browsers: it uses Direct2D, whereas Firefox and Chrome use Skia).
I think Firefox on Windows uses Direct2D, at least for Canvas, not sure if for img tags.
The hard bit isn't the drawing of the vectors - it's the conversion from vectors to triangles (triangulation) it's non-trivial and can be slow for complex (and complexly filled shapes).
This is the big reason we had to write a pixmap caching layer for icons/Plasma themes/etc. in KDE.
GTK+ goes one better, and they compile an entire icon theme into a single mmap-able file with the data in a static GdkPixbuf format. Sadly I'm not sure how to map that to a QImage in general, otherwise I would have adapted that theme cache (where present) into KDE.
Sprites are a dirty hack that works around the fact that HTTP 1.0 only allows one asset to be returned per request. Using CSS background-images to represent content is semantically gross.
If you wanted to the same advantages with SVG, you shouldn't be using CSS sprites; you should take advantage of the fact that SVG is a text-based format and concatenate them all together. Then, you can use some really simple JavaScript to insert each child SVG into the correct place in the DOM.
The ideal way to handle this would look like this:
<img src = "icons.svg#map" />
where map.svg was the original file on the developer's machine. A grunt task could concatenate all the SVGs in a particular folder together and give them IDs according to their file names. In the client's browser, a JS prollyfill would iterate over all the img tags where src ends in a hash and replaces them with the child SVG of that ID.
Just as the prevalence of $$ inspired querySelectorAll, an SVG-optimized spriting system could inspire browser vendors to properly handle hashes in src attributes. and the need for the prollyfill (or the ugliness of CSS spriting) would fade over time.
How would you make HTTP better? How could you get it to send multiple files per request, because, while a little weird in some ways. HTTP is really quite well designed, there isn't really a good way to send multiple files with one request, unless you want to mage HTTP kinda hacky.
Sorry, I've had to write an HTTP compliant server recently, and I don't think there's any good way to send multiple files without completely redesigning the protocol, and even doing that, I don't think there's a good way to do it. Plus, keeping requests atomic makes more sense than bungling then together.
I know the main point of your comment wasn't too make HTTP better, just that sprites are, in your opinion, a bad hack, but your implying that HTTP is bad. Also, and this is just nitpicking, everyone uses 1.1, which has persistent connections in the spec, which help negate some if the computing cost for sending multiple files.
SPDY[1] multiplexes multiple assets over one connection, which will (one day; many years from now; eventually) resolve some of the performance issues with HTTP and TCP.
You can already use SPDY now (and fall back to HTTPS), FWIW.
I wasn't trying to bag on HTTP 1.0. I was just noting that HTTP 2.0 (fka. SPDY) includes support for sending related assets along with the requested resource.
Updating scrollTop is a pretty slow way to scroll on some browsers. Have you tried animating `transform`? That gets you hardware acceleration on webkit at least
Animating transform doesn't affect page scroll, which is a more useful use case (since users need to scroll a page) than being able to use a translate transformation.
Of note, a translate transformation still isn't perfect. It seems to chug and then turn into a smooth animation.
Eh, updating page at end/cancel easy enough. I use this approach to animate a page scroll:
1. Animate #transform using jquery's animate (which doesn't work out of the box unfortunately, you have to use a custom #step fn)
2. Install "capture" event handlers on document.body that will cancel the animation, reset scrollTop to the state of the transform, then reset the #translate to 0 on #scroll or #touch (so we don't "fight" the user scrolling)
3. .. animation runs, calls my "complete" callback which uninstalls the event handlers, sets #translate back to 0, and updates scrollTop. Unfortunately there is a noticeable "glitch" here if the user tries to immediately further interact with the page.
#2 is optional (OP's implementation didn't handle canceling anyways). I'm sure there's a jquery plugin to do this and degrade to scrollTop on non-webkit browsers.
Additionally, jQuery is not known for its performance, especially regarding animations.
For me, on Chrome Canary, the animation "chugs" every 20-30 frames (from 60 fps to a frame that takes 200ms). It's almost entirely in rendering, and it's immediately following a jQuery callback. It only happens when scrolling down. I'd like to see this done with a very simplistic requestAnimationFrame tweener to compare the same type of animation against something that is doing nothing else but computing a new scrollTop and setting it. I have a strong feeling, in Chrome at least, that the problem here is jQuery, not SVG perf.
Additionally, for other browsers, I'd like to see this tested with icon fonts.
off topic, but IE 10 is really good browser, I just recently discovered how good Devtools are (I dare everyone to go and check). And compared to Chrome the RAM and CPU are less drained.
I'd consider using it again, but the UI is just so ugly. Maximized, it has a useless border at the top of the window for no reason (which hurts on low res laptop screens). And in general, the tabs are next to the URL, so you never get to see a remotely full title or URL. And, to top it off, the URL/tab part looks like a dev preview. It doesn't look like anyone took time to make that part look pixel perfect. For general purpose use, I'd expect all modern browsers to deliver a generally decent experience, so the actual chrome is relevant.
On top of that, IE10 has no plugin model, so getting basics like privacy and ad blocking - there's just no reason to use IE10 outside of specific demos.
IE10 only has a smaller chrome when windowed. When maximized, it has the same (within a couple px) top chrome, but combines tabs and nav into one, so the chrome is actually less useful. It's mind-boggling that MS shipped something with so little polish.
Can someone point me to the latest browser distribution on the planet? Last check it was 50-50 tussle between IE and non-IE (If I can call it this way) browsers.
Microsoft already had hardware accelerated xaml (which is almost identical to SVG) with shaders for bitmap filters: blur etc. I would hope they were able to draw upon that work for their SVG implementation.
Maybe I'm mistaken. It's been a while since I've worked with xaml. We built the first hardware accelerated xaml renderer that was fast apart from the triangulation but I wan't working for MS. MS at that point had two xaml implementations WPF & Silverlight: I thought one of them was hardware accelerated eventually (one of them certainly gained hardware shaders).
Adding #container {-webkit-transform: translateZ(0);} puts the whole div as a texture onto the GPU as a composited layer. This improves scrolling massively, but interestingly SVG still has a little bit more jank than the PNG version.
See http://jankfree.org
It probably would also help if this were done as pure inline SVG instead of CSS background images. It doesn't surprise me that adding a ton of SVG background images to the page would cause some browsers to behave badly.
There are icons in the SVG sprite set which consist of numerous clip paths, which could be the root cause of the performance issue. If you load the sprite in Chrome (http://adrianosmond.com/images/sprite.svg) and inspect the element immediately above the facebook logo you will see an example of this. That aforementioned icon could possibly have been created using a single line path and gradient fill (I've not edited SVG files for a while).
You cannot have a gradient following a curve. At least not yet. You could probably use some filter trickery and thus create a fill where a gradient follows the path but I bet that's much worse than a few dozen paths.
What's strange is that scrolling SVG can be quite smooth in browsers, at least in Chrome. The map library Leaflet, or instance, makes a point of panning the map with -webkit-transform: translate3d() and it animates very smoothly. I wonder why scrolling the whole window like this is worse?
SVG is scalable, if you have a vector-graphic that is a clear advantage. For pixel-graphics PNG is better. A downside is, that the Internet Explorer supports SVG only with the coming version 9 (before with plugin). Mobile browsers may also have limited support for SVG.
I would say PNG simply for the fact it seems to be a more accepted format than SVG.
Just as an aside Firefox has a bug which means it blurs SVGs that are being displayed at a different background-size than 100% 100% (or equivalent in other units), if the width and height set in the SVG is smaller than the size at which it is displayed as a background image. This happens because Firefox apparently (only for background images) renders the SVG at it's size settings and then scales it for use in the page.
This is the same type of issue as discussed in the example - it's a bug in the browser not a problem with SVGs in general.
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.
I know EaselJS library has capability to cache the bitmap representation of SVG, so if you do not change stroke settings, paths, etc. it works really fast. When you change, you need to update the cache manually. This works for HTML5 Canvas, but they also have DOMElement class which is still experimental so YMMV. Or maybe there is some other lib. that does specifically for DOM.
Huh. Interesting. Activity Monitor gives me some weird numbers for Safari's performance as I watch this on my
dual i5 Macbook Air.
When scrolling the PNGs up and down, Safari oscillates between 64 to 94% CPU usage.
When scrolling the SVGs up and down, it goes between 36-54% CPU. Very very strange. I wonder if it has something to do with the fact that the SVG is dropping about a zillion frames.
Are you looking at just the Safari process or also the Safari Web Content process and the parts of the work Safari offloads to WindowServer and whatnot?
So this is an interesting case for animation, but turn off the javascript and try real-world (manual) scrolling -- both pngs and svg perform about the same for me in Chrome (osx).
I'm not sure there's much of a takeaway here unless you're trying to animate the page scrolling of a full page of sprites (i.e., the example proves itself, but not much else).
What is it? What shoud I see? What does it demonstrate?
I followed the link which opens an html/css/js editor in which I cannot do anything. After some search I saw a white page with a list of icon a radio button switching from png to svg and some text about framerate where I do not see any animation or any difference between the two!
I'd be interested to see you icon-fonts perform in the test. (knowing that it is not really the same thing as you only have monochrome icons in fonts, unless you layer them)
Safari 6 and iTunes 11† already use CoreAnimation for scrolling. Mavericks "merely" extends this to other apps.
†: Saf' was advertised to do so, and since neither respect defaults write -g NSScrollViewRubberbanding -bool false while being butter smooth, I concur iTunes does so too.
Closed after noticed the page will scroll up/down automatically. Quickly tried SVG version and my browser (latest Firefox) skyrocketed CPU.
Guys, please make your pages usable since (we), users, are not interested in you-think-it-is-cool effect. I'm going to avoid this page like plague until author fixes it.
The browser will generate an internal bitmap for each decoded PNG image, and uses that for blitting/compositing. Any decent browser ought do the same for SVG icons as well (and just invalidate the bitmap when the SVG image size/rotation or page zooming changes). When compared to blitting, stroking and filling paths is expensive and so is PNG decoding.
Of course, SVG can be rotated and scaled and animated nicely, unlike PNG. That will obviously be slower if done every frame. But this isn't the case and shouldn't be the case for such static icons.
(Of course, the current state of affairs probably is as described on the demo page. But it doesn't need to be.)