Browser-native GPU API that replaces WebGL with Vulkan/Metal-class semantics: compute shaders, multi-threaded command encoding, two-orders-of-magnitude performance gain.
What it is
WebGPU is a W3C standard for accessing the GPU directly from a browser. It went to Candidate Recommendation in 2024 and ships in Chrome 113+, Edge, and Safari 18; Firefox follows. Unlike WebGL (which wraps OpenGL ES) it gives low-level access comparable to Vulkan and Metal — multi-threaded command encoding, compute shaders, explicit pipeline state.
Why ProAV cares
For software video walls with browser-based control panels, WebGPU collapses a previously hard architectural problem: client-side preview canvases that can hold 20-30 live 4K source thumbnails without burning the operator's laptop. Published benchmarks show WebGPU sustaining 200,000 scene objects at 60 FPS on an NVIDIA RTX 3080 where WebGL collapses past 15,000.
The architecture shift
- Multi-threaded command encoding — the renderer is no longer single-threaded on the JS main thread, so the main thread stays free for UI interaction.
- Compute shaders — run general-purpose GPU workloads in the browser, including parts of the preview pipeline that used to require server-side rendering and a streamed screen capture.
- Three.js TSL — from release r166 onward, Three.js exposes a Shading Language (TSL) that compiles to WebGPU and WebGL alike. Practical on-ramp for existing WebGL codebases.
What it doesn't do
WebGPU does not replace the server-side composer that drives the physical video wall panels — that still wants Vulkan or a comparable native API for the determinism and panel-output throughput. WebGPU's domain is the operator's browser: control plane, preview, situation maps, overlay graphics.
When to plan for it
New browser-based control panels in 2027-2028 will assume WebGPU is available. Existing WebGL panels keep working — there is no deprecation pressure — but anything beyond a static layout grid will start to feel slow once peer products move.