Computer vision / 2026 / Live in the browser
WebGPU Vision Lab
Four image filters written twice, once as a Canvas2D loop and once as a WGSL compute shader, running on the same webcam frame side by side with honest timings.
01
The problem
Everyone says WebGPU is faster. Almost nobody shows the number, and the number turns out to depend entirely on the filter.
02
How I approached it
The same four kernels on both paths, with the CPU side written fairly: typed arrays, precomputed Gaussian weights, clamped edges, the same work per pixel the shader does. Pipelines compile once and textures survive between frames, because recreating them per frame is the usual reason a naive port comes out slower. Readback handles the 256-byte row alignment that copyTextureToBuffer requires. Timing is a rolling median so one stalled frame cannot set the headline.
03
The outcome
On an Intel Iris Xe at 172,800 pixels: Gaussian blur 159.9ms to 7.0ms (22.8x), dilate 19.4x, adaptive threshold 19.3x. Sobel, at a fixed 3x3, only 2.1x. The GPU column barely moves between filters because it is dominated by transfer overhead, so speedup tracks arithmetic per pixel, not the API. Cheap operations do not repay the move.
Camera: this runs entirely in your browser. No video is uploaded or stored.
Related work
Twelve real-time webcam effects in one booth, each a separate shader-style pass over the camera feed.
Face, hands and 33-point pose tracked at once, fusing MediaPipe Tasks with parallel TensorFlow.js detectors on a GPU-first backend.
A five-phase energy sequence that doubles as a calculus visualiser: the blue phase renders partial sums, asymptotic rings and Zeno-style halving.