[jsve]

Closes #225

Background

_earcutPolygonData() and _earcutMultiPolygonData() cloned the geometry with preparePostMessage(..., true) (and interleaved separated coordinates) before calling pool.queue(), then waited on pool.completed().

When many record batches create polygon layers faster than earcut can keep up, for example with progressive rendering:

• every layer waiting for a worker held its own copy of its geometry, no matter how small the pool
• each layer waited for the whole shared pool to drain instead of its own task, and because completed() rejects on any task failure, one layer's error could fail another layer's triangulation

Change

Interleaving and preparePostMessage now run inside the queued task, and each layer awaits the task returned by pool.queue(). Copies are limited by the number of active pool tasks, which is the pool size at the default concurrency of one. Each layer resolves or fails with its own triangulation only. metrics timing is unchanged.

Tests

Added tests/solid-polygon-layer-earcut.test.ts. It uses a real threads Pool with an in-process worker that clones, rehydrates, and triangulates the payload the same way the earcut worker does. For Polygon and MultiPolygon data, with both interleaved and separated coordinates:

• while the only worker is busy and the layer's task is queued, neither getInterleavedPolygon nor preparePostMessage has run
• after the worker is released, preparePostMessage runs once, getInterleavedPolygon runs only for separated coordinates, and the result matches main-thread earcut
• a layer resolves with its own result while another pool task is still running

All eight tests from 8558c54 fail on main (the last one by timing out) and pass after applying de1478a. pnpm typecheck, pnpm test, and biome ci . pass.

[jsve]

This overlaps with #232, which cancels queued triangulation tasks when a layer is "finalized". As mentioned in that PR body, they both complement eachother. There is a plan for how to handle if #230 merges first, and this would probably be my recommended order.

If PR #232 is already merged, rebase #230 on top of main and keep geometry preparation inside the callback, but pass that callback through _queueEarcutTask() instead of calling pool.queue() directly. Keep the cancellation handling and try/finally metrics cleanup from #232.

Don't trust git conflict markers, check the surrounding code as well. Git can retain a direct pool.queue() call outside the conflict markers.

If maintainers think both issues these PRs address should be fixed, and this merge-order makes reviewing difficult, I'm happy to combine the PRs into one. When i started out, i thought there would be a cleaner separation between them, but implementations were slightly more entangled than i thought.