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)
Core
SVG
Tracking
()
People
(Reporter: jwatt, Assigned: jwatt)
References
Details
(Keywords: perf)
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•7 years ago
|
||
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.
Assignee | ||
Comment 2•7 years ago
|
||
For lack of a better term, I'll refer to this as "Lightweight SVG" or "LSVG" for now.
Alias: LSVG
Comment 3•7 years ago
|
||
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.
Comment 4•7 years ago
|
||
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-]
Comment 5•7 years ago
|
||
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.
Comment 6•7 years ago
|
||
And of course it's worth linking to one of IconVG's inspirations: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
Comment 7•7 years ago
|
||
Are we talking about doing this for 57 or in general?
Assignee | ||
Comment 8•7 years ago
|
||
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... :/ )
Assignee | ||
Comment 9•7 years ago
|
||
(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.
Comment 10•7 years ago
|
||
(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.
Assignee | ||
Comment 11•7 years ago
|
||
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.
Assignee | ||
Comment 12•7 years ago
|
||
Assignee | ||
Comment 13•7 years ago
|
||
Assignee | ||
Comment 14•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Attachment #8871210 -
Attachment is patch: true
Assignee | ||
Comment 15•7 years ago
|
||
Updated•7 years ago
|
Priority: -- → P3
Comment 16•7 years ago
|
||
Would image/lsvg be exposed to the web, or only chrome content?
Assignee | ||
Updated•7 years ago
|
Comment 17•6 years ago
|
||
Patch exists for this, why those are not applied?
Comment 18•6 years ago
|
||
(In reply to Massimo Fidanza from comment #17) > Patch exists for this, why those are not applied? Did you read comment 11?
Updated•6 years ago
|
Updated•2 years ago
|
Performance Impact: --- → -
Whiteboard: [qf-]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•