wander: a WebAssembly rendering engine you embed in your own app

A renderer, not an engine

wander is a GPU-based rendering framework designed to be fully embeddable in any application, and the name in the repository title is wander, the Wasm Renderer.

The problem it addresses is stated in the README's own terms. Many visual apps need a high-performance rendering engine that works in a browser or in a native app, where a JavaScript library won't scale, but a game engine is not the right application model.

That is the whole positioning, and it is a narrow one. A game engine gives you a scene graph, an entity system, an asset pipeline and an event loop, and it expects to own the main loop and the window. wander gives you a way to execute graphics code you did not write, inside an application that already has all of that. The application keeps its own loop, its own window and its own scene; wander adds the ability to run renderlets and to draw the result.

The promise is that wander is primarily designed as the runtime to run renderlet bundles, but can also be used more generically as a WebAssembly-based rendering engine that uses the GPU.

The technology underneath is Wasm. The library links against wasmtime, which is vendored in the repository as a wasmtime directory, and the WebAssembly modules it runs are the renderlets. The licence is MIT, the primary language recorded for the project is C, and the last push was on 2026-07-06 with a single tagged release, 0.1.0 from 2024-03-31.

Renderlets are self-contained graphics modules

The unit of work in wander is the renderlet: a self contained, portable module of graphics data and code compiled to WebAssembly, which can be run in any software.

The list of benefits the SDK brings is worth reading as a design statement rather than a feature list. You get high performance 2D and 3D graphics, and fully portable rendering pipelines, meaning any app, device, client or server, with sandboxed third party code execution. The rendering modules are self contained, so you can reuse your graphics code as building blocks. There are no game engine or platform dependencies, and no GPU expertise is required.

Sandboxed third party code execution is the item that changes what the project is for. A renderlet can be supplied by someone you do not know, and it runs inside a WebAssembly sandbox rather than inside your process with your privileges. That is the property that makes the use cases below plausible rather than hypothetical.

The use cases the documentation lists are all about the same idea. Modern CAD apps, where you use code to allow objects to describe how to render themselves. Procedural modeling and data visualisation, executing runtime code to view your data in new ways. Product visualization, interacting with dynamic objects in 3D on any device. Composable user interfaces, rendering any UI module on top of an existing canvas or in any scene. Interactive animations, described as like Adobe Flash but with an actual programming language and GPUs. And low or no-code graphics, making graphics pipelines out of existing building blocks.

The CAD example is the clearest statement of the intent. The application does not need to know what a given object looks like; the object brings its own renderer.

Five steps from device to render tree

The API flow in the quickstart is short, and the shape of it tells you how the library is meant to be owned.

const auto pal = wander::Factory::CreatePal(
        wander::EPalType::D3D11, baseDevice, baseDeviceContext);
auto runtime = wander::Factory::CreateRuntime(pal);

auto renderlet_id = runtime->LoadFromFile(L"Building.wasm", "run");

auto tree_id = runtime->Render(renderlet_id);
auto tree = runtime->GetRenderTree(tree_id);

The steps are: create a PAL object based on your device's underlying GPU API, where PAL is the platform abstraction layer that hides D3D11, OpenGL or whatever else sits underneath. Create a global runtime object, with the documentation noting that this is not currently thread safe. Load a renderlet file, with an optional entry point name, and get it ready to run. Run it, which for static content can be done once but for dynamic content could be per frame. Then get a non-owning pointer to the output.

Two details in that sequence are worth pausing on. The runtime is described as global and is explicitly not thread safe, which is a real constraint for an application that wants to render from more than one thread. And the render tree pointer is non-owning, so the tree stays valid only as long as the tree id does, which is why the teardown functions matter.

The naming convention also tells you something about the shape of the data. The renderlet is loaded from a file with an entry point name, so a single module can expose several entry points, and the result of running one is a tree of nodes rather than a single draw call.

Drawing means iterating a render tree

The rendering side is deliberately thin, and the reasoning is worth understanding because it explains what a renderlet actually returns.

deviceContext->PSSetShaderResources(0, 1, &textureViewWhite);

for (auto i = 0; i < tree->Length(); ++i)
{
    tree->NodeAt(i)->RenderFixedStride(runtime, stride);
}

