The issue here is possibly related to the need to keep zero length paths for SVG because correct drawing of markers and linecaps requires it.

And what does the spec have to say about this?

The spec I think would be https://html.spec.whatwg.org/multipage/scripting.html#trace-a-path (step 2)

https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-arcto could also be relevant.

Skia has a mode to remove the empty subpaths. I wrote it. I'll try to sort this out.

Treatment of degenerate path segments for Chrome once again bites us.

Apparently SVG and Canvas differ on the way you should treat degenerate content. Canvas says remove degenerate segments when stroking, while SVG insists you keep them.

I think this means we need a way to tell the stroking code which option to do, and hence what to tell the path iterator as it spits out segments. Would the Skia team be willing to get the Skia side in place?

I have verified that we fix this test if we change, for instance, SkEdgeBuilder to remove degenerates as it processes a path. But that will break a whole host of other content, I presume.

Another option might be to check what compat looks like for this case, and adjust the spec if there's indication of it deviating from implementations.

The history of this is that, way back when, I changed Skia to keep the degenerate segments because we were failing all the tests for painting zero-line-length markers and line caps. I agree that it would be nice if the specs all agreed on what to do.

Firefox also fails.

Probably need to sample Gecko on other platforms too, because I believe it uses Skia too on at least some of them.

There's already a path iterator and a raw path iterator. Does this require a third iterator? Can SVG's need be built on top of the raw path iterator?

Right, we already have raw path iteration and that was used by SVG for markers and/or endcaps. I'm not sure if it still is.

The issue here, though, is that the Skia internal path stroking code does not remove degenerates, at least as far as I can tell, and the Canvas spec implementation is using that code directly. i.e. via something like SkCanvas::drawPath with a stroke paint. I really don't think Skia should change the default behavior here - the effect would be significant. I'm thinking that maybe we can make the behavior optional and keep it efficient.

I'll make a first pass at looking into what would need to change, and also figure out the extent to which other vendors agree with us.