Radix, Spark, and PlayCanvas
drawing the same splats

With the same culling, Radix and PlayCanvas are close

The renderers' defaults draw different splats: PlayCanvas drops tiny and faint splats that Radix and Spark draw, which makes it look faster than it is at like-for-like work. So the comparison here sets Radix and Spark to cull and dilate exactly as PlayCanvas does by default (section 02). With culling matched, Radix and PlayCanvas run at similar speeds on WebGPU.

• With culling matched, Radix and PlayCanvas are close on WebGPU: Radix is 1.03× slower than PlayCanvas (geometric mean over the scenes; Butterfly 3.44 vs 3.52 ms, Ceramic (cave) 5.82 vs 5.55 ms, Sutro 3.42 vs 3.43 ms, Bicycle 4.83 vs 4.54 ms, Grace interior 8.09 vs 7.55 ms, Radix first).
• On WebGL2 with culling matched, relative to Radix: Spark · WebGL2 1.08×, PlayCanvas · WebGL2 1.36×. PlayCanvas's WebGL2 path has no contribution cull, so there the match is the pixel size cull, the alpha floor and the dilation.
• Without any culling, where every renderer draws every splat, Radix on WebGPU is 1.05× slower than PlayCanvas on WebGPU; on WebGL2, relative to Radix: Spark · WebGL2 1.08×, PlayCanvas · WebGL2 1.38×.
• The defaults are not like for like. PlayCanvas by default culls splats drawn under a 1-pixel radius and, on WebGPU, splats whose opacity × area is under 0.75 px²; Radix and Spark cull neither. These culls remove visible detail (most of the bicycle's wheel spokes on WebGPU), and PlayCanvas's fixed dilation is 0.075 px², a quarter of the 0.3 px² of standard 3DGS training, so its splats are drawn smaller than trained. So at defaults Radix on WebGPU is 1.30× slower than PlayCanvas. PlayCanvas's culling makes PlayCanvas on WebGPU 1.20× as fast as without culling, and Radix 1.23× (1.26× as fast as its defaults).
• Radix's WebGL2 path stalls while it re-sorts. Its sort cycle (a keys pass on the GPU, a readback, then the order's upload) lands in the frames: 724 frames over twice the median across the scenes at defaults (Spark and PlayCanvas on WebGL2: 7), and its mean frame is 1.25× its median (section 05).

The speed of each renderer relative to Radix on WebGPU with culling matched (above 1× is faster), as the geometric mean over the 5 scenes of the ratio of mean frame times.

On WebGL2 only

Spark has no WebGPU path, so the like-for-like comparison with it is on WebGL2, where all three sort on the CPU (on a worker) and draw with WebGL. With culling matched, relative to Radix on WebGL2: Radix · WebGL2 1.00×, Spark · WebGL2 1.08×, PlayCanvas · WebGL2 1.36×.

• Frame times varied by 0.4% between rounds (the median coefficient of variation over configs); the canary stayed within 2.8% of its first measurement (10 runs after a slower canary were measured again, section 10).
• No run failed.

What the defaults drop, and how it was matched

Every renderer skips splats it considers invisible, but by different rules. Radix and Spark follow the reference 3DGS rasterizer: they draw every splat above a tiny alpha (0.5/255) and blur each by 0.3 px² with opacity compensation. PlayCanvas also drops splats drawn under a 1-pixel radius (σ under about 0.22 px) and, on its WebGPU path, splats whose opacity × area is under 0.75 px², with an alpha floor of 1/255 and a fixed 0.075 px² blur without compensation. On scenes with many distant or faint splats, that is a lot of work skipped, and visible detail with it: on WebGPU it removes most of the bicycle's wheel spokes.

PlayCanvas's settings read larger than that because it measures its 2D covariance with twice the focal length in pixels (viewportWidth × P[0], where the pixel focal length is half of it) and halves its quad again when drawing, so the drawn size is right but its constants are in half pixels: minPixelSize: 2 is a 1 px radius, minContribution: 3 is 0.75 px², and its 0.3 dilation is 0.075 px². That dilation is a quarter of the 0.3 px² that standard 3DGS training uses, so PlayCanvas draws splats smaller than they were trained, and it cannot be changed.

Three culling settings

