Session

Paint by Numbers: High Performance Drawing in Wasm

Sean Isom - Renderlet

Have you ever tried to use WebAssembly to draw something? Complicated, isn’t it?

We all know that WebAssembly was originally created as a way to bring compiled code into the browser.

That compiled code typically needs a UI, but none of this is built into Wasm itself. Various parts of the web stack do polyfill and supplement Wasm by exposing WebGL through Emscripten bindings or wasm-bindgen; sometimes this leads to separate web UIs that communicate with a Wasm app core via linear memory. Although this is a complicated system, it can sometimes work well enough for apps built for a browser.

But what about applications intended to run outside of the browser? In pure WASI there’s no way to access the GPU, and much of the code written for the browser is not reusable here. We could use pure Wasm to render directly into a framebuffer stored in linear memory and copy that into VRAM, but this is not very performant or scalable. We could also bypass WASI and call host functions to wrap underlying hardware or graphics APIs, but this negates the security guarantees of Wasm for arbitrary code. None of these tradeoffs are particularly scalable or lead to a reasonable developer experience.

By building the wander toolkit, we’re on a mission to build universal rendering in Wasm - and learning a lot of lessons along the way. Come listen to some of these lessons about efficiently using linear memory, orchestrating effective task level parallelism, and get an early preview of how you could access GPUs in a standardized way through WASI, bridging the gap between native and web code.