Upgrade to Clipper2

[gpeairs]

We can get a 2x to 4x speedup on clipping and offsetting operations by switching to Clipper2. I've done some experiments locally, and for the existing benchmarks I get:

Benchmark	Clipper2	main	Speedup
difference2d 100_square	165 μs	672 μs	4.1x
difference2d 961_square	2.40 ms	7.53 ms	3.1x
difference2d 3600_square	9.65 ms	30.7 ms	3.2x
difference2d 8000_skew	23.5 ms	71.7 ms	3.1x
difference2d 10000_square	30.6 ms	92.3 ms	3.0x
difference2d 19881_square	66.3 ms	193 ms	2.9x
difference2d_offset	88.2 μs	230 μs	2.6x

Offsetting small polygons is ~4x, large polygons is ~2x.

This was done with a minimal ad-hoc approach to enable the tests, making a drop-in replacement despite breaking changes to the Clipper2 interface itself:

• wrapping Clipper2 with a custom C wrapper matching the existing custom C wrapper for Clipper1 used by Clipper.jl
• modifying Clipper.jl to use that wrapper

The test suite mostly still passes, with some exceptions where behavior seems to have changed:

• point order changes (fine, some tests fail but can be changed)
• intermediate points on straight edges are not removed (likewise)
• under some circumstances shapes with exactly shared edges are not combined (union2d(Rectangle(1, 1), Rectangle(1, 1) + Point(1, 0)) returns the same 2 contours, although a float or Unitful version gives 1 as expected) -- needs investigation (does this affect our DotMatrix fonts, which need to be combined for rounding?) but likely fine

So I suspect there are no fundamentally breaking changes, but will want to do more testing.

There was an earlier effort to upgrade Clipper.jl to Clipper2 (JuliaGeometry/Clipper.jl#50) but it seems to have stalled. If we want to pursue this, I would wrap Clipper2 faithfully and put any compatibility shim in DeviceLayout.jl instead of the wrapper/Clipper.jl.

[gpeairs]

This got bumped up in priority because Z tagging in Clipper2 would be useful for #232 with clipped curves (and only adds 2-3% overhead for us). I have the new approach working locally:

• A faithful Clipper2 wrapper: Clipper64 engine (subject/clip/open-subject, Execute incl. PolyTree), ClipperOffset, and the free functions, exposing Clipper2's actual API shape (single FillRule, native Cint-backed enum values) over a custom C shim (cclipper2.cpp, same approach as Clipper1's cclipper.cpp). Standalone tests pass.

• A compat shim inside DeviceLayout (src/clipper_compat.jl): the Clipper1-shaped Clipper module surface DL consumes (IntPoint, PolyNode{T}, Clip/ClipperOffset, execute_pt, Clipper1 enum names) backed by libcclipper2. DL precompiles with no external Clipper dependency, and clipping results are exact on the basics (union/intersection/difference areas). arc_tolerance will be pinned to 0.25 in the shim (Clipper2's default changed to 0/auto), preserving current offset arc quality.

• test_clipping.jl in DeviceLayout: 354 pass / 31 fail, every failure is one of the two documented Clipper1→Clipper2 behavioral deviations below

  1. Collinear vertices + point order (almost all of the 31 failures). Clipper2's engine defaults to PreserveCollinear = true, where the Clipper1 wrapper stripped collinear vertices. We can expose preserve_collinear in the C wrapper's constructor and have DL set it false, keeping that behavior in the engine with no post-processing pass. Neither setting reproduces Clipper1's output byte-for-byte (the start vertex can rotate) so the exact-vertex tests use circular comparisons.

  2. Edge-touching union (union2d(Rectangle(1, 1), Rectangle(1, 1) + Point(1, 0)) -> 2 contours). This is only when the edge is 1 integer unit long — Clipper2's short-edge merge limit (Is this expected behaviour for a difference operation? AngusJohnson/Clipper2#690), not a general integer-union failure. Side-by-side squares with edge length 1 stay separate; length ≥ 2 merges. In practice our float/Unitful edges are much longer in scaled coordinates. There is a regression test for this behavior but no fix needed.

The C wrapper would be built as a dedicated JLL (cclipper2_jll) via Yggdrasil — a dependent build linking the existing Clipper2_jll (pinned = 1.2.2, to avoid changing too many things at once), mirroring how Clipper_jll ships libcclipper. We target a single -DUSINGZ build. The narrow {x, y} entry points are ABI-stable under USINGZ (z = 0 internally; nothing widens at the FFI boundary), and the performance penalty looks like ~2–3 % on our clipping hot path, negligible compared to performance gains over Clipper1.

The Julia wrapper would become the Clipper2 upgrade of JuliaGeometry/Clipper.jl itself (as its next breaking version — JuliaGeometry/Clipper.jl#50 already planned to tag v0.7 in the existing package rather than start a new one). DeviceLayout will depend only on cclipper2_jll through its internal shim, so we aren't blocked on the upstream timeline.

The sequence from here would look like Yggdrasil PR for cclipper2_jll → migrate the DL shim off the vendored .so → set preserve_collinear = false and re-baseline the exact-vertex tests → re-run the benchmarks above as a regression check → PR to Clipper.jl.