Warren Moore

Ah. That’s O(n^2) and won’t handle self-intersecting paths, which are extremely common in the real world :(

Not trying to troll you, BTW; it’s impressive work. Just trying to save you a year’s worth of dead-ends that I had to go through. There’s only one practical solution for tessellation of resolution independent paths that I know of, and it’s what Pathfinder uses.

You will need to rework the whole thing for SVG spec compliance when you get to implementing fill rules. The spec mandates that you handle winding vs. even-odd properly. Probably best to do it sooner rather than later, IMO.

Yeah. I already found some svgs that earcut can't handle. SVG is like COLLADA, we won't support it fully, but we'll have decent support with performant and maintainable code. Enjoying the luxury of not being a browser

Really appreciate sharing your findings by the way. I have the same urge when I see someone starting a open source library

Sorry noob qn for @pcwalton - what's the complexity for pathfinder and does it avoid polygon triangulation?

It’s O(k * n * log n) where n is the number of vertices and k is the maximum number of simultaneous active edges (usually a low number). Same complexity as a CPU renderer. It creates trapezoidal meshes that preserve curves (so the mesh is resolution independent).

In the case of a monotone path, Pathfinder’s tessellation is O(n log n), whereas ear clipping is O(n^2).