1507018 - Investigate optimizing SVGs loaded on the startup path somehow (for example, using sprites)

Status: NEW

(Firefox :: Theme, enhancement, P5)

Description

[Brian Grinstead [:bgrins]]

When looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1505944 for browser.xhtml perf investigations I noticed we were seeing some time waiting for MozSVGAsImageDocumentLoad before onload could be processed.

That got me wondering if replacing a bunch of the svgs with a single one would lead to a win even in browser.xul, and it does appear to:

- Patch: https://hg.mozilla.org/try/rev/2ddb435be03b
- Compare (talos-other-e10s only): https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=068b0a5c21a8869f870be1f76eb9628f61204910&newProject=try&newRevision=a9f2f3ba1bcb9bfa9e886348b5798a3dc02bfe40&framework=1&showOnlyImportant=1

Looks like some potentially nice wins. Of course, it breaks the UI since it replaces all images with the same thing, but Potch mentioned we might be able to do something with sprites where we build all of the "startup" SVG files into a single file and use them like sprites (here’s an example of that: https://codepen.io/chriscoyier/pen/GndhE). I’m not sure how much of the win will be maintained when we do actually have to parse out the whole sprite.

Anyway, I did some logging later on and saw that these files fire MozSVGAsImageDocumentLoad before onload when opening a new window (at least on my local build), so that could be a starting point for looking more deeply into this:

- chrome://browser/skin/reload.svg
- chrome://browser/skin/stop.svg
- chrome://browser/skin/home.svg
- chrome://browser/skin/sidebars-right.svg
- chrome://browser/skin/forward.svg
- chrome://browser/skin/back.svg
- chrome://browser/skin/arrow-left.svg
- chrome://browser/skin/add.svg
- chrome://global/skin/icons/arrow-dropdown-16.svg
- chrome://browser/skin/search-glass.svg
- chrome://browser/skin/library.svg
- chrome://browser/skin/sidebars.svg
- chrome://browser/skin/menu.svg
- chrome://browser/skin/chevron.svg
- chrome://mozapps/skin/places/defaultFavicon.svg
- chrome://global/skin/icons/close.svg
- chrome://browser/skin/places/bookmarksToolbar.svg
- chrome://browser/skin/places/unfiledBookmarks.svg
- chrome://browser/skin/places/folder.svg
- chrome://browser/skin/tabbrowser/loading.svg
- chrome://browser/skin/forward.svg

Comment 1

[:Gijs (he/him)]

My understanding was that we picked the current individual-images way based on discussions with folks who knew about svg and its perf characteristics, and that there were also downsides to SVG sprites. Maybe jwatt can say more.

We'd also have to be a little bit careful with how this works with the fill colour hacks that we currently have to make this work with theming (ie not all these images necessarily end up with the same fill/stroke colour, I think).

Comment 2

[Jonathan Watt [:jwatt]]

(In reply to Brian Grinstead [:bgrins] from comment #0)
> - Patch: https://hg.mozilla.org/try/rev/2ddb435be03b

Try that with a different fragment identifier tacked onto each reference to arrow-left.svg (an integral part of the sprite system). You'll find that a new instance of the SVG is now loaded for each reference, and furthermore things will actually get slower due to the fact that each instance of arrow-left.svg now contains tons *more* SVG than it did before (or it would do once you added all the sprites to it).

For prior analysis see bug 1054016 and the various bugs linked from it.

Perf can certainly be improved. For example, fixing bug 1121693 (which is now unblocked) would probably be helpful. If perf is really an issue though probably I should finish off bug 1353771. That would require some coord between managers to get approval for me to do that from Maire though.