WebAssembly multithreading tracking issue

## UPDATE: This is on hold while `TaskPool` and `Scope` are reworked ### Motivation Currently, Bevy can only run single threaded on WebAssembly. Bevy's architecture was carefully designed to enable maximal parallelism so that it can utilize all cores available on a system. As of about six months ago the stable versions of all browsers have released the web platform features needed to accomplish this (`SharedArrayBuffer` and related CORS security functionality). I think now is a good time to attempt to make Bevy run natively in the browser like it does on the desktop: fully multithreaded. There are three distinct tasks that will enable the accomplishment of this goal: 1. Create a modified versions of `task_pool::{Scope, TaskPool, TaskPoolBuilder}` that run on wasm called `wasm_task_pool::{Scope, TaskPool, TaskPoolBuilder}`, and use those instead of the `single_threaded_task_pool::{Scope, TaskPool, TaskPoolBuilder}` (TODO: create issue and link here) 2. Modify bevy_audio so that it runs mutlithreaded in the background (not on the main thread) on wasm (TODO: create issue and link here) a. Contribute the functionality needed to to do background multithreaded audio using WebAssembly via the web platform's [AudioWorklet API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Using_AudioWorklet) to the upstream dependencies of bevy_audio (TODO: create issue and link here): i. cpal (TODO: create issue and link here) ii. rodio (TODO: create issue and link he

Posted by colepoirier on Mar 2, 2022, 2:53 AM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0