[seanisom]

Yes! It's kind of a pain to build now, so will probably shift to shipping as a .so/dll with a raw C api in a future version. With that, should be easy to generate bindings for any language - the host API footprint is minimal.

[billconan]

I don't follow this part. if the lib is shipped as .so/dll, how can it be compiled into wasm?

[seanisom]

There is the host API - wander, which contains the Wasm runtime and interfaces with the GPU. The actual graphics code is always compiled to Wasm.

[nerpderp82]

Can one use with WebGPU in the browser? I see you answer that here https://news.ycombinator.com/item?id=39909440

The primary issue with things that include their own Wasm env, that then moving that system to the web doesn't work because you can't run wasm in wasm.

[seanisom]

Yes! Not in the open-source repo yet (because it's currently broken :) ) but you can see it in the video, and will have it working again soon.

That's exactly the goal - one wasm binary with defined input/outputs that can be loaded either in a browser or running in any app outside of a browser.

[nerpderp82]

Then effectively your non-browser container is a browser subset just for your application.

You could run a browser and record all the page faults, then remove all the code you didn't run.

https://fgiesen.wordpress.com/2012/04/08/metaprogramming-for...