Rendering splats in the browser

A trained splat scene is a few million semi-transparent ellipsoids, and a browser has to composite them in the correct depth order every frame, from whatever angle the user has dragged the camera to. Drawing them is the easy part; keeping them in order is where all the interesting engineering in a web splat renderer actually lives, and it’s also the axis along which WebGL and WebGPU renderers genuinely differ.

Why splats have to be sorted

alpha blendingA compositing technique that accumulates colour from ordered, semi-transparent primitives, each weighted by its own opacity and by how much light nearer primitives have already absorbed. Splat rasterisers use it to blend overlapping Gaussians into a final pixel colour. is order-dependent: the “over” operator that composites semi-transparent primitives is not commutative, so blending the same Gaussians in a different order produces a different pixel. Opaque triangles avoid this because the depth buffer keeps the nearest fragment per pixel and discards the rest, which is exactly why meshes can be drawn in any order. A depth test keeps one winner; it cannot accumulate weighted contributions from everything behind that winner, which is what translucent Gaussians need. So every visible Gaussian must be blended back to front, which means an explicit sort by distance along the view direction, and that sort has to be redone whenever the camera moves, because the correct order is a property of the viewpoint, not the scene.

The drawing itself is cheap by comparison. Renderers submit the whole scene as instanced quads in a handful of draw callA single CPU-issued command asking the GPU to render a batch of geometry. Splat renderers draw an entire scene as instanced quads in very few draw calls, so frame cost concentrates in sorting and blending rather than call count.s, so the frame cost concentrates in two places: the sort, and the fill-rate burned blending millions of overlapping fragments.

The WebGL answer: sort on the CPU, in a worker

Under WebGL2 there is no compute capability worth the name, so the standard architecture, established by antimatter15’s original 2023 viewer, is to sort on the CPU in a web worker and stream the new order to the GPU. That project’s README is explicit that a GPU-side bitonic sort was tried and rejected: sorting a million elements bitonically takes on the order of two hundred passes, which lost to a tuned CPU sort. The pattern stuck. Mark Kellogg’s GaussianSplats3D runs its sort in a WASM and SIMD accelerated worker sharing memory via SharedArrayBuffer, gsplat.js sorts back to front in a worker of its own, and PlayCanvas’s WebGL path does CPU-side sorting too. The practical consequence of an asynchronous sort is that the order lags the camera by a frame or two; renderers hide it well at normal orbit speeds, but a fast flick can briefly show splats blending in a stale order.

What WebGPU changes

WebGPUThe modern web graphics API succeeding WebGL, whose compute-shader support makes GPU-side splat sorting possible in a browser. Shipped by default in Chrome and Edge since 2023 and, as of the 26-generation Apple OS releases, in Safari. brings compute shaders to the web, and compute shaders make a proper GPU radix sort possible. This is shipped, not hypothetical: the PlayCanvas engine exposes a GSPLAT_RENDERER_RASTER_GPU_SORT mode that its own source documents as “GPU-side culling and sorting. WebGPU only.”, alongside a CPU-sort mode and an auto mode that picks per device, falling back to the CPU sort on WebGL. PlayCanvas’s June 2026 numbers for the WebGPU path claim 1.1x to 5.7x speedups on desktop and roughly 2x on mobile against WebGL2; their published device figures include an iPhone 13 Pro Max rendering a 4 million Gaussian scene at 42 fps under WebGPU against 20 fps under WebGL2. In the three.js ecosystem no equivalent GPU sort ships in the dominant libraries yet, so CPU-sort-in-a-worker remains the practical default outside PlayCanvas.

Where browser support actually stands

WebGPU shipped in Chrome and Edge in 2023 (Chrome 113 on desktop, 121 on Android). Firefox turned it on for Windows in version 141 and has been rolling out macOS since, with Linux still pending. The one that matters most for splat delivery is Safari: WebGPU is enabled by default in macOS Tahoe 26, iOS 26, iPadOS 26 and visionOS 26, no flag needed, which makes 2026 the first year all three engines ship it by default. The install base lags the releases, though: every device still on an older OS gets WebGL2, so WebGPU is a progressive enhancement and the CPU-sorted WebGL2 path remains the floor a production scene has to be budgeted against.

Popping: the sort everyone ships is approximate

Sorting whole Gaussians by a single depth value is itself an approximation, because Gaussians are volumes that overlap in depth. As the camera rotates, pairs of splats swap places in the global order and the blend result changes discontinuously: the visible artefact is popping, a flicker along thin structures and silhouettes during rotation. StopThePop (SIGGRAPH 2024) attacks this with hierarchical per-pixel resorting so each pixel blends in genuinely correct order, but its reference implementation is CUDA and a desktop viewer; no shipping web renderer implements it as of mid-2026. Browser viewers simply live with the artefact, and it’s worth knowing it is a sorting approximation, not a training defect, when a client asks why an edge shimmers.

In practice

Leave renderer selection on automatic and let the engine take the GPU sort where WebGPU exists, but do all performance sign-off on the WebGL2 CPU-sort path, because that is what an older iPhone will actually run. When reviewing a delivered scene, test with fast orbital moves: sort lag and popping both show up under rotation, not in stills, and thin railings or mullions are where they show first. And treat mild popping as a known cost of the technique rather than something to burn training iterations trying to fix.