Richard GeldreichandClaude Opus 5.5
918d658f95
Newer Emscripten (6.0.x) no longer includes mainScriptUrlOrBlob in its default INCOMING_MODULE_JS_API, so the threaded encoder loaded via importScripts() in ktx2_studio/encode-worker.js ignored it and the pthread pool never came up (the worker hangs while loading). Add it explicitly (Emscripten's default list plus mainScriptUrlOrBlob), as in the development tree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Prebuilt versions of basis_encoder.js and basis_encoder.wasm are included in the build/ folder, and are sufficient for local demos. Note the encoder also includes the transcoder. To build the encoder yourself, first install emscripten (tutorial) and cmake (download). Then run:
cd webgl/encoder/build/
emcmake cmake ../
make
Strict Content-Security-Policy (no unsafe-eval)
By default, the generated JavaScript glue uses new Function() to build its
embind bindings at runtime. A Content-Security-Policy without 'unsafe-eval'
blocks this, and module startup fails with an EvalError. To build glue that
never calls eval() or new Function(), add -DNO_DYNAMIC_EXECUTION=ON:
emcmake cmake ../ -DNO_DYNAMIC_EXECUTION=ON
make
This adds -s DYNAMIC_EXECUTION=0 -s EMBIND_AOT=1 to the link flags. The
.wasm file does not change. EMBIND_AOT generates the bindings at build
time, so JavaScript-to-WASM calls stay as fast as in the default build. The
page still needs 'wasm-unsafe-eval' in script-src to compile the
WebAssembly module. Use -DEMBIND_AOT=OFF to get the smaller, generic
bindings, which are slower per call.