stroke path calculation seems broken in certain case

[zimond]

<path d="M63,252.1L66.1,249.4L63,246.7" stroke-width="2" stroke="#000000" fill="none"/>

Seems the svg demo renders wrong stroke path. Maybe pathfinder_path_utils::stroke is giving wrong endpoints in this case?

[dylanede]

I've also bumped into this. Given this SVG (uploaded as a zip since GitHub refuses to attach SVGs):

test_svg.zip

the following output is observed (ignore the clipped bottom of the frame):

The correct output should look like this (ignoring discrepancies in line joins, which pathfinder doesn't implement yet):

This SVG includes both closed and open paths. Observed issues:

• Closed paths are not actually getting the last edge added to close them
• Sometimes the right-most pair of edges in a path get badly triangulated. This doesn't seem to be affected by whether the path is created in a clockwise or anti-clockwise fashion.
• The top-left path isn't being rendered.
• All paths are exactly twice as thick as expected.

I have seen similar issues when using Pathfinder in an OpenGL ES renderer I'm working on, with much more complex graphics. The above SVG renders with identical problems in my renderer as well.

@pcwalton What are your thoughts?

[pcwalton]

Interesting, thanks for the report! I'll take a look.

[pcwalton]

I believe this is all fixed. Thanks for the bug report!

[dylanede]

I've checked out the latest commit, and although most of the problems are fixed, the top left spiral shape is still not showing up. Also, the closed black pentagon does not appear to be joining the starting edge with the last edge. This is what I see:

[dylanede]

On further inspection, it appears that the spiral shape only shows up when using XCAA. Under other modes it doesn't appear.

[dylanede]

It appears that some new problems have appeared as a result of these fixes.

Before the fixes, this svg (a stroked and filled path generated from some text in Inkscape) looked like this (using XCAA):

Now it looks like this:

and with no anti-aliasing, it looks like this:

For reference, all browsers I tried it on rendered it natively like this:

[pcwalton]

@dylanede Did you rebuild the demo with npm run build? It was a client-side fix, not a server-side one. The top left path shows up locally for me under all AA modes.

[dylanede]

Ah, it's possible that I didn't. That could explain it. When I'm back at that machine I'll check.

However with the other problem (the strokes in the "Testing" image) I have seen similar behaviour in my own renderer after updating the dependency on pathfinder, so it's not affected by changes in the client.

[zimond]

Seems when using the new stroke logic, every EndPoint.subpath_index is 0 no matter how many subpaths are there in the PathBuffer. Is this a bug?

[zimond]

Oops, it seems that I need to consume the stream once again in a new PathBuffer to make the numbers correct. Ignore my last report please