Native WASM support for WebGL

[jasonrichardcraig]

I'm advocating for native WASM support for WebGL (My intentions' are to allow .Net MAUI to target the browser):

Why Native WASM Support for WebGL?

1. Performance Improvements
   Reduced Overhead: Eliminating the need for JavaScript as an intermediary between WASM and WebGL would reduce the performance overhead of context switching and data marshaling.
   Example: Large datasets like vertex buffers or textures wouldn’t need to be copied between WASM and JavaScript memory spaces.
   Faster Rendering: WASM can directly execute graphics commands, leading to lower latency in GPU-bound operations.
2. Simplified Development
   Unified Development Model: Developers can focus on one language (e.g., Rust, C++, or C# compiled to WASM) rather than managing a dual-layer system (WASM for computation, JS for rendering).
   Easier Debugging: Debugging performance issues across WASM and JavaScript layers is complex. Native support would simplify this process.
3. Unlocking WASM's Full Potential
   High-Performance Computing: WASM is designed for near-native performance. Native support would allow it to leverage this capability fully for GPU-intensive tasks.
   Broader Adoption: By enabling WASM to interact directly with WebGL, the development community could expand use cases for WASM, such as gaming, scientific visualization, and real-time simulations.
4. Forward-Looking Standards Alignment
   WebGPU Integration: WebGPU, the successor to WebGL, already emphasizes high-performance and low-level control. Native WASM support for WebGPU would align well with modern web standards.
   WASI Expansion: As the WebAssembly System Interface (WASI) evolves, incorporating native graphics support aligns WASM with broader system-level capabilities.
   How This Could Be Achieved
5. Direct API Exposure
   Browser vendors could expose WebGL APIs directly to WASM, bypassing JavaScript.
   This might involve creating a specialized WASM-compatible interface layer for WebGL.
6. WASM-Friendly WebGL Bindings
   Develop lightweight bindings that integrate directly with WASM memory and execution model.
   For example, WASM could pass pointers to GPU data structures, avoiding JavaScript intermediation.
7. Collaboration with Standards Bodies
   Advocate for this feature in the WebAssembly Community Group or relevant W3C working groups.
   Push for extending WASI or creating new specifications for WASM-native graphics APIs.
   Potential Challenges
8. Browser Compatibility
   All major browsers would need to adopt and implement these changes, which requires coordination among vendors.
9. Security Concerns
   Direct access to WebGL (or WebGPU) from WASM must maintain the web’s robust security model.
   Potential issues like memory safety, sandboxing, and cross-origin resource sharing would need thorough review.
10. Development Effort
    Implementing WASM-native WebGL support would require significant engineering resources and testing by browser developers.
    Proposed Messaging to Developers
    Subject Line: Proposal: Native WebAssembly Support for WebGL APIs
    Introduction:
    As the development community increasingly adopts WebAssembly (WASM) for high-performance applications, we encounter a significant bottleneck in the current WebGL integration model. WASM relies on JavaScript as a bridge to access WebGL, introducing overhead and complexity. Native support for WASM-to-WebGL interactions could resolve these issues, bringing substantial benefits to developers and users alike.

Key Benefits:
Performance: Direct WASM-to-WebGL interaction eliminates intermediary overhead, improving execution speed for GPU-heavy tasks.
Developer Experience: Simplifies cross-layer communication and debugging, allowing developers to focus on high-performance application logic.
Future-Ready: Positions WebGL and WASM to support emerging technologies like WebGPU, aligning with the next generation of web standards.
Call to Action:
We propose exploring a roadmap to enable native WASM support for WebGL APIs. This effort could start with the creation of WASM-friendly bindings, leveraging WASI or a similar framework to ensure a secure, performant, and scalable solution. Community collaboration and pilot implementations in experimental browser builds could accelerate adoption.

Next Steps
Present this proposal to relevant browser vendors (e.g., Mozilla, Google, Microsoft, Apple).
Open discussions in WebAssembly Community Group meetings or forums.
Build prototype implementations or proofs of concept to demonstrate the feasibility and benefits.