Rasterizing filled 2D PolyLines in Unity

My app includes a 2D painting interface, and I would like to add a filled polyline support to it.

For this to work, I want the user to be able to draw an arbitrary path, which we then complete with a line back to the origin of the path. The filled region should then be the intersection of all areas of the path the user drew.

To be clear, I therefore need to render:

• 2D polylines (ideally splines, but I can make do with lines with many vertices.)

• Supporting self-intersection

• Without lots of complex winding rules

• At runtime, based on user input

• On iOS

• With not-that-strict performance requirements (33ms for the operation would be acceptable.)

There are many possible solutions to this, but none of them are simple, and many of them require work. Has anyone done this before? Here are the options I have tried that don't work:

• RageSpline: Fails - does not handle self-intersecting paths

• Unify Wiki Tesellator: Fails - does not handle self-intersecting paths

From here, I have many options, each of which would take time to investigate:

• Use Clipper to generate non-intersecting polys, followed by Unify Wiki Tesellator, then GPU rasterization

• libtessdotnet - nobody seems to have used it, but looks promising to emit triangles for rasterization.

• Clipper followed by Unify Community SVG renderer to render to a bitmap (do you need clipper, or does SVG path rendering support intersection?)

• Giving up and thunking through to Apple's Objective-C path rendering, then marshalling that bitmap back to Unity.

I am equally happy to go with a solution that generates triangles that I can render to a rendertexture to get them on the canvas, or a solution that rasterizes directly to texture.

Any source code must be licensed for commercial use, and I am happy to pay for a solution.

Any advice would be greatly appreciated, especially if you've got this working, as this looks like an area where there is a lot of code, but no clear solution that will "just work", and debugging all the edge cases with computational geometry takes a long time and often becomes a dead end.