Support a subset of SVG

[jdm]

We need to start experimenting with SVG support in order to have more confidence in using WebRender for Gecko. This issue will serve as a tracking metabug for that work. Our goal is to implement the smallest subset possible, such that particular testcases look correct. We should hide this behind feature flags to avoid exposing a half-baked SVG implementation to web content.

[jdm]

cc @jrmuizel

[jdm]

I am working from the assumption that https://www.w3.org/TR/SVG11/ is the specification to care about at this point.

[larsbergstrom]

@nical has been doing some awesome work in Rust around an SVG implementation, at least as of our discussions in London:
https://github.com/servo/servo/wiki/Webrender-Overview#stuff-nical-is-doing-around-svg-path-rendering

[jdm]

@nical's renderer is part of the work. I'm filing issues for the DOM and layout infrastructure surrounding that which will allow us to run representative benchmarks.

[jdm]

Initial milestone: http://people.mozilla.org/~jmuizelaar/svg-circle.html
Next step: http://www.themaninblue.com/experiment/AnimationBenchmark/svg/
Meaningful result: http://people.mozilla.org/~jmuizelaar/Animometer/developer.html?test-interval=20&display=progress-bar&controller=ramp&frame-rate=50&kalman-process-error=1&kalman-measurement-error=4&time-measurement=performance&suite-name=SVGsuite&test-name=SVGbouncingcircles

[metajack]

@SimonSapin has a parser already working that he was using for some experiments.

[SimonSapin]

I have a a parser for the micro-syntax of d attributes of SVG <path> elements that I put together with an existing XML parser and just enough hard-coded glue to render one carefully chosen example file :) https://github.com/SimonSapin/victor

I have written https://github.com/SimonSapin/victor/blob/master/src/svg/README.md about the state of SVG specifications as of a couple months ago.

Last time I discussed this with Jack we talked about using moz2d to render SVG to a pixel buffer, and give that to WebRender to treat as an image. I’m not sure how this would help with confidence in WebRender.

@pcwalton, @glennw, my understanding is that WebRender’s strategy is to not support arbitrary 2D graphics but specialize in CSS things like axis-aligned rectangles with rounded corners. Has that changed? (That is, would you want WebRender to support enough primitives to render SVG without something like moz2d?) Or more generally, what do you think is a good strategy to implement SVG in a browser that uses WebRender?

[SimonSapin]

pcwalton> just render it to a canvas, basically like today
pcwalton> I mean
pcwalton> not a true
pcwalton> but something like that
gw> SimonSapin: I think (without having read the entire spec) that doing native svg in wr is quite doable, and probably a sensible (long term) goal. Certainly writing to a canvas with moz2d is the easiest way to get a reasonable feature set working in a short-ish time frame. I guess I'm not really sure what is meant specifically by confidence and which would be the right path (ha)

[jrmuizel]

For this to be a valuable experiment for the gecko-webrender integration it's important for the implementation to be as webrendery as possible.

A basic sketch of what this would like is as follows:

• Add add_geometry, remove_geometry functions similar to the current add_image, remove_image functions
• Add svg_geometry, svg_text, svg_effects display items
• Geometry would be rasterized cpu side (but in parallel) just as glyphs are today.
• Webrender would composite the svg display items similar to how it composites other display items today

[glennw]

That seems like a reasonable way forward. @jrmuizel I think when we last discussed this you suggested that we could use something "off the shelf" for the geometry rasterization part?

[metajack]

@jrmuizel I like that plan.

[jrmuizel]

For now, it's probably best just to use Skia or Cairo for the geometry rasterization part. Both of these have fairly fast software rasterizers and support stroking and dashing

In the future we could experiment with something more sophisticated like Direct2D's rasterize to geometry approach or something else. However, that work is relatively well contained and as long as the majority of webcontent isn't going through this path I don't expect it to be a bottleneck that we need to care about in the near term.

[nical]

Since I am mentioned here, the SVG work I have been doing is in the lyon repository. For now it mostly does one thing: provide tools to build and tessellate flattened path fill operations. It only generates triangles, and the renderer using it is responsible for uploading/displaying the geometry. I am very happy with the how the tessellator is working out, although since I am doing this entirely in my spare time, it is progressing very slowly (If anyone is interested in helping out it would be great).

There's also a (work in progress) toy stroke tessellator that is simple but does not handle transparent overlapping geometry (overlapping pixels will be drawn twice instead of once).

The repo is split into small crates, some of which may be useful even when not using the tessellators:

• the lyon_bezier crate implements some useful quadratic and cubic bezier math including the flattening algorithm ported over from Gecko,
• lyon_path_builder and lyon_path_iterator implement some neat tools to, well... build and iterate over path objects.

Edit: I should mention that the tessellator only implements the even-odd fill rule at the moment, and that vertex-aa is not yet implemented (a bring your own anti-aliasing party for now). I'll eventually add whatever svg feature is missing when I have time.

[Ms2ger]

It's my understanding we should be working from https://svgwg.org/svg2-draft/

[gsnedders]

SVG 2 is now at CR, so is in principle now done. It makes a fair bit of stuff in SVG 1.1 optional, which also seems useful for this use-case. :)

[tigt]

Just a note that the SVG2 working group didn't have its charter renewed, and its future may be in doubt. (Those minutes also link to a spreadsheet where browsers declared intent on SVG2's proposed features.) As far as removing features, though, probably good enough.

The WHATWG HTML5 spec has notes on conforming SVG features, but those were me researching what current browsers supported/didn't support. I'd be the first to say they should be challenged by any further knowledge.

[pshaughn]

A lot of WPT tests want to see the SVG script element working.