The video editor draws through one of two graphics engines. WebGL is the default and has always been there. WebGPU is the newer one — the same editor, the same projects, drawn through a modern GPU API.
Choosing an engine
App Settings ▸ Video Editor ▸ Video editor renderer offers WebGL (default) and WebGPU. The choice applies to every video project.
Changing it safely restarts the open preview, so effects, 3D layers, materials and GPU resources all end up on the same engine rather than half on each. Until WebGPU is selected, none of its code is loaded at all — the setting is not a flag that leaves both paths running.
App Settings itself is split into three tabs — Canvas, Video Editor and AI Agents — rather than one long scroll.
What was ported
Every built-in layer effect, transition, 3D layer, particle system, shader background and the Rig, Auto Fill and Motion Trail tools were ported and checked frame-against-frame with the classic WebGL renderer, so a project looks the same on either engine.
A machine that cannot run WebGPU says so plainly instead of failing with a developer error, and a transition or custom shader that only exists on one engine tells you where it will and will not run.
Which to use
Stay on WebGL unless you have a reason to move. It is the default, it is the most-tested path, and nothing in the editor requires the other one.
Try WebGPU when you are working on something heavy — a Particle Solver above 50,000 particles, several 3D layers, or a long effect chain. The particle solver’s live GPU preview engine is a WebGPU feature: below 50,000 particles a system is baked and runs anywhere, and above that the WebGPU engine owns the layer.
Custom GLSL in the Overlay Effects chain and custom shader backgrounds are the one place where an engine difference can be visible, because a hand-written shader may target one API. The picker tells you which.
Rendering
The engine choice carries through to rendering, so an export uses the same one the preview did. Particle layers, Chroma Key and Grid Builder members all render the right way up on both — a run of orientation faults specific to WebGPU was fixed, and the two engines are now compared pixel-for-pixel in the test suite on the effects that were affected.
Leave a Reply