elements.comp scene traversal may leave gaps in paths about vello HOT 5 CLOSED

This is a very interesting problem, thanks for bringing it to my attention. I will study your solution, but also consider some alternatives. Just to brainstorm, one is to represent the affine transformation using fixed point arithmetic, which should make the math deterministic, but with limitations.

from vello.

@raphlinus I'd like to take a stab at implementing your idea of combining transformations in their own monoid in elements.comp. Are you currently (or anyone else) working on this?

Related, is the comment about shared arrays of structs in elements.comp still relevant? If we're going to have two monoid passes, it would be a big readability to work on structs.

FWIW, the malloc functionality (example) uses shared arrays of structs, and I haven't heard you complain.

from vello.

I'm open to you having a crack at it. If you would like to write a brief design doc before digging into the code, I'll try to prioritize it (I've had difficulty switching gears to focus on piet-gpu, but plan for it to be my main work over the next weeks).

I think we can do shared structs now, the bug in the NV shader compiler has been fixed a while ago and we're not at the point where we have to accumulate workarounds for driver bugs - yet.

from vello.

Please review #71 which contains an implementation of your separate transformation monoid. It works for me in Gio, and the piet-gpu tiger.

EDIT: I lied. It doesn't always work correctly. Stay tuned.

from vello.

Ok, I believe I found a correct (and simpler) fix, a hybrid between your resolved transforms and my tracking of path endpoints. I abandoned the second pass, because I ended up needing both the resolved transformations (for path segments) and the relative transformations (for the bounding box monoid). The new approach keeps a single pass, and doesn't need an end path flag.

Tested with Gio and the piet-gpu tiger.

Please review at #72.

from vello.