Garbled output with reschart

[ishitatsuyuki]

For some reason, piet-gpu seems to give garbled rendering for the reschart test. The test svg is attached below, and it consists of only typical path and strokes, which piet-gpu should have no problem handling. (It does use a transform to flip the image upside down, but piet-gpu simply ignore so it's unrelated to the issue.)

(File taken from MPVG test suite, renamed to txt for uploading to GitHub)

reschart.svg.txt

piet-gpu rendering (cargo run --release --bin cli -- reschart.svg --scale 2):

Looks like backdrop calculation is all over the place, but I'm not sure what is causing that.

[raphlinus]

Thanks for bringing this up. It's evidence that the numerical stability issues in the coarse rasterizer are not fully resolved. The reschart image is definitely a stress test for it.

Honestly, I haven't prioritized the issue, in part because I'm fairly confident it can be solved. There are challenges, though, not least of which is that shaders are generally compiled with the equivalent of -ffast-math, so it's difficult to get absolute bit level equality guarantees even when subexpressions are identical. A systematic approach will involve some combination of analytical reasoning and thorough testing.

[ishitatsuyuki]

I tried out @eliasnaur's branch at #72, and I got the exactly same broken output as before. So it's deterministically broken and unrelated to the transform monoid.

[eliasnaur]

I think this is caused by reschart.svg relying on the SVG auto-close property and the piet-gpu parser doesn't support it. I can reproduce the corruption with just a single path from the original:

<svg>
<defs>
</defs>
<path id="path103" fill-rule="nonzero" stroke="none" fill="rgb(0,0,0)" d="M 428.031,84.3669 L 450.707,84.3669 450.707,78.699 428.031,78.699 "/>
</svg>

There are only 3 line commands, the fourth being implicit. The corruption is gone if I explicitly close the path:

<path id="path103" fill-rule="nonzero" stroke="none" fill="rgb(0,0,0)" d="M 428.031,84.3669 L 450.707,84.3669 450.707,78.699 428.031,78.699 428.031,84.3669"/>

[raphlinus]

I think you're right, and it is good news indeed if that is the explanation; it should be fixable in the path encoding (CPU side) when generating paths for fill that lack a closepath element.