If you have ever peeled an orange in one continuous strip, you already understand ear clipping. Each time you pull away a section of peel, the remaining boundary gets simpler. A "ear" on a polygon is a convex corner where you can slice off one triangle without hitting anything else inside the shape — peel it away, and you have a polygon with one fewer vertex. Keep peeling until nothing remains. The insight is not the algorithm itself, which dates to 1975, but the systematic elimination of every wasted cycle in applying it to millions of real-world map polygons. The committed claim: earstrip, a single C++ header (ISC-licensed), triangulates polygon data 14% faster than earcut.hpp in C++ and 1.4–2.1× faster than earcut.js in the browser, benchmarked on 3,740,425 polygons from zoom level 13 of the Masovian Voivodeship map tile. The constrained Delaunay triangulator it replaced took 2.93 seconds on one M4 Pro core; earstrip does it in 489 ms — a 6× speedup. The architecture is classical computational geometry, not ML or GPU compute. The method belongs to the ear-clipping family, which trades the well-shaped triangles of Delaunay for raw speed on flat-fill rendering where triangle quality is irrelevant. The key structural bet: GPUs fill needle-thin triangles just as correctly as equilateral ones, so Delaunay's angle-maximizing property is wasted work for map rendering. The post walks through seven incremental optimizations — testing only reflex (dent) vertices instead of all vertices, short-circuiting convex polygons, zig-zag triangle strips, spatial bucketing, branch elimination, and marked-hit tracking — each with a before/after timing on the same 3.7M polygon dataset. The ladder is clear and honest. Earcut is the reigning open-source baseline for map triangulation, used across the Mapbox ecosystem. Earstrip beats it by 14% in native C++ and up to 2.1× in WebAssembly. The authors also acknowledge where Delaunay still wins: on the 1,123 largest polygons (257+ vertices), Delaunay's 90 ms beats ear clipping's 199 ms because the O(n²) ear test dominates at scale. This is unusually forthright — most library announcements bury the cases where the old approach is better. The integrity regime is engineering benchmarking rather than academic validation, but it is rigorous on its own terms. Every optimization is a single git commit, timed on the same real-world dataset (Masovian Voivodeship, zoom 13), on the same hardware (one M4 Pro core). The dataset is not synthetic — it is actual OpenStreetMap geometry with all the degenerate cases real map data produces: zero-area holes, self-touching boundaries, collinear edges on integer grids. The code is open-source under ISC license, and the npm WebAssembly build accepts the same arguments as earcut, making independent replication straightforward. The milestone trajectory here is not about hitting a single number but about the diminishing-returns curve of optimization. The seven commits took the naive ear clipper from 1,119 ms to 489 ms — a 2.3× internal speedup — with each step yielding progressively smaller gains: 237 ms, then 2 ms, then 118 ms, then 65 ms, then 178 ms, then 30 ms. The next meaningful threshold would be beating Delaunay on large polygons too, which likely requires moving beyond O(n²) ear testing to a spatial data structure that makes the per-ear check sublinear. The obvious experiment not run: GPU-side triangulation. The entire premise is that these triangles feed a GPU, yet the triangulation itself runs on a single CPU core. Compute shaders for parallel ear clipping exist in the literature. The honest read is (a) — this is a map engine team shipping a production library, and GPU triangulation would be a fundamentally different architecture. They optimized what they control. The other gap is the large-polygon crossover: the post acknowledges Delaunay wins above 257 vertices but does not explore a hybrid strategy that switches algorithms by polygon size.