Every scene ran with three settings: matched (PlayCanvas's default culling and dilation in all three; PlayCanvas at its defaults), defaults (each renderer as it comes), and no culling (pixel size and contribution minimums at 0 and alpha 1/255 for all, the lowest PlayCanvas allows on WebGPU; each renderer keeps its own dilation), so every renderer draws every splat. Sort keys stay at each renderer's default throughout (section 11).

Bicycle was trained without anti-aliasing (a 0.3 px² dilation without opacity compensation), so the defaults and no-culling runs draw it that way: Radix · WebGPU objectParams.blurAmount: 0 objectParams.preBlurAmount: 0.3; Radix · WebGL2 objectParams.blurAmount: 0 objectParams.preBlurAmount: 0.3; Spark · WebGL2 renderer.blurAmount: 0 renderer.preBlurAmount: 0.3; PlayCanvas · WebGPU antiAlias: false; PlayCanvas · WebGL2 antiAlias: false. Matched keeps PlayCanvas's 0.075 px², a constant in its shaders.

Frame time per scene, culling matched

Still, turning level, turning and tilting

The path has three parts of equal length: the start view held still, a full turn at the start elevation, and a full turn tilting up and down. Objects (butterfly, Sutro, bicycle) are orbited, ±30° in elevation in the third part; in interiors (the ceramic cave, Grace Cathedral) the camera looks around, ±45° in pitch, while walking a level circle facing out (radius a tenth of the distance to the start view's target), so distance sorts must re-sort. The still part shows a renderer's cost with nothing to re-sort; the turns add sorting, and on the CPU-sort paths, orders that arrive a few frames late. Culling matched:

Medians, tails, and stalls

Per scene, culling matched: the median frame (dot), the 95th percentile (tick) and the 99th (end of the line), the median over rounds. A stall is a frame over twice the median: on the CPU-sort paths these are usually the frames that upload a new order.

Butterfly · 546k splats

Ceramic (cave) · 2.0M splats

Sutro · 2.0M splats

Bicycle · 6.1M splats

Grace interior · 10.0M splats

Main-thread time per frame

The CPU time of the frame call alone (the renderer's update, sort dispatch and draw submission), the median over rounds, culling matched. It is small for every renderer, so the timing method's lack of CPU and GPU overlap costs little.

In a vsync loop

The timed numbers above measure each frame alone. An app runs in a requestAnimationFrame loop paced by the display: one frame's CPU work overlaps the previous frame's GPU work, and a frame that misses a vsync is a stutter. Every config also ran that way, in headed Chrome with vsync on (120 Hz, 3 rounds). Frame i draws pose i of the same path and nothing waits for the GPU, so a slower renderer takes longer over the path.

• Scenes at the full 120 Hz (within 3%, under 1% of frames late), of 5, culling matched: Radix · WebGPU 4, Radix · WebGL2 3, Spark · WebGL2 3, PlayCanvas · WebGPU 5, PlayCanvas · WebGL2 4.
• Over the 8.30 ms budget when timed, but at full rate with vsync (consecutive frames overlap CPU and GPU work): Radix · WebGL2 on Ceramic (cave) (8.74 ms, 119 fps); PlayCanvas · WebGL2 on Bicycle (9.36 ms, 120 fps).
• Under the budget when timed, but dropping frames with vsync: Radix · WebGPU on Grace interior (8.09 ms, 118 fps).
• Frame rate (capped by the display, which shrinks differences): Radix on WebGPU 1.00× PlayCanvas on WebGPU; on WebGL2, Spark 0.97× and PlayCanvas 1.11× Radix.
• Worst p99 frame intervals: Spark · WebGL2 on Grace interior 58.9 ms (max 66); Radix · WebGL2 on Grace interior 50.0 ms (max 59); Radix · WebGL2 on Bicycle 35.9 ms (max 44).

Per scene, the median over rounds: frames per second, the share of frames late (over 1.5 display frames), the p99 frame interval in ms, and the timed mean frame. Green: full rate; red: below it (full red at 33% below).

Culling matched

Defaults

No culling

These are requestAnimationFrame intervals, not presented frames; Chrome's backpressure keeps the two close. The display caps the rate, so on light scenes every renderer reads 120 fps.

What you get out of the box

Each renderer with its default settings, so with different culling (section 02): PlayCanvas skips work the others do. Relative to Radix on WebGPU: Radix · WebGPU 1.00×, Radix · WebGL2 0.67×, Spark · WebGL2 0.73×, PlayCanvas · WebGPU 1.30×, PlayCanvas · WebGL2 0.98×; on WebGL2, relative to Radix on WebGL2: Radix · WebGL2 1.00×, Spark · WebGL2 1.09×, PlayCanvas · WebGL2 1.47×.

Radix and PlayCanvas on WebGPU, by culling

Radix with its defaults and with PlayCanvas's culling, against PlayCanvas with its defaults and without culling: how much of the difference at defaults is the culling.

Every renderer drawing every splat

Pixel size and contribution minimums at 0 and alpha 1/255 for all: every splat is drawn, each with its renderer's own dilation. Relative to Radix on WebGPU: Radix · WebGPU 1.00×, Radix · WebGL2 0.67×, Spark · WebGL2 0.72×, PlayCanvas · WebGPU 1.05×, PlayCanvas · WebGL2 0.92×; on WebGL2, relative to Radix on WebGL2: Radix · WebGL2 1.00×, Spark · WebGL2 1.08×, PlayCanvas · WebGL2 1.38×.

Time to the first frame

Was the laptop throttling?

Before every run the driver waited for macOS to report a nominal thermal state (ProcessInfo.thermalState): up to 90 seconds while "fair", which by itself is not throttling, and up to 5 minutes at "serious" or worse, then an idle gap. A canary (Radix on WebGPU, the butterfly, 120-frame parts) ran at the start of each round, every ten runs and at the end; when it came out more than 8% slower than its first measurement, the driver cooled down for a minute and measured it again, and measured the runs since the last good canary again. The configs ran in a different random order each round, so a slow period would spread over all of them rather than one.

• Thermal state after each run: nominal 335, fair 0, serious 0, critical 0. 0 runs waited for the machine to cool first (0.0 minutes in all).
• 10 runs were measured again after a slow canary.
• Power: Now drawing from 'AC Power'.

Every round

Mean frame time (ms) of each round of every config, the coefficient of variation between them (yellow over 5%), and the thermal state before each run.

How it was measured

Inputs

Each scan was decoded by Radix's loader and written as a standard degree-0 3DGS PLY (float32 position, log scales, rotation, logit opacity, DC color), so all three renderers load the same bytes and draw degree-0 color only: Radix has no spherical harmonics, and Spark and PlayCanvas would otherwise evaluate the degree-3 SH of the Grace, Sutro, and bicycle files. PlayCanvas reads no SPZ, so the SPZ scans needed converting anyway. The decode quantizes slightly (SPZ sources are quantized already; the PLY sources lose some color and scale precision), identically for every renderer.

Renderers and defaults

Sort keys

Each renderer sorts with its default key width. Radix uses 24 bits: the distance's float bits without the low 7, so splats more than about 0.0015% of their distance apart are ordered. Spark always sorts 32-bit keys (the float distance). PlayCanvas picks its width from the splat count and spreads it linearly over the range of visible distances, with more of it near the camera; its GPU sort rounds the width up to whole 8-bit radix digits.

All renderers draw at 1920×1080 at pixel ratio 1 with MSAA off, onto a black background, in headless Chrome (WebGPU on Metal; WebGL2 through ANGLE on Metal). Each config runs in a fresh tab, so nothing is shared between renderers or scenes.

Timing

• The camera path is a function of the frame index (240 frames per part, 3 parts), so every renderer draws exactly the same poses.
• Frames are driven by the page, one at a time: the renderer's own frame call (Radix and Spark: renderer.render; PlayCanvas: the application's tick, its whole update and render), then a wait until the GPU finished all submitted work (WebGPU: queue.onSubmittedWorkDone(); WebGL2: a one-pixel readPixels), then a yield to the event loop, so asynchronous sorts on workers land as they would in an app. A frame's time runs from its call to the GPU being done.
• This measures each frame's whole cost (its CPU work, then all of its GPU work) without the overlap of a pipelined loop. Uncapped requestAnimationFrame timing was tried and rejected: Chrome runs WebGL frames far ahead of the GPU without vsync (one renderer timed at 16,000 fps).
• Before measuring, each config warms up for at least 120 frames and 3 seconds of the path (pipelines compiled, caches warm, the first asynchronous sorts done). The path is then repeated until at least 6 seconds were measured (up to 6 passes).
• Every config ran 5 rounds; each number is the median over rounds. PlayCanvas's matched numbers are its default runs (the same settings). Timer resolution is 0.1 ms.
• The vsync run (section 06) drives the same path from requestAnimationFrame in headed Chrome with vsync on: one warm-up pass, then 2 measured passes. Thermal waits and the canary (a timed run) are as above.

Caveats

• One machine: an Apple M3 Max laptop. A slower GPU or a phone would shift the balance toward whichever renderer culls more.
• Matched culling equalizes which splats are drawn and how they are dilated, not every detail: PlayCanvas sizes splats on its WebGPU path by the 2D covariance's diagonal, Radix and Spark by its eigenvalues (a difference only right at the threshold), and the sort metrics differ. Image quality was compared by eye only. The first round saved every config's start view; the summary shows the bicycle in each renderer at its defaults.
• The CPU-sort paths draw orders a few frames old while the camera turns: the timing counts their cost, not the visual lag.
• Radix's numbers come from its code at the time of the run; Spark and PlayCanvas are the latest npm releases.