Start the data-worker pool NOW instead of waiting for the first decode.
Fire-and-forget and idempotent: initialize() dedupes on its cached promise,
and the pool deliberately outlives dataset switches (only app teardown
disposes it), so calling this on every scene load is free after the first.
Why it exists: the pool used to be created lazily by the first chunk decode,
which on a hosted demo meant it started 1.93 s AFTER the scene fetch began —
and the first LOD's bytes had already arrived and were waiting on it. Warming
at scene-load time overlaps worker startup with the metadata fetch that has
to happen anyway.
The config guard preserves the existing "Web Workers disabled" contract;
warming must not fetch WASM or spawn workers no data path will use. The
Worker guard mirrors warmUpDepthSortWorker: the unit suite runs in
node/jsdom with no constructor, where spawning would latch the pool's
deliberately-sticky rejected initPromise for the rest of the file.
Start the data-worker pool NOW instead of waiting for the first decode.
Fire-and-forget and idempotent:
initialize()dedupes on its cached promise, and the pool deliberately outlives dataset switches (only app teardown disposes it), so calling this on every scene load is free after the first.Why it exists: the pool used to be created lazily by the first chunk decode, which on a hosted demo meant it started 1.93 s AFTER the scene fetch began — and the first LOD's bytes had already arrived and were waiting on it. Warming at scene-load time overlaps worker startup with the metadata fetch that has to happen anyway.
The config guard preserves the existing "Web Workers disabled" contract; warming must not fetch WASM or spawn workers no data path will use. The
Workerguard mirrorswarmUpDepthSortWorker: the unit suite runs in node/jsdom with no constructor, where spawning would latch the pool's deliberately-sticky rejectedinitPromisefor the rest of the file.