You bind your own resources, and then you walk the tree and let each node render itself. There is no need to manage the underlying graphics data or buffers, because wander takes care of it. The name RenderFixedStride says what the node expects: a fixed stride layout, so the runtime can draw the data without copying it into a format it likes.

That is the design in one line. The renderlet produces data in a layout the runtime can hand straight to the GPU, and your application keeps ownership of the graphics API calls. The alternative would be a renderlet producing a description that your application has to translate into buffers, which is where the interesting performance problems start.

Teardown is symmetric. To delete and free old content you call runtime->DestroyRenderTree(tree_id), and wander can tear down every object automatically on unload or close with runtime->Release(). For an application that reloads renderlets as the user navigates, having both is what you need: fine grained release for one tree, and a global release for shutdown.

The platform table is a status board

The support matrix in the documentation is worth reading as a status report rather than a compatibility list, because it uses three different markers rather than a yes or a no.

The table covers OpenGL, DX11, DX12, WebGPU, Vulkan and Metal across Windows, Linux and Android, macOS and iOS, and the Web. A white check mark means currently supported. A hammer and wrench means in progress, coming soon. A triangular ruler means in design or planned for the future.

What is supported today is narrower than the list of APIs might suggest. OpenGL is supported on Windows at GL 3.3 and on macOS and iOS, with WebGL2 for the Web still marked as planned, and the Linux and Android entry is OpenGL ES 3.0 or newer and still in progress. DX11 is supported on Windows, with DX12 in progress there. WebGPU is in progress for the Web. Vulkan is planned across the board rather than supported on any platform, and Metal is planned for macOS and iOS.

So the honest reading is that today the library runs on Windows through Direct3D 11 and on desktop Linux and macOS through OpenGL, with the rest of the matrix being intent.

There is a useful symmetry here, and it comes from the design. Since a renderlet is WebAssembly and the runtime executes it, the graphics API only has to be present in the host process. Adding a backend is an engineering task on the host side, not a change to the renderlet format, which is why the table can honestly show most of it as planned.

The rive-renderer path and what it costs

The one substantial integration documented in detail is with rive-renderer, and it shows both the potential and the current limits.

wander has experimental support for 2D vector operations using rive-renderer. Currently this is only supported in the Windows and Direct3D11 backend, the project is working on a WebGPU build, and macOS will require a Metal backend.

The build instructions are the part that tells you what kind of project this is. It is non-trivial to build rive-renderer on Windows, so precompiled binaries and .lib files are provided in the D3D11 example, and the manual route wants a MinGW toolchain, a clone with submodules so that rive-renderer lands in libs with rive-cpp submoduled inside it, a manual CMake run for glfw with specific flags, a premake5 invocation producing a Visual Studio solution, then switching every project to the MD or MDd runtime, upgrading path_fiddle to C++20 with warnings as errors disabled, and finally building in Visual Studio or via MSBuild.

Nine steps, each with a flag or a version to get right, is the real cost of that integration today, and it is the cost you should weigh before planning on vector support.

Wiring it up afterwards is simpler. You define RLT_RIVE globally in your project, which the DX11 example does automatically in the Release build, and wander links to the output libraries automatically.

The rest of the project is lighter by comparison. wander is delivered as a cross-platform C++ library, and you add wander.h and wander.cpp to your build chain along with the included dependencies such as wasmtime. CMake support is not yet implemented, so integration means following the platform specific examples, and there are examples for D3D11 and for OpenGL 3.3 on Mac, Windows and Linux, along with GL, HeadlessGL, OBJHost and WebGL example directories and two sample renderlets, Building.rlt and Vector.rlt.

For Linux, the Dockerfile in the repository is the reference path: Ubuntu with Clang 17, the wasmtime C API version v18.0.3 for x86_64, GLFW built from source, and the usual build dependencies.

Editorial conclusion

wander suits a team building a native or embedded application that has to run third party graphics code, for example a CAD tool where each object describes how to draw itself, or a product viewer that has to work in a browser and on a phone. It is the wrong choice for a project that wants a supported rendering stack, because the version is 0.1.0 from March 2024, the runtime is not thread safe, and CMake support is not implemented, so integration means following the platform specific examples by hand. Verify three things before you build on it: that the graphics API you need is in the supported column rather than the in progress one, that you can tolerate building the library and its wasmtime dependency from source, and that the rendering model of a render tree with fixed stride node data matches what your renderer needs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. renderlet/wander on GitHub