1027080 - Optimize a subset of SVG in order to make it possible to ship SVG icons in Firefox Desktop instead of PNGs

Status: NEW

(Core :: SVG, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Firefox Desktop, Gaia, and likely other Gecko-based apps have needed to use rasterized images for icons since SVG hasn't been fast enough / memory efficient enough to do the job.

SVG would be the preferable mechanism to draw these icons though, as it would make scaling to different screen resolutions trivial. For Firefox Desktop, this would also make it possible to leverage CSS awareness of platform colours in order to appropriately colourize the icons for alternative themes.

I talked with bz, bjacob and a few others during a Platform bootcamp thing, and I was told that the request to "make SVG faster" is kind of a monumental task because the SVG spec is _humongous_. Did you know it has (or, at least, had) a networking API? Networking in SVG. Unreal.

Anyhow, they suggested that the best way to move this forward would be to identify a small subset of SVG features that we require to optimize that we could knock off one by one.

I asked shorlander to come up with that short-list, and he's full-on delivered. Here's the short-list of features:

http://people.mozilla.org/~shorlander/svg-optimization-uses/svg-support.html

We should see if there are any wins to make for those features.

Comment 1

[Jonathan Watt [:jwatt]]

(In reply to Mike Conley (:mconley) from comment #0)
> Firefox Desktop, Gaia, and likely other Gecko-based apps have needed to use
> rasterized images for icons since SVG hasn't been fast enough / memory
> efficient enough to do the job.

What is this opinion based on? Are there other bugs that have been filed on the issues that you/others have encountered?

> I talked with bz, bjacob and a few others during a Platform bootcamp thing,
> and I was told that the request to "make SVG faster" is kind of a monumental
> task

It shouldn't be. Just be specific about what you'd like to do that you've found to be slow. We can then look at those things individually.

> because the SVG spec is _humongous_. Did you know it has (or, at least,
> had) a networking API? Networking in SVG. Unreal.

Now we're off in the weeds back to the good old badmouthing of SVG. The SVG spec is less complex than the CSS specs and considerably less complex than HTML 5, in my opinion. That networking thing you're referring to was back before anyone else was willing or interested in looking at providing such facilities for the Web platform, and many cool things were done with the plugin that supported them. In many ways the SVG WG at the time were just forward thinking and catering to demand. It wasn't until years later that we saw those same cool things on the Web at large. Funny how the fact that these facilities are now available in other forms doesn't raise any eyebrows. I guess it's down to people wanting to keep SVG as a graphics format, but nobody has really tried to restrain HTML to purely being a document format (happily!).

> Anyhow, they suggested that the best way to move this forward would be to
> identify a small subset of SVG features that we require to optimize that we
> could knock off one by one.

I'd rather that you just try use SVG to do what you want, see if it's slow, and file bugs on your real use cases as necessary. Please CC me on any such bugs or note any issues here.

> I asked shorlander to come up with that short-list, and he's full-on
> delivered. Here's the short-list of features:
> 
> http://people.mozilla.org/~shorlander/svg-optimization-uses/svg-support.html

Gradients and filters can be expensive under certain circumstances, but again we need concrete use cases to determine what we can do about that to meet the needs of Firefox Desktop.

Comment 2

[Jonathan Watt [:jwatt]]

Note there was some major improvements made in the memory use of SVG-as-an-image in the bugs blocking bug 999931. There are still more improvements that can be made, but more real world use cases would help focus efforts on the right things.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jonathan Watt [:jwatt] from comment #1)
> (In reply to Mike Conley (:mconley) from comment #0)
> > Firefox Desktop, Gaia, and likely other Gecko-based apps have needed to use
> > rasterized images for icons since SVG hasn't been fast enough / memory
> > efficient enough to do the job.
> 
> What is this opinion based on? Are there other bugs that have been filed on
> the issues that you/others have encountered?
> 

Speaking at least for Firefox Desktop, during the Australis project, we attempted to solve the problem of colouring for monochrome Linux icons by using SVG and using system colours. Performance was indeed a problem there from what I recall - I believe on the ts_paint Talos test. It's partially recorded in bug 874674.

> Now we're off in the weeds back to the good old badmouthing of SVG. 

I'm sorry, I didn't want to come across as badmouthing SVG - I was trying to express that it's not a simple drawing language, and so general fixes across the board for SVG are unrealistic.

> I'd rather that you just try use SVG to do what you want, see if it's slow, and file bugs on your
> real use cases as necessary. Please CC me on any such bugs or note any issues here.

Alright - we could start with Linux, and attempt to replace all of the monochrome icons with SVG, and see what it does to our talos scores, and then I guess we'll Cc you if / when they regress.

Thanks jwatt!

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #2)
> Note there was some major improvements made in the memory use of
> SVG-as-an-image in the bugs blocking bug 999931.

(bug 764299 should have helped here a lot, too, for non-SMIL-animated SVG being used as an image. We'll only draw the SVG once & cache that rasterization, to re-use for any subsequent repaints at the same resolution.)

Comment 5

[Daniel Holbert [:dholbert]]

(bug 764299 should have helped _with perf_, I meant to say. (not e.g. memory usage))

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Mike Conley (:mconley) from comment #3)
> Speaking at least for Firefox Desktop, during the Australis project, we
> attempted to solve the problem of colouring for monochrome Linux icons by
> using SVG and using system colours. Performance was indeed a problem there
> from what I recall - I believe on the ts_paint Talos test. It's partially
> recorded in bug 874674.

There's not too much detail there so another pass at this so we can do some measuring sounds great (bug 1054016 which I see you've filed looks good).

> I'm sorry, I didn't want to come across as badmouthing SVG - I was trying to
> express that it's not a simple drawing language, and so general fixes across
> the board for SVG are unrealistic.

It wasn't you I was having a dig at. No worries. ;)

> Alright - we could start with Linux, and attempt to replace all of the
> monochrome icons with SVG, and see what it does to our talos scores, and
> then I guess we'll Cc you if / when they regress.

Bug 1054016 for those following along. Thanks, Mike!

Comment 7

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (bug 764299 should have helped here a lot, too, for non-SMIL-animated SVG
> being used as an image. We'll only draw the SVG once & cache that
> rasterization, to re-use for any subsequent repaints at the same resolution.)

That definitely improved things, although that's a blocker of bug 874674 (and discussed in that bug) so I think those improvements had already been factored in at the time the Desktop guys ran into their issues?