Using Cesium.js without wasm on main thread

[ben-polinsky]

Feature Request / Inquiry

Hi,

We're looking into using Cesium in a desktop app, and are debating expanding our CSP to support wasm. As part of the discussion, we'd like to know if it is possible to run Cesium without wasm support - or to at least move all wasm usage to within workers to allow for a less-permissive CSP where wasm-unsafe-eval is scoped to worker contexts.

With the help of Claude I've gathered all instances of wasm usage in the library below. As mentioned, one compromise might be to move all wasm usage into workers. Then we could dynamically add headers to worker responses with the CSP only for that response (CSPs are set from the response for the resource that creates the context for which a particular CSP is valid)

Main Thread

Dependency	Imported at	Compile timing	Runtime trigger
meshoptimizer	Scene/GltfBufferViewLoader.js#L5 (sync decodeGltfBuffer at L176); Core/Cesium3DTilesTerrainGeometryProcessor.js#L1	Eager — module-scope IIFE calls WebAssembly.instantiate at import (meshopt_decoder.mjs, ~L30)	EXT_meshopt_compression content; 3D Tiles terrain
@spz-loader/core	Scene/GltfSpzLoader.js#L7	Lazy — instantiates on first loadSpz(), but still main-thread	SPZ Gaussian splat content
long (via protobufjs, from Core/GoogleEarthEnterpriseMetadata.js / Scene/GoogleEarthEnterpriseImageryProvider.js)	long/index.js, ~L24	Eager — module-scope new WebAssembly.Instance feature probe (try/caught, but still generates a CSP violation report)	none (feature probe)

Worker-side

Pattern: main thread fetches .wasm bytes (TaskProcessor.initWebAssemblyModule), posts to worker, worker compiles under its own header-delivered policy.¹

Feature	Config site	Worker	Binary
Draco decode	Scene/DracoLoader.js	Workers/decodeDraco.js	ThirdParty/draco_decoder.wasm
KTX2/Basis transcode	Core/KTX2Transcoder.js	Workers/transcodeKTX2.js	ThirdParty/basis_transcoder.wasm
I3S decode	Scene/I3SDecoder.js	Workers/decodeI3S.js	ThirdParty/draco_decoder.wasm
Gaussian splat sort	Scene/GaussianSplatSorter.js	Workers/gaussianSplatSorter.js	ThirdParty/wasm_splats_bg.wasm
Gaussian splat textures	Scene/GaussianSplatTextureGenerator.js	Workers/gaussianSplatTextureGenerator.js	ThirdParty/wasm_splats_bg.wasm
KMZ/zip inflate	DataSources/KmlDataSource.js (configure() inside loadKmz() — lazy and worker-routed)	ThirdParty/Workers/zip-web-worker.js	ThirdParty/zip-module.wasm

Thanks in advance :)

P.S. only partially used AI for the source-gathering.

AI acknowledgment

• I used AI to generate this feature request.
• (If the above is checked) I have reviewed the AI-generated content before submitting.

At least tangentially related: #13412

[ben-polinsky]

Hi @ggetz - any idea when you'll get a chance to assess this?

[ben-polinsky]

Some more findings over the weekend:

Two of the issues are upstream with what appear to be simple fixes, though not sure if the two libraries are open to providing these alternative builds:

• @spz-loader/core could ship a rebuild with -s DYNAMIC_EXECUTION=0 for emscripten. Docs: https://emscripten.org/docs/tools_reference/settings_reference.html#dynamic-execution. This prevents emscripten from outputting eval or new Function which require consumers to make exceptions in their unsafe-eval CSP.
• Basis/KTX2 also needs the above flag set during build.

I have a working branch with a quick-n-dirty proof: main...ben-polinsky:cesium:issue-13617 - locally, I built spz with -s DYNAMIC_EXECUTION=0 and everything is good. I did not yet test KTX2.

I'm happy to refine this and get a PR in if it would help speed things along, and can raise issues on the two upstream repos.