See bug 1426295 comment 2, there are various stylist data which takes significant part of SVG document, which is not useful for most SVG-as-images. SVG-as-images cannot run any script, so the only thing which can affect selector matching would be SMIL animation on class attribute. We should be able to drop much of those data when there is no SMIL animation in the SVG-as-image. SVG-as-image would still respond to media feature change, though, so maybe there would still be something we cannot totally drop, but at least we should be able to drop invalidation-map, and after the initial style, we should also be able to discard element-and-pseudos-maps and probably rule-tree.
Arrgh, the class attribute thing is going to make it too invasive to be worth it I suspect :(. That animated class attribute is the one used to match selectors, right? If so, that means that we at least need to keep the class and attribute invalidation maps, which is probably most of them...
I think we can drop things when there is no SMIL animation, which should be the case for majority of SVG images, and probably all SVG images used in our chrome.
So, after servo/servo#19696, tracking-protection-16.svg#enabled now takes 19,120 bytes, in which 5696 bytes are from the rule tree and various maps for styling. Most other images now take ~11KB more memory than Gecko, and for most of those images, rule tree and the maps take 560 bytes (there are three take 480 bytes and one takes 640 bytes instead), so in total it would save us 36KB from the current regression of 251KB. Not sure whether it's worthwhile... If we want to do that, I guess we need to decide when to drop the rule tree and element / pseudo maps, since they are required in styling, and SVG-as-image can be styled more than once without redoing selector matching, e.g. for anonymous subtree of <use> elements.
If we're going to drop the rule tree and element / pseudo maps too, we should check we don't have any CSS animations or media queries.
Oh, that's going to be more tricky, although for chrome image case, it probably doesn't matter. I'm wondering why media queries matter? Don't we need to rebuild everything if media queries change, since they could introduce new rules, etc.? (Probably because we wouldn't be rebuilding the maps for other cascade level in that case?)
Yes, good point. Though we should make sure to drop the element / pseudo maps in a way that they can be re-created when the matched MQ changes.
It's not clear to me we whether dropping the rule tree is possible at all without implementing another way of doing the cascade, which is not great IMO.
You need to log in before you can comment on or make changes to this bug.