4 ms·

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

by yason 13y ago

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

Nekorosu 13y ago
Thanks for sharing the thought 'cause at first the demo looked meaningless to me. Now it makes sense.
overgard 13y ago
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. See: http://www.w3.org/TR/SVG/filters.html#AccessingBackgroundImage http://www.w3.org/TR/SVG/filters.html#AccessingBackgroundIma...
- corresation 13y ago
  >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.
  - sambeau 13y ago
    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.
    - seanmcdirmid 13y ago
      I believe Loop and Blin have done a lot of work in this area. See for example, http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf http://research.microsoft.com/en-us/um/people/cloop/LoopBlin... If someone like Ben Constable is lurking in this thread, he'd be able to say more this; I am extremely ignorant about this problem.
- jahewson 13y ago
  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.
sageikosa 13y ago
Never thought I'd write this about SVGs, but it looks OK on IE, and choppy on Chrome.
- deleted 13y ago
  [deleted]
- GhotiFish 13y ago
  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.
  - Chris_Newton 13y ago
    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. :-(
    - GhotiFish 13y ago
      >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.
sambeau 13y ago
It would be better if the browser cached the image as triangulated geometry. Then it would be much faster to draw and could be arbitrarily scaled.

by yason 13y ago

Nekorosu 13y ago

Thanks for sharing the thought 'cause at first the demo looked meaningless to me. Now it makes sense.

overgard 13y ago

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

corresation 13y ago
>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.
- sambeau 13y ago
  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.
  - seanmcdirmid 13y ago
    I believe Loop and Blin have done a lot of work in this area. See for example, http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf http://research.microsoft.com/en-us/um/people/cloop/LoopBlin... If someone like Ben Constable is lurking in this thread, he'd be able to say more this; I am extremely ignorant about this problem.
jahewson 13y ago
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.

sageikosa 13y ago

Never thought I'd write this about SVGs, but it looks OK on IE, and choppy on Chrome.

deleted 13y ago
[deleted]
GhotiFish 13y ago
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.
- Chris_Newton 13y ago
  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. :-(
  - GhotiFish 13y ago
    >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.

sambeau 13y ago

It would be better if the browser cached the image as triangulated geometry. Then it would be much faster to draw and could be arbitrarily scaled.