GPU graphics

GPU.js · analytic spheres

For each output pixel, a camera ray is tested against every active sphere using the ray–sphere quadratic equation. A positive intersection nearer than previous hits determines the visible surface. The surface normal supplies diffuse lighting and a specular highlight; a pixel with no hit keeps the background. This kernel does not trace the Three.js workload's shadow rays or reflected scene ray.

A fixed pseudorandom seed generates sphere positions and velocities. Time drives bouncing motion inside the kernel, rather than a CPU physics simulation. Each frame re-evaluates the scene at the selected 16:9 output resolution. More spheres mean more intersection tests per pixel; more pixels mean more kernel invocations. GPU.js selects WebGL2 when available, otherwise WebGL. The app checks the initialized kernel backend and rejects CPU fallback. GPU.js is the app default, not a benchmark standard.

Three.js · raymarched spheres

Three.js renders a fullscreen surface through WebGL2. Its fragment shader finds the nearest sphere distance at each sampled point and advances along the camera ray by 85% of that distance. A distance below 0.0015 scene units counts as a hit; travel beyond 18 units or the configured step limit ends the search. This is numerical raymarching, not the analytic intersection loop above.

On a hit, six nearby distance queries estimate a surface normal. A separate shadow march uses up to 16 steps, and one reflected ray can sample another surface. These extra queries also evaluate active spheres, making sphere count and the 16–128 primary/reflection step ceiling different kinds of load controls. Rays can exit early, so the ceiling is not a measured iteration count. Deterministic seed data and shader time drive motion; this is not a rigid-body physics test.

Timing and comparison

Both sphere implementations retain a rolling two-second window of browser animation-frame intervals and report approximately every 250 ms. Frame interval is the arithmetic mean; FPS = 1000 / mean interval in ms. Jitter is the population standard deviation of those intervals. These are browser presentation measurements, not GPU hardware timers or utilization. Exported callbacks preserve their reported windows; they are not a whole-session average.

For intervals Δt, mean = sum(Δt) / sample count and jitter = sqrt(sum((Δt − mean)²) / sample count). Early reports contain less than two seconds of observations. Initialization precedes reporting, but there is no separate standardized GPU warm-up/calibration phase. Monitor refresh, browser frame pacing, power management and background activity can cap or disturb FPS, even when the GPU could render faster. Keep the tab visible and repeat matching runs; displayed decimal places do not establish hardware-timer precision.

Matching sphere counts do not make these different algorithms equivalent. Compare only the same workload, backend, resolution, settings and browser configuration. Counts are bounded to 8192; large counts can stall the driver. Stop if the device becomes unstable. No calibrated GPU score is produced.