World Explorer: performance, 5 October 2026

Where a frame's time goes, in every world, in calm flight and in a heavy fight, at zoom 100% and 50%; what was changed to make the game smooth and what each change bought, with screenshots compared pixel by pixel. Build: commit 64c9626 and the changes listed below.

How it was measured

bin/perf plays scenes of build/index.html in headless Chromium (Playwright) at a window of 1920 × 1080, at device pixel ratio 2 (the main case: a 4K screen at 200%; the game caps the ratio at 1.7, so the canvas is 3264 × 1836) and at 1. It works on a copy of the page with a hook inserted before the script's last line, so the game itself carries no measuring code. The page runs on a virtual clock of 1/60 s a frame and a seeded Math.random; the menu's clocks and seeds are reset when a scene starts, so a scene is the same frame for frame on every run and every build (two runs give identical canvases). Each scene is played 240 frames without drawing, drawn 60 more, then measured over 300 frames (5 s of game time).

Each at zoom 100% (-z100) and 50% (-z50): 38 scenes. The ship never dies.

What is reported:

• frame: the main thread's time inside the game's frame(): update, drawing (the canvas calls) and the HUD. p50, p95, p99 and the longest of 300 frames, and how many took longer than 16.7 ms (a missed frame at 60 Hz) and 33 ms.
• GC: the garbage collections in a trace of the 300 frames (MinorGC, MajorGC), their total and longest pause, and the memory allocated a frame (what the collections freed plus what the heap grew).
• raster: this machine has no graphics card, so Chromium draws the canvas in software, on the same main thread. --mode=layers flushes the canvas around each drawing pass, so a pass's time includes its raster; on a graphics card that work moves to the GPU process, so these numbers rank what is expensive to fill and blur rather than predict milliseconds there.
• --mode=profile: a CPU and an allocation profile per scene; --mode=shots and --compare: screenshots of the canvas at a fixed frame, compared pixel by pixel between two builds.

What was slow

Ranked by what it costs a frame at ×2, before the changes.

