Bug 106158 – Change SVG image cache to be per-size instead of per-renderer

• Status: RESOLVED
• Resolution: INVALID
• Component: SVG

[Philip Rogers]

The SVG image cache is currently per-renderer which makes it almost useless. Consider this example of 60 <img> tags with an SVG tiger:
http://philbit.com/SvgImagePerformance/image.html

We can knock this benchmark out of the park if we change the cache to be global or per-image-resource.

[Philip Rogers]

Created attachment 182273 [details]
Preview patch - move SVGImageCache into SVGImage

Not yet ready for review.

[Philip Rogers]

Update for posterity:
A caveat of caching per-size instead of per-renderer is we cannot have two users of an image rendering at different animation states. This is already our behavior but I don't think it has ever been explicitly stated (and it's untested).

I talked with dholbert on IRC and Mozilla's interpretation of the spec is that there is a single document animation timeline that all image renderers use. Therefore, like us, Firefox does not support different animation states. Opera does support different animation states, and IE10 does not support SMIL animations at all. Caching per-size will maintain our current behavior and we will continue to match Firefox.

[Philip Rogers]

Thorton (via email) pointed out that Nikolas' original SVGImageCache patch mentions a related issue:
// FIXME: This doesn't work correctly with animations. If an image contains animations, that say run for 2 seconds,
// and we currently have one <img> that displays us. If we open another document referencing the same SVGImage it
// will display the document at a time where animations already ran - even though it has its own ImageBuffer.
// We currently don't implement SVGSVGElement::setCurrentTime, and can NOT go back in time, once animations started.
// There's no way to fix this besides avoiding style/attribute mutations from SVGAnimationElement.

This is slightly different than the situation I was thinking of (it's multiple documents referencing a single image instead of multiple <img>s referencing a single cached image), but it will affect our cache. A solution is to simply track the document as part of the key in our cache.

Firefox also seems to be affected by this so I filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=830211