seanisom

This is pretty cool - great to see what a small codebase can do with raw WebGL. Have you looked at WebGPU at all?

Working fine for me on Firefox - their WebGL support tends to be good enough, although there are plenty of other resource issues.

This is awesome! The dev loop for web apps is kind of broken - really cool that you can keep this running in a browser.

Yes! You should be able to get nearly native performance for that sort of pipeline out of a WebGL backend.

Can you utilize streaming compilation of the Wasm modules? This significantly improved load times in Photoshop Web.

GPU processes are separated due to driver instability and unsafe code, so this means more than a GPU process crash, or a content process crash (tab crashed), something in the orchestration layer or main process crashed. There are probably massive amounts of memory being moved around which could easily be stressing the system or running into large limits. Don't think this is related to the security model or a compromise of an origin / content process.

Just wander itself is almost working in a browser - kind of hacked together right now, but will be pushed to the open-source soon. The same Wasm payload should be able to run in the browser or through wasmtime.

For the rive-renderer / 2D integration, it is going to be a much longer path to get working in a browser together with wander.

Anybody remember COM? Yes, this is certainly not a new problem.

Keeping it high level -

No, the goal is not to create a C++ API to give you GPU functions.

The C++ API for wander is used to embed the WebAssembly module of graphics code into the application. The API footprint is very small - load a file, pass parameters to it, iterate through the tree it produces.

This could be viewed as logically equivalent to programmatically loading a flash/swf file. Or similar to what Rive has built with a .riv, although this is static content, not code.

> 1) Why use WASM?

You're loading arbitrary, third-party code into an app - that is the renderlet. The benefit is to have a sandboxed environment to run code to put data on the GPU.

2) Why use renderlet instead of webGPU, which is already a high level cross platform abstraction including shader definitions?

WebGPU is a low-level API. If you are a graphics programmer, and want to build an app around WebGPU, go for it! A renderlet is more of a graphics plugin system than an entire first-party app.

> The renderlet compiler is currently in closed preview - please contact us for more information.

This is the system to build the renderlet. This is not writing raw C++ code to talk to WebGPU, this can be higher-level functions (build a grid, perform a geometric extrusion, generate a gradient) - you can see in the video it is a yaml specification. The compiler generate the necessary commands, vertex buffers, textures, etc, and soon, shaders to do this, and builds a Wasm module out of it.

> Is this like a 'alternative to webGPU' with a different API / easy mode tooling?

I certainly wouldn't describe it as an alternative to WebGPU, but easy(er) tooling to build graphics, yes.

> What is the use-case for 'I've compiled a part of my application only into a cross platform binary renderlet and I can now run that cross platform ... after I've compiled the rest of my application into a platform specific binary for the platform I'm running it on?'

Let's take an example - Temporal Anti-Aliasing. There are libraries that exist to implement this, or you can implement it through raw code. This requires changes structural changes to your pipeline - to your render targets, additional outputs to your shaders, running additional shaders, etc. Wouldn't it be nice to easy connect a module to your graphics pipeline that contains the code for this, and the shader stages, and works across platforms and graphics APIs, with data-driven configuration? That is the vision.

> ... rest of your application into WASM/platform native code... is that not strange? It seems strange to me

There is not really such a thing as a standalone Wasm application. It has seen great success as a data-driven plugin model. In a browser, it is hosted with / interacts with JavaScript. Even built for pure WASI, as a standalone app where everything is compiled into a single module, there is stil a runtime/host environment.

Does that help clarify?

Great suggestion, appreciate it. wgpu is coming!

More of a comment on how apps are being built in the future - web-first is becoming the default.

I already see web even taking over in things like embedded UIs where native toolkits like QT historically were popular.

Appreciate it. It's coming! I want to get the compiler working and generally available and everything working seamlessly for Web first. Stay tuned!

Interesting! Had never heard of it before, will check it out. The point of Haxe seems to be as a meta-compiler to generate code for a bunch of different languages/compilers? The same spirit of the Wasm dev experience but without the runtime.

Text / fonts is very much on the roadmap! For input and audio I would have to think through the scope.

That's exactly it. With renderlet, the goal is to compile the "frontend" code that's driving the rendering pipeline to WebAssembly, and provide a runtime that embeds that in any app, with the host app providing any configuration necessary to connect renderlet modules and use its canvas.

On the "backend", we will switch fully to wgpu as we retool around wasi-webgpu. I explicitly don't want to rebuild a project like wgpu, and everybody should commit upstream to that - we will likely have stuff to upstream as well.

This is awesome! I'm not fluent with Flutter/Dart but would like to dig in to how the build / Wasm packaging works.

The state of shared memory for Wasm is not great, although raw SharedArrayBuffers work ok in a browser for running multiple guests. Getting multi-memory properly working through llvm is likely a better solution.

We've got a bundle size issue as well even with -O3. I thought it was due to the amount of templated glm simd code we run, but now am convinced its deeper than that into Emscripten. Haven't been able to look into deeply yet.