Skip to content

Alternate ear search direction after each cut (~6% faster) - #222

Open
mourner wants to merge 1 commit into
mainfrom
zigzag
Open

mourner wants to merge 1 commit into
mainfrom
zigzag

Conversation

@mourner

@mourner mourner commented Oct 23, 2026

Copy link
Copy Markdown
Member

An idea adopted from Earstrip. There's a trade-off to it, so I want to capture it as a PR but not sure it's worth the output churn plus worse quality for the small speedup.

After cutting an ear, earcut always moved on to next, so prev (which just got a new corner) was only retried after a full lap, with lots of reflex corners hit along the way. This PR alternates between prev and next. On the MVT tiles benchmark, ear-loop iterations drop from 5.84M to 4.00M, and time drops 6.4% (14% on water-huge*).

Tradeoff: more fan-like triangles. Across the tiles corpus, mean quality goes from 0.429 to 0.411, slivers increase 10%, and total edge length grows 5%. Output stays exact (zero deviation everywhere). This doesn't matter for fill rendering, and refine() removes the difference completely (0.621 either way).

I also tried always going to prev, and retrying prev once after next fails. Both lose as much shape quality or more for about the same speed.

Test changes: new triangle order in the README and indices-* tests, slightly looser limits on the invalid fixtures (water-huge2, issue142, eberly-6), and the refine test's improvement limit goes from 10% to 5%.

@mourner
mourner requested a review from a team as a code owner October 23, 2026 10:22
@mourner
mourner requested review from Xdudu and removed request for a team October 23, 2026 10:22

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant