Open Bug 1353771 (LSVG) Opened 7 years ago Updated 2 years ago

Investigate implementing a lightweight subset of SVG for SVG-as-an-image in our UI

Categories

(Core :: SVG, enhancement, P3)

enhancement

Tracking

()

Performance Impact none
Tracking Status
firefox55 --- affected

People

(Reporter: jwatt, Assigned: jwatt)

References

Details

(Keywords: perf)

Attachments

(4 files)

I'm investigating implementing a subset of SVG not based on nsIDocument for  the SVG images used in our UI. There will be no nsIDocument, no DOM, no nsIFrames, no CSS, no animations and no display lists or layers.

We have made some huge performance and memory use improvements for SVG-as-an-image over the last few years, but we're now into the long tail and performance improvements are harder to come by. The majority of SVG icons used in our UI are very simple, but we're still paying the cost of a full-SVG implementation including an nsIDocument and all the things that go with that. We should be able to implement a much lighter weight version of SVG with a very narrow feature set.
It's unclear exactly what an initial implementation would require, but here's an initial pass:

 * root-<svg> with 'width', 'height' and 'viewBox' attributes
 * units would not be supported on <length> values
 * <path> with the 'd', 'fill', 'fill-opacity', 'stroke' and
   'stroke-opacity' attributes, but supporting simple colors
   and the 'context-fill' and 'context-stroke' values only

Following on from that we could:

 * support <g> with the 'transform' and 'opacity' attributes
 * support the 'transform' attribute on <path>
 * maybe support other shapes

It's not clear whether it would be worth supporting filters or gradients etc. given that their overhead may dwarf the general overhead of using the full SVG implementation. If so, then it would seem to make sense for the UI to just continue to use normal SVG files for those cases.
For lack of a better term, I'll refer to this as "Lightweight SVG" or "LSVG" for now.
Alias: LSVG
I've thought about doing something like this as well.

My feelings were to drop the SVGness completely and have a binary format with a minimum of features. i.e. just a simple container that contained filled paths and the ability to animate them. I think taking inspiration from the flash format would be wise.
This doesn't really fit under the traditional QF umbrella as we have been talking about so far.  But this is a pretty important issue.  If we do need this for Photon we should absolutely do it.

I'm gonna qf- for now, but if this need prioritization help, please renominate again, I'd be happy to assist.  :-)
Whiteboard: [qf] → [qf-]
One attempt at this is IconVG: https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p8k8 https://godoc.org/golang.org/x/exp/shiny/iconvg

It seems reasonable and good thing to compare with or start from.
And of course it's worth linking to one of IconVG's inspirations: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
Are we talking about doing this for 57 or in general?
IconVG looks pretty cool, and implementing an IconVG/Haiku/our own Flash inspired format would be a fun project to work on! That said it seems like the wins over a lightweight SVG document would mainly be in the parsing. I don't remember ever seeing parsing turn up in profiling of SVG images though, so it's not clear to me that any wins would be significant or worth the implementation effort. Of course, if all the DOM, frames, display list, etc. overhead is avoided, then maybe the XML parsing of a handful of tags would end up being a significant proportion of the remaining image processing time...

I'd also be a bit worried that trying to settle on/modify/develop another format might end up being a lot more time consuming.

Sticking with a small subset of SVG has the advantage that no extra tooling or modifications to workflow are required for the frontend folks. (It also has the disadvantage that it would reduce any motivation to implement something better... :/ )
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #7)
> Are we talking about doing this for 57 or in general?

I'm certainly aiming for something for 57.
(In reply to Jonathan Watt [:jwatt] from comment #8)
> Sticking with a small subset of SVG has the advantage that no extra tooling
> or modifications to workflow are required for the frontend folks. (It also
> has the disadvantage that it would reduce any motivation to implement
> something better... :/ )

Either way, it's certainly valuable to figure out the stuff that we would want to take out of SVG. It would always be possible to do a binary format/transcoding afterwards.
Depends on: 1360063
Depends on: 1360511
Blocks: 1362395
Just a quick update on this. A bunch of work has been put into reworking our UI SVG icons to take advantage of the new context paint feature implemented in bug 1058040 et. al. (allowing us to do things like avoid using filters to color icons - bug 1359073) and to restructure our SVG to avoid badly performing usage patterns (such as the blockers for bug 1358998). This work was in large part motivated by the prospect of then being able to process those restructured SVGs as LSVG. As it happens, that work has in itself turned out to significantly reduced the amount of time we spend processing SVG icons. So much so that it's unclear whether it's worth landing an LSVG implementation since SVG is now hardly showing up in profiles at all.

The one thing that we would still benefit from with LSVG is a reduction in memory use. Currently we seem to be using about 70 KB per SVG icon that simply contains a short <path> element (see bug 1362395).

At any rate I'll attach my current LSVG patches. They mostly seem to work, but could do with a bit of a tidy up before review, if we decide we want to land them.
Attachment #8871210 - Attachment is patch: true
Priority: -- → P3
Would image/lsvg be exposed to the web, or only chrome content?
See Also: → 1403256
Patch exists for this, why those are not applied?
(In reply to Massimo Fidanza from comment #17)
> Patch exists for this, why those are not applied?

Did you read comment 11?
Blocks: 1465524
See Also: → 1027080
Performance Impact: --- → -
Whiteboard: [qf-]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: