# Clipper2: polygon booleans and offsetting in C++, C# and Delphi

> The successor to the fifteen year old Clipper library, doing intersection, union, difference and XOR on complex polygons, plus offsetting and constrained Delaunay triangulation, in three languages.

**AngusJohnson/Clipper2** — Polygon Clipping, Offsetting & Triangulation in  C++, C# and Delphi

- Repository: https://github.com/AngusJohnson/Clipper2
- Stars: 2,502 · Forks: 460
- Language: C++
- License: BSL-1.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/angusjohnson-clipper2

## What the library actually computes

Clipper2 performs intersection, union, difference and XOR boolean operations on both simple and complex polygons. That distinction is the whole point of the library. A simple polygon library falls over on self-intersections, coincident edges and holes, and those are exactly the shapes that arrive when the input is a real drawing or a scanned outline rather than something authored deliberately.

Alongside the booleans it does polygon offsetting, described in the examples section as inflating, and constrained Delaunay triangulation. Offsetting is the operation that produces a parallel curve, which is what you want for stroke outlines, CNC toolpaths, laser kerf compensation and similar work. The repository's topic tags match that scope: boolean-operations, polygon-union, polygon-intersection, clipping-algorithm, offsetting and inflate.

The README calls this a major update of the original Clipper library written about fifteen years earlier, which the author now calls Clipper1. His assessment of the old one is that it still works very well but Clipper2 is just better, with a link to a changes document.

Licensing is Boost Software License 1.0, and the default branch is `main` with the last push on 2026-04-20. The tree is small and telling: `CPP/`, `CSharp/`, `Delphi/`, `DLL/` and `Tests/`, plus a `.gitmodules` entry, so there is no packaging tooling or CI scaffolding beyond the per-language workflows.

## Three languages, and a DLL for everyone else

Clipper2 is written in C++, C# and Delphi Pascal, and the README makes a case for the C++ build that surprises people who arrived from C#.

| Lang. | Requirements |
| --- | --- |
| [C++:](https://github.com/AngusJohnson/Clipper2/tree/main/CPP) | Requires C++17, |
| [C#:](https://github.com/AngusJohnson/Clipper2/tree/main/CSharp) | Standard Library 2.0 but the sample code uses .NET6, |
| [Delphi:](https://github.com/AngusJohnson/Clipper2/tree/main/Delphi) | Compiles with any version of Delphi from version 7 to current. |

That table is close to verbatim from the README, and the requirements are worth noting individually. C++ needs C++17. The C# library uses Standard Library 2.0 even though the samples target .NET6, so the library itself is broadly consumable. Delphi support reaching back to version 7 is a compatibility promise most modern libraries would not make.

The DLL route is the fourth option and the one the README pushes hardest. Other languages can dynamically link to exported functions in the compiled C++ library, and the claim is that the C++ compiled code is measurably faster, so where performance is critical even C# and Delphi developers may prefer this approach in application development. That is an unusual recommendation from a library author who ships three managed implementations, and it is worth taking seriously rather than assuming it is marketing.

The 32-bit and 64-bit DLL releases expose almost all of the library's features through the functions declared in `clipper.export.h`, which also documents the simple language agnostic data structures those functions expect. The `DLL/` directory holds the Visual Studio project files and source for a Delphi utility demonstrating the DLLs, which is the most practical reference for the calling convention.

## Triangulation is the newest module and the README flags it

Constrained Delaunay triangulation is the newest thing in the library. The 2.0.1 release notes say that release includes the new constrained Delaunay triangulation module, and the DLL release notes add that the latest DLL build adds `Triangulate()` to the exported function list.

What makes this worth flagging is the caution the author left in the README, presented as a diff block rather than prose.

```diff
- CAUTION: The triangulation code is buggy and I regret releasing it when I did.
- I'm working on fixes but these may still be weeks away. Sorry.
```

That block is in the current README, which tells you something specific: the author considers the triangulation code unreliable as shipped and had planned fixes that were still outstanding. It is an unusual thing to leave in a README, and the honest reading is that the booleans and offsetting have a long track record while the triangulation module is newer and less settled.

The examples section nonetheless gives triangulation its own group of links across all three languages, plus a separate C++ example for coordinates that include a Z value, which suggests the API handles 3D input for cases where coplanarity needs care.

If triangulation is the main reason you are considering this library, read the changes document and the example code before committing, and keep the boolean and offset paths as the parts you can rely on today.

## Examples are permalinked, which tells you they move

The examples section is organised by operation rather than by language, and each entry links to a specific commit and line range in the repository rather than to a file on the default branch. Clipping, inflating and constrained Delaunay triangulation each get a C++, a C# and a Delphi link, and the C++ using-Z example is separate.

Pinning examples to a commit SHA is a deliberate choice with a practical consequence: the links stay valid, but they do not show the current code. Anyone copying from the linked line ranges is copying from a snapshot the author chose, and the C++ triangulation example in particular is linked to an older commit than the others.

What the examples demonstrate is small and focused, which is the right shape for a geometry library. You construct paths, set up the operation, and get paths back. There is no framework, no scene graph and no application layer to learn around the algorithm.

For anyone assessing the library quickly, reading the three-language C# examples first is the efficient path, since that is usually the implementation they would ship. The documentation pointer is an external HTML site at angusj.com with an Overview page, and the badge in the README links to it, so the API reference lives off-repository while the examples live inside it.

## Nine community ports and what they imply

A table at the end of the README lists ports to other languages, each pointing at a separate repository: Go, Haxe, Java, Kotlin, Lua, Rust, Swift, TypeScript and WebAssembly. Only Haxe is in this repository, under `Delphi` adjacent paths and referenced in the table, so eight of the nine are third-party.

That list matters for two reasons. First, it tells you the algorithm ports cleanly, which is a good sign about how the reference implementation is factored. Second, it sets an expectation: none of those ports carry the same level of scrutiny as the three languages the author maintains.

The releases reinforce which parts are first-class. Version 2.0.1 of the library and 2.0.1 of the DLLs were both published on 2025-12-19, with the library release covering source in the three languages plus samples, and the DLL release covering the exported function surface. The previous DLL release, 1.5.4 from 2025-06-06, carries a note that it fixes a clipping bug that potentially results in an endless loop.

That bug is the most informative line in the release history. An endless loop in a clipping library is the worst kind of failure for a production system, and its existence in a version that shipped tells you two things: the algorithm has sharp edges that only large or adversarial inputs expose, and the author documents them rather than burying them.

## Where this fits against the alternatives

The obvious comparison for a .NET developer is with the geometry libraries that ship inside drawing or CAD stacks, and Clipper2's pitch is narrower and more specific: it does robust boolean operations and offsetting well, in a small library you can read.

For a general-purpose 2D geometry toolkit, you get less than you would elsewhere. No curves, no 3D solids, no spatial indexing, no scene representation. The triangulation module exists but carries the author's own caution. If your requirement is a full geometry kernel, this is not it, and picking it means writing the rest.

For the specific job of turning messy outlines into cut shapes, toolpaths or stroke geometry, the case is stronger. The boolean operations work on complex polygons rather than requiring you to sanitize input first, which is the failure mode that causes the most bugs in code that processes drawings. And offsetting is treated as a first-class operation with its own example rather than as an afterthought.

The multi-language story is unusual for a library this specialised. Having native Delphi support back to version 7 alongside C++17 and C# means the same algorithm can be used in a modern service and in a decades-old desktop tool without a bridge in between.

One practical caution on ports: if you are working in Rust, Go or TypeScript, you are depending on somebody else's reimplementation. Check whether it covers the operations you need, especially offsetting and holes, before assuming parity with the C++ reference.

## Conclusion

Clipper2 is the geometry library to reach for when a project needs robust polygon booleans on real-world input, and the reason is the combination of three things: a mature algorithm lineage going back to Clipper1, an implementation in C++, C# and Delphi so you are not forced through a binding, and a DLL route for other languages when raw speed matters. For most C# and Delphi developers the recommendation in the README is the opposite of what people expect, namely that calling the compiled C++ through exported functions is measurably faster and worth the extra layer where performance is critical. Triangulation arrived late and carries a caution from the author in the README, so treat that module as newer than the rest and verify it against your own cases.

## FAQ

### What operations does Clipper2 support?

Intersection, union, difference and XOR boolean operations on both simple and complex polygons, plus polygon offsetting, which the examples call inflating, and constrained Delaunay triangulation. Handling complex polygons, with self-intersections and holes, is what separates it from simpler polygon libraries.

### Which languages can I use Clipper2 in?

C++, C# and Delphi Pascal are the author's own implementations. The C++ build needs C++17, the C# library uses Standard Library 2.0 though samples target .NET6, and Delphi compiles from version 7 through current. Other languages can dynamically link to exported functions in the compiled C++ DLL, and community ports exist for Go, Java, Kotlin, Lua, Rust, Swift, TypeScript, Haxe and WebAssembly.

### How do I use the Clipper2 DLL from another language?

Dynamically link to the exported functions in the compiled C++ library, which the README says is measurably faster, so even C# and Delphi developers may prefer it where performance is critical. The 32-bit and 64-bit DLL releases expose almost all features, and the declarations in `clipper.export.h` document both the functions and the simple language agnostic data structures they need. The `DLL/` directory also contains a Delphi utility showing the usage pattern.

### Is the triangulation in Clipper2 reliable?

The README carries the author's own caution that the triangulation code is buggy and that he regrets releasing it, with fixes still to come. It arrived in release 2.0.1 on 2025-12-19, along with `Triangulate()` in the DLL exports, so it is the newest and least settled part of the library. The boolean and offsetting operations are the long-established ones.

### Should I use Clipper2 or the original Clipper library?

Clipper2, according to its author, who describes it as a major update of Clipper1 written about fifteen years earlier and says Clipper1 still works very well but Clipper2 is better. Note that triangulation is only in Clipper2 and carries a caution in the README, so if your need is purely the classic clipping and offsetting, Clipper1 remains a defensible choice.

### What licence is Clipper2 released under?

Boost Software License 1.0, with a licence badge in the README linking to the Boost licence text and a `LICENSE` file at the repository root. Versions 2.0.1 of both the library and the DLLs were published on 2025-12-19, and the last push to the main branch was on 2026-04-20.

## Sources

- [AngusJohnson/Clipper2 on GitHub](https://github.com/AngusJohnson/Clipper2)
- [Issues](https://github.com/AngusJohnson/Clipper2/issues)
- [License: BSL-1.0](https://github.com/AngusJohnson/Clipper2/blob/main/LICENSE)
- [README](https://github.com/AngusJohnson/Clipper2/blob/main/README.md)
- [Releases](https://github.com/AngusJohnson/Clipper2/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/angusjohnson-clipper2