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.
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.
See: http://www.w3.org/TR/SVG/filters.html#AccessingBackgroundIma...