Web Support

[cart]

It should be possible to run Bevy Apps on the web

[takkuumi]

yeap, plz, i am waiting for, i am using the pathfinder now

[lwansbrough]

The most significant blocker for full web support is likely to be multithreading. An MVP for this probably needs to be single threaded.

Some thought should be put into understanding what Bevy changes would be required to support asynchronous thread waiting, as it is not possible to block the main thread in web browsers.

A couple alternative solutions may exist to this and I’ll leave them here for future discussion: Binaryen Asyncify, and rendering off the main thread using a worker and some combination of an offscreen canvas API and WebGPU.

[takkuumi]

@lwansbrough what is about run thread in web work?

[lwansbrough]

@nateling With the Canvas API we can transfer control from the main thread to a web worker. According to this comment WebGPU will (may already?) have the same capability to transfer control to a worker. Edit: I see now that WebGPU uses a canvas like canvas.getContext('gpupresent'); so it works the same way in theory. This transfer of control works like this for Canvas:

const offscreen = document.querySelector('canvas').transferControlToOffscreen();
const worker = new Worker('myworkerurl.js');
worker.postMessage({ canvas: offscreen }, [offscreen]);

from: https://developers.google.com/web/updates/2018/08/offscreen-canvas#unblock_main_thread (This page has several examples.)

Then I suppose Bevy would then spawn additional WebAssembly threads from this main worker. I don't know what Bevy needs in order to work, but it sort of seems to me like the required browser features exist.

Edit:

So the issue here actually seems to be what happens once you start doing work in workers. Work done by the Amethyst team showed that browsers will not execute tasks until control is returned to the main thread. You can follow that issue here and Azriel made a demo which you can find here.

[azriel91]

Heya, one thing I'd like to share:

It's quite difficult to integrate with the browser event loop unless one uses async Rust, but it's also difficult to share source for both a native app and WASM app using winit (because winit's event loop is non-async).

So, is it possible to use winit, async, and WASM all at the same time?

The answer is yes -- before I went back to work, I made this thing: https://nginee.rs/examples/event_loop_rate_limit.html

• Repo: https://github.com/azriel91/nginee
• Example usage of nginee::EventLoop: examples/event_loop_rate_limit
• Code that you may want to copy/learn from: crate/event_loop/src/event_loop/window/rate_limit_on.rs

Also, worth noting that that currently uses a single threaded pool to run the tasks (futures), I hadn't tried integrating with web workers yet

(not intending to promote -- please look at the code for how you would convince Rust to run async event handlers inside a synchronous winit event loop, and not freeze the browser)

[kettle11]

An approach to working with async in the browser is to have a Vec of events that are passed to an async function. If the async function is blocked, then enqueue the event for the async function to receive later.

There's an incomplete but workable implementation of this idea in kapp: https://github.com/kettle11/kapp/blob/main/src/async_application.rs

It allows code like the following example to be written:

async fn run(app: Application, events: Events) {
    let mut _window = app.new_window().build().unwrap();

    // Loop forever!
    loop {
        match events.next().await {
            Event::WindowCloseRequested { .. } => app.quit(),
            Event::Draw { .. } => {}
            _ => {}
        }
    }
}

[lwansbrough]

Yet another approach is to run the entire engine off the main thread. This makes blocking a non-issue, as WASM Threads (Web Workers) are allowed to block.

This is an example using WebGPU to render in an offscreen canvas hosted by a web worker. This should work once WebGPU contexts are supported by offscreen canvases. It sits beside a main thread canvas which is rendered using WebGPU. That part is working today in Chrome Canary with --enable-unsafe-webgpu enabled.

This is an active area of development. Support for WebGPU in offscreen canvases in Chrome is being tracked here and is currently blocked by a refactor.

[Waridley]

FYI the issue fixed by uuid-rs/uuid#477 was blocking compilation to WASI for several of Bevy's crates, but just got merged today.

[smokku]

I attempted porting https://github.com/amethyst/web_worker WorkerPool implementation as a replacement TaskPool - it looked very promising and the changes are straightforward.

The main issue I stumbled is that wasm_bindgen::JsValue and wasm_bindgen::closure::Closure are not Send nor Sync, thus such TaskPool cannot become a Resource. It may be an issue for any implementation using wasm-bindgen provided bindings.

You can look at my change at: https://github.com/smokku/bevy/commit/2ad15d8e1830b891e76b73c92dab28a2dd911ee5
Just an experimental PoC, so a bit messy at the moment. See README on how to compile.

[dlight]

The main issue I stumbled is that wasm_bindgen::JsValue and wasm_bindgen::closure::Closure are not Send nor Sync, thus such TaskPool cannot become a Resource. It may be an issue for any implementation using wasm-bindgen provided bindings.

Is wrapping each of them in an Arc a problem?

[smokku]

Is wrapping each of them in an Arc a problem?

Unfortunately the internals of these types are the issue. Arc protects the type, but not internals.

[smokku]

Single threaded implementation works fine though. https://github.com/smokku/bevy/commit/72d672515584e7c865915c649a8759dcf3460b1b

I will make it into a proper PR soon - just have a question:

• Should I make the TaskPool changes a separate feature?
  i.e. Legion has parallel feature (enabled by default). I think there may be other contexts where single threaded implementation might be useful.