1. The sky layer in the big worlds. render_nebula_layer drew the nebula into a canvas padded by 2.5% of the map's size on every side, for the parallax. The maps grow from 12 km (Haven) to 240 km (Eclipse), so the layer did too: 1320 × 900 px in Haven, 3335 × 2915 in Obsidian, 6960 × 6540 (174 MB) in Eclipse, built again on every window resize (428 ms in Eclipse). In worlds 5–8 of the campaign that image made Chromium flush the canvas in the middle of the frame, at the planet's drawImage: render took 20–28 ms every frame, calm or not, and every one of the 300 frames went over 16.7 ms (the worlds 1–4 drew in 1–1.5 ms). Most of the layer can never be seen: the camera never goes left of or above the map, and past the glow and the clouds the sky is one colour.
2. The pulse, EMP and chain fronts. Each front was stroked with shadowBlur = 18, and the depot's shield ring with 24. A blurred shadow of a large circle is a Gaussian blur over its whole bounding box: about 100 ms a ring in software and 68 ms in SwiftShader (Chromium's GPU path on the CPU), for a ring 300–840 px across at ×2. In the fights it was the largest drawing cost by far: render_pulse_wave 69 ms a frame of 116 in Haven at 100%, 54 of 98 in Ion Reach at 50%. On a graphics card it is the same blur in a shader over a 4K canvas, once per front per frame, with up to a dozen fronts after a pulse chains.
3. Collisions in a crowd. bodies_settle runs four passes of every raider against every rock and every other raider (36 raiders and 108 rocks: about 18 000 checks a frame), each through Math.hypot. Raiders come in many shapes (fields added as they fly), so V8 threw the optimized code away 25 times in 8 s and recompiled bodies_settle 34 times; between recompiles it ran in a lower tier that boxes every number. In a fight: 2.8 ms of CPU and 1.5 MB of garbage a frame in bodies_resolve, bodies_settle and bodies_push_out alone.
4. Math.hypot everywhere. V8 does not inline it: every call allocates its numbers. In a micro test, a million distances cause 275 minor GCs with Math.hypot and 13 with Math.sqrt(dx*dx + dy*dy), which is also 2–3 times faster. distance() and segment_distance() are called thousands of times a frame; 260 KB a frame came straight from the builtin.
5. Arrays built per object per frame. block_hostile_ore ran ore_nodes.filter() and a sort for every raider shot every frame (380 KB a frame and 0.3 ms in the arcade's Eclipse); each drifting rock built [station, ...portals, ...world_gates] and a closure every frame.

Together the fights allocated 2.5–2.9 MB a frame: 186–219 garbage collections in 300 frames, the longest 4–7 ms, which is where the stutter in a crowd comes from even when the average frame is short.

What changed

Each item is one commit; the files are listed so they can be staged separately. Every change but the glow keeps the simulation and the picture the same: the canvases of all 38 scenes, compared pixel by pixel (bin/perf --mode=shots then --compare), differ by at most 1 of 255 on about 20 pixels (the sky layer's new edge) and, in Eclipse at 50%, by at most 8 of 255 in a 3 px column at the screen's edge where the old layer ended.

1. The sky layer only as large as can be seen (src/js/render_cache.js). nebula_box() keeps the part the parallax can bring into view (the camera only moves right and down from the map's corner) and the glow and the clouds colour; past it the sky is the glow's last colour, filled under the layer. The box stays on the old layer's pixel grid, 16 units at a time, so the layer renders as before. Eclipse 6960 × 6540 → 1444 × 1235 (174 → 7 MB), built in 64 ms instead of 428; Obsidian 37 → 6 MB. Worlds 5–8: render 20–28 → 1.0–1.3 ms a frame, frames over 16.7 ms 300 → 0 of 300.

2. Ring glows as gradient rings (src/js/draw.js, src/js/pulse.js, src/js/depot_shield.js; pulse.js also carries one Math.hypot of item 4). ring_glow() draws what the shadow drew: the stroke's profile convolved with the same Gaussian (σ = shadowBlur/2 canvas pixels, measured in Chromium), as a radial gradient of 25 stops over an annulus. A small ring, whose shadow is cheap and where the flat profile would be off, keeps the real shadow; so do the shield's hit flashes. Look: the pulse and EMP fronts mid-flight (frame 90 of a fight) differ by at most 3–4 of 255 at ×1 and 8 at ×2, no pixel by more than 8. Cost of a front in software raster: render_pulse_wave 69 → 12 ms (Haven fight, 100%), 54 → 10 ms (Ion Reach, 50%), 25 → 6.5 ms (arcade Eclipse); the depot shield 13 → 10 ms.

3. Collisions on typed arrays (src/js/bodies.js, src/js/update.js; update.js also carries two Math.hypot of item 4). The settling passes and raider_avoid read x, y and r from Float64Arrays filled each frame, not from raiders of many shapes, and skip a pair apart along either axis before any square root (an exact test). The rocks are loaded again just before the raiders move, since a pulse can shrink a mined rock in the frame. The player's pass no longer calls ore_nodes.includes() for every rock.

4. Math.sqrt instead of Math.hypot in the hot paths (src/js/helpers.js, src/js/map.js, src/js/missiles.js, src/js/drones.js, src/js/sprites.js). distance(), segment_distance(), the missile's speed, the drones' flight, a sprite's raster size, and in items 2 and 3 the star bend and the shots. The square root rounds differently in the last bit: two pixels in one scene of 38 differ after 300 frames.

5. No arrays per shot or rock (src/js/flight.js, src/js/expedition.js). block_hostile_ore finds the nearest rock hit in one loop and skips a rock clear of the shot's box; debris_sanctuary() looks up the station, portals and gates in the old order without building an array.

6. bin/perf, the tool, and this page (bin/perf, docs/performance-2026-10-05.md, docs/README.md).

7. The HUD writes only what changed (src/js/hud.js, src/js/operations.js, src/js/update.js, src/js/navigation.js, src/js/guidance.js, src/js/world_visuals.js, src/js/physics.js, src/js/music.js, src/js/expedition.js, src/js/goals.js, src/js/arcade.js). Every 0.12 s the HUD's layers wrote about 35 texts and markups whether or not they changed, and four of them (act, mission name and phase, navigation status) twice, a later layer overwriting an earlier one; each write rebuilds the element and costs a style and layout pass. hud_text() and hud_html() now hold the writes until the end of update_hud and write only a value that differs from the page's (text) or from the last one written (markup, while the element still holds the nodes it made). In a fight 35 writes a tick fall to 2–6 (the distance, the alert, a changing readout). Script in update_hud 0.07 → 0.04 ms a frame, style and layout 0.21 → 0.14 ms in a fight and 0.09 → 0.00 calm: the tick's spike falls from about 2 to 1.4 ms in a fight and from 1.1 to 0.2 ms in calm flight (×2, 300 frames, the same scenes before and after). Every element of the HUD reads the same as before at frames 30, 97 and 300 of a calm flight, a fight and the arcade (bin/perf --mode=shots now saves the HUD's text beside the canvas), and a driven check moves hull 40 → 100, pulse 43% → Ready, turbo 8.0 s → Ready, Dock → Jump at a gate and back at the station.

The missile smoke trails stay as they are. Behind 53 raider missiles in Nova Forge at 50% they cost 0.5 ms of script and 3.4 ms of software raster a frame, nearly all of it in the one arc and fill per puff that the look needs: building no arrays per trail and caching the ribbon's colours and the sprites' anchors measured 0.51 → 0.49 ms and was left out. Puff sprites cost more (1600 puffs: 1.6 ms of script instead of 0.4, and 70 ms instead of 3 in SwiftShader); one path per colour would draw overlapping puffs once, and they overlap by most of their size, so the smoke would turn flat and lighter; the smallest puff, a dart's newest, is about 1 px across at 50% and ×1 (1.7 px at ×2), and dropping it would remove its share of grey. A graphics card batches such circles into one draw.

Items 3–5 together: in the CPU profile of the Ion Reach fight at 50% the collision functions fall from 2.8 ms a frame to below the top 30; over the 16 fights, update falls from 2.6 to 1.0 ms a frame, allocation from 2.7 to 0.7 MB a frame and garbage collections from 202 to 54 per 300 frames.

Before and after

Main-thread time per frame at ×2 (1920 × 1080 at 200%), in ms, before → after. Before and after ran side by side on the same machine; the arcade rows come from a second run, one build after the other. The one long frame of the Verdant fight after is a major garbage collection of 20 ms.

Update and render per frame (ms), garbage collections in 300 frames, memory allocated a frame, and the main thread's whole time a frame with the software raster:

At ×1 (1920 × 1080 at 100%), frames over 16.7 ms of 300 per scene, summed by kind:

The same at ×2: calm 1200 → 0 and fight 1201 → 2 at 100%, calm 1200 → 0 and fight 1201 → 2 at 50%; the worst p99 of any campaign scene 57 → 11 ms.

Raster by pass at ×2 (--mode=layers, ms a frame, software canvas; the passes not named are under 3 ms):

The software raster numbers wander by a few ms between runs (the arcade's sky layer and scenery went up while its fronts went down); the fronts and the Eclipse sky are the changes that hold in every run.

What is left

• The sky layer, kept at half resolution, is scaled up to the canvas every frame: 20–27 ms in software, a single textured quad on a graphics card. The depot shield's hex lattice is about 460 separate strokes; one path would merge the shared edges and change their brightness, so it stays.
• Smaller garbage: debris_sanctuary, gravity_move and in_gravity_core still allocate about 50 KB a frame each (numbers V8 boxes), block_hostile_ore 170 KB a frame in the arcade's Eclipse.
• The portals' turning arcs keep shadowBlur: they are partial arcs, small on screen and only near a portal.
• No graphics card here: the numbers that transfer are the script's and the garbage collector's. A check on the 4K machine itself would be Chrome's Performance panel over a fight at 50% in Eclipse.

14 October: the canvas's raster

A player's log (Chrome on Linux, a 1536 × 794 window at 250%, so the canvas at the 1.7 cap, 3.5 million pixels) showed 45 fps in the arcade's late worlds on Overload while work_ms said 1.8 ms a frame; at 125% the same player had 60 fps. work_ms times the script in frame(), and a canvas call only records the drawing: the raster runs after the frame, on the main thread for a software canvas. The play log now also keeps paint_ms, the main thread's time from the end of frame() until a message posted then arrives (docs/play-log.md); in a headless test it took nearly all of the frame. bin/perf --mode=raster flushes the canvas at each frame's end and reports the frame with its raster; --size, --dpr and --difficulty play the player's window (the arcade scenes now start at Ion Reach).

What cost the most, by --mode=layers at 1536 × 794 ×2.5 on Overload: the sky layer scaled from half resolution to the canvas each frame (20–35 ms), the scenery's sprites turned and scaled each frame (15–28 ms; a turned copy costs the software canvas 5–15 times an unscaled one), Nova Forge's planet scaled (up to 25 ms), the depot shield's lattice under its clip (up to 16 ms at 50%). What changed, each to the nearest device pixel and otherwise the same drawing:

• render_cache.js: the sky layer is scaled to device pixels once over the window and a 128 px margin, and copied unscaled each frame; drawn again when the parallax takes the window past the margin.
• sprites.js sprite_draw_still(): a sprite that keeps its turn and size (scenery, planets, the outer moon, the station's and gates' bodies, the black hole, rocks, structures) is turned and scaled once into a copy and copied unscaled; a spin layer still turns each frame. While the zoom moves, and for a copy over 8 million pixels, it is drawn as before. The copies share a budget of 16 million pixels, the least recently drawn going first.
• depot_shield.js: the lattice's cells clear of the rim are stroked before the clip, the cells the rim cuts under it (the cells never touch).
• physics.js: Nova Forge's glow fills the circle its gradient reaches, not the square round it.

The canvases of all 47 scenes at ×2 differ only by that rounding: edges move by at most half a device pixel (up to 210 of 255 on a sharp edge, under 1% of the pixels by more than 8 in most scenes); the HUD's text is the same in all. Frame with its raster, p50 at ×2.5, before → after: arcade Ion Reach 85 → 53 ms, Nova Forge 102 → 64, Eclipse at 50% 89 → 51, calm Nova Forge 39 → 23; at ×1.25 the arcade's 47–70 → 32–45. Left as it was: the pulse and EMP fronts (gradient rings, 12–20 ms while one crosses the screen), the explosions, the dynamic sprites (raiders, debris, pickups turn every frame).

Running it

bin/build
bin/perf                                 every scene, frames, ×2
bin/perf --dpr=1 fight-w7-z50            one scene at ×1
bin/perf --size=1536x794 --dpr=2.5 --difficulty=overload --mode=raster arcade-w6-z100
bin/perf --mode=layers --wrap=render_pulse_wave fight-w3-z50
bin/perf --mode=shots --label=before     screenshots, then after a change:
bin/perf --mode=shots --label=after
bin/perf --compare=before,after

--page= measures another copy of the page (a build kept from before a change). The reports and screenshots go to data/perf/, which git ignores.