The wasm module's geometry tile pool surface (conway-geom
tile_pool_api.h via the embind bindings in conway-api.cpp) — Phase B of
the demand-geometry track. Typed narrowly here rather than through the
vendored module d.ts; asset ids and sizes cross the boundary as JS numbers
(< 2^53 by construction).
Division of labour (see "Resident memory: two regimes" in the design doc):
the TS side (ChunkedPool + SharedAssetPool + GeometryTilePool) is the
accounting/policy layer — it holds no payload bytes — while the wasm
TilePool owns the physical chunks. In this composition the TS layer calls
materialize/discard exactly once per residency, so the wasm-side
refcount stays at 1 for TS-managed tiles; the wasm refcounting exists for
future direct-C++ holders, not for this path.
The wasm module's geometry tile pool surface (conway-geom
tile_pool_api.hvia the embind bindings in conway-api.cpp) — Phase B of the demand-geometry track. Typed narrowly here rather than through the vendored module d.ts; asset ids and sizes cross the boundary as JS numbers (< 2^53 by construction).Division of labour (see "Resident memory: two regimes" in the design doc): the TS side (
ChunkedPool+SharedAssetPool+GeometryTilePool) is the accounting/policy layer — it holds no payload bytes — while the wasmTilePoolowns the physical chunks. In this composition the TS layer callsmaterialize/discardexactly once per residency, so the wasm-side refcount stays at 1 for TS-managed tiles; the wasm refcounting exists for future direct-C++ holders, not for this path.