We should see if we can get rid of nsSVGArcConverter and use ArcToBezier from PathHelpers.h instead.
I've not actually looked at ArcToBezier - this may depend on us killing off gfxContext and converting to Moz2D. Maybe not.
There may be a few issues with doing this: a) In SVGPathSegUtils.cpp, TraverseArcAbs and TraverseArcRel both use nsSVGArcConverter without ever drawing on anything, and they both also compute the length of the arc as the arc is drawn, neither of which is supported by arcToBezier. But neither of the TraverseArc* functions are called from anywhere (and they're declared static), so possibly they could go? I don't know. b) ArcToBezier doesn't directly support the |angle| parameter of nsSVGArcConverter (which determines the rotation of the ellipse on which the arc is drawn), so a transform(s) would need to be applied to the drawable in the calling code. (arcToBezier also takes different parameters than those supplied by the svg arc curve command, so I guess we'd want to wrap ArcToBezier in any case). c) ArcToBezier starts by |lineTo|ing the starting point of the arc, which I guess in the standard case should just be a noop(?), but might be undesirable in other cases?
regarding a) they are put in a table of function pointers and called indirectly: http://mxr.mozilla.org/mozilla-central/source/dom/svg/SVGPathSegUtils.cpp#431
Created attachment 8589296 [details] [diff] [review] bug929375_nsSVGArcConverter.diff As discussed with Jonathan over email: Regarding point a), the "length of arc" functionality required by TraverseArcAbs and TraverseArcRel could be provided by a moz2D Path, but PathBuilders and Paths can be expensive on Windows, so for now we'll continue to use nsSVGArcConverter. I added a comment to the nsSVGArcConverter class saying as much.