Re-measure the screensaver set on the wall's own host — the board is done, the 30 savers are not

[BernardJen]

Every screensaver has now been measured at the real videowall resolution. Until today
every figure in this repo was taken at 3000×600 — a quarter of the pixels — so nothing
was known about the resolution the app actually runs at.

Method

node shot.mjs --root <repo>/input_viewer_electron --saver "<name>" \
  --size 6000x1200 --times 15 --seed 4242 --gpu

30 savers, 15 seconds each, one fixed seed (4242), real GPU (ANGLE/Metal, M3 Pro) — not
SwiftShader, which shadercheck deliberately forces for determinism and which says
nothing about speed. The list came from STRUCTURE_BASELINES, which is generated from
the registry, so it is all 30 and no preset names.

Results

Saver	fps @ 6000×1200	Rewritten today
Flow Field	15.6 ⚠	—
Raymarch Fractal	18.4 ⚠	#217
Mandelbrot	26.6 ⚠	#210
Frost	34.3 ⚠	—
Bicycle Horizon	35.9 ⚠	—
Voronoi	43.8 ⚠	#211
Plasma	50.7	#216
Burning Ship	62.4	—
Strange Attractor	66.8	—
Aquarium	75.6	—
Weather	76.3	—
Metaballs	86.4	#218
Starfield Warp	91.6	#212
Truchet Tiles	92.5	#214
Reaction Diffusion	103.1	#220
Particle Swarm	103.8	—
Julia Set	108.7	—
Pong	113.7	#213
Matrix Rain	114.5	#219
Boids	114.6	—
Physarum	117.7	—
Moire Interference	118.9	#215
Double Pendulum	119.9 (vsync cap)	—
ASCII Doughnut	120.0 (vsync cap)	—
Wave Tank	120.0 (vsync cap)	—
Tree Growth	120.0 (vsync cap)	—
Game of Life	120.1 (vsync cap)	—
Falling Sand	120.1 (vsync cap)	—
DVD Logo	120.1 (vsync cap)	—
White Particles	120.2 (vsync cap)	—

Three savers stutter, and the worst is not new

Flow Field at 15.6 fps is the slowest saver in the set, and it predates this batch.
It is one of the twelve the owner singled out as already good. That is the opposite of the
expected result: the eleven rewrites merged today are mostly healthy, and the
pre-existing set carries the worst offender. Nobody had filed a bug, because nobody had
measured at this resolution.

Raymarch Fractal at 18.4 fps is the one real casualty of the rewrite batch. #217
carried the claim that it "costs less than the version it replaces"; that was flagged as
unverified when it merged, and at 18.4 fps it should not be relied on. The likely cost
centre is that the temporal accumulation blends into a canvas-sized HDR target every
frame — cheap at 1.8M pixels, much less so at 7.2M.

Mandelbrot at 26.6 fps is the price of the perturbation-theory dive from #121. That
may simply be what an unbounded dive costs; worth confirming rather than assuming.

Frost (34.3) and Bicycle Horizon (35.9) are marginal rather than broken, and neither is
from this batch.

Two limits on what this proves

• Wrong machine. These are M3 Pro numbers, not the machine that drives the wall. A
  weaker GPU shifts everything down proportionally, so 35 fps here could be 20 there.
  The figures are comparative, not a pass mark. Re-running this on the actual wall
  host is the measurement that would settle it, and it is one command.
• The ~120 readings are a vsync cap, not a measured ceiling. Twelve savers are
  refresh-bound and have unknown headroom above 120.

Not a release blocker

Nothing here is a regression. Flow Field has evidently been shipping at this speed for
some time. But three savers visibly stutter on the wall, and that is now measured instead
of suspected.

Acceptance criteria

• Re-measure on the machine that actually drives the videowall, and record those
  numbers here — they are the ones that matter
• Flow Field profiled and brought above 30 fps at 6000×1200
• Raymarch Fractal above 30 fps, or its accumulation target decoupled from canvas size
• Mandelbrot above 30 fps, or the cost documented as inherent to the dive with the
  per-frame iteration budget stated
• Decide whether a floor belongs in CI at all — bench exists and shot.mjs reports
  fps, so a regression gate is possible, but a fps threshold on shared CI hardware is
  notoriously flaky and may be worse than nothing
• Frost and Bicycle Horizon reviewed once the three below 30 are dealt with

[BernardJen]

Relevance check, 2026-08-18: the title is now wrong and two of six criteria are done.

Only one saver is below 30 fps, not three. Retitling accordingly.

Saver	At filing	Now
Flow Field	15.6	33.3 — #228
Raymarch Fractal	18.4	31.7 — #230
Mandelbrot	26.6	26.6 — unchanged, see below

• Flow Field above 30 — perf: halve Flow Field's noise evaluations — 15.6 → 33.3 fps at 6000×1200 (#119) #228. Cut noise evaluations from 164 to 64 per pixel by reducing
  integration steps while holding arc length constant. An analytic-gradient approach reached
  40 fps but changed the field and was backed out.
• Raymarch above 30 — perf: cut Raymarch Fractal's step budgets — 18.4 → 31.7 fps at 6000×1200 (#225) #230. Step and iteration budgets reduced as a set; individually
  most of them did nothing, which reads as an occupancy effect.
• Mandelbrot — the explanation exists but is not in the source, so this stays open.
  It already runs a closed loop on measured frame time (TARGET_FRAME_MS = 20, reducing
  maxIter by 5% per frame when it overshoots) and at 26.6 fps it has driven itself down to
  its iteration floor (MIN_ITER_BASE = 220 + 40 per zoom doubling). So 26.6 is the cost
  of that floor, not a defect — going faster means lowering it and accepting less detail at
  depth, which is a quality decision. This criterion asks for that documented in the file
  with the per-frame budget stated; that has not been written.
• Re-measure on the machine that actually drives the wall — not done, and still the most
  important item here. Every figure in this issue is an M3 Pro; the wall's host is unknown.
• Decide whether an fps floor belongs in CI
• Frost (34.3) and Bicycle Horizon (32-36) reviewed

One correction to a figure I put elsewhere: I claimed on #201 that its 32.6 fps for Bicycle
Horizon was measured at 3000×600 and was inconsistent with 35.9 at 6000×1200. Wrong — both are
6000×1200, 11% apart, which is this saver's ordinary run-to-run variance. Retracted on #201.

[BernardJen]

The Mandelbrot criterion is now met — documented in the source by #254, merged to main.

• Mandelbrot — cost documented as inherent to the dive, with the per-frame budget stated: the floor runs 220 iterations at the surface to 3420 at MAX_DIVE_LOG2 = 80, against a wanted ceiling of 300 to 4460. TARGET_FRAME_MS is not met at 6000×1200 and cannot be — the loop reduces maxIter whenever the frame-time EMA exceeds 23 ms, which at 37–77 ms is every frame, so it clamps at the floor and stays.

One figure in this issue needs correcting. The 26.6 fps recorded above was measured over a 15-second run, early in the dive. Cost climbs with depth because the budget does:

run	fps	ms/frame
15s, shallow	26.6	37.6
60s, deeper	13.0	76.9

So this saver is meaningfully slower than this issue records, and there is no single frame rate for it — any figure has to say how far into the dive it was taken. That does not change the conclusion (the floor's cost is a quality decision, not a defect), but it does mean the 26.6 in the table above understates it by roughly half at depth.

Three of six criteria are now done. Remaining:

• Re-measure on the machine that actually drives the wall — still the most important item here. Every figure in this issue is an M3 Pro.
• Decide whether an fps floor belongs in CI
• Frost (34.3) and Bicycle Horizon (32–36) reviewed

[BernardJen]

Measured on the wall's own host at last — and the conclusion is that this issue's
central assumption was wrong.

The hardware, confirmed

gl renderer      ANGLE (NVIDIA, NVIDIA RTX PRO 4000 Blackwell (0x00002C34) Direct3D11 vs_5_0 ps_5_0, D3D11)
gpu_compositing  enabled
webgl / webgl2   enabled / available
EXT_color_buffer_float  yes
primary display  6000x1200 @1x

Not a weaker GPU than the M3 Pro every figure above was taken on. A serious professional
card with a current driver, on hardware acceleration, at the real resolution.

What was actually slow

This issue assumed the problem was per-saver GPU cost, and its worry was that "a weaker
GPU shifts everything down proportionally, so 35 fps here could be 20 there". That is not
what was happening. Two CPU-side wastes were, and neither is a shader:

	fps on the wall	what changed
as found	1.4	Art-Net's frame readback ran every frame — 32 synchronous gl.readPixels per runtime, 64 across two boards, with Art-Net disabled
after #275	45.3	readback registered only when enabled, and rate-limited to 1Hz
after #283	59.7	system-volume poll scoped to when the dropdown is visible — it had been spawning PowerShell and compiling C# every 2 seconds

43x, and none of it was rendering. 59.7 is vsync: the wall is at its display's ceiling.

The per-frame split says so directly:

saver                      fps   draw    pre   work  frame   wait   n  size
Split Flap (left)         59.7   0.08   0.17   0.25  16.74  16.49  12  2918x1200
Split Flap (right)        59.8   0.02   0.01   0.03  16.73  16.70  12  2918x1200

work is 0.25 ms of a 16.74 ms frame — the render loop is idle 98.5% of the time.

What this does and does not settle

• Re-measure on the machine that drives the wall. Partly. The split-flap board is
  measured there; none of the 30 savers is yet. The wall had not been in no-signal
  long enough for the screensaver rotation to start during any of these readings.

  What has changed is that this no longer needs a measurement campaign. The frame-rate
  instrument (#271, #279) ships in the app and writes
  `userData/fps-report.txt` continuously — one row per saver, overwritten, bounded by
  the number of savers rather than by uptime. Leave the wall in no-signal past the
  five-minute delay and the rotation measures the set by itself. Someone just has to
  read the file.
  

• Frost and Bicycle Horizon reviewed. Unchanged, and now cheap: they will appear in
  that file with their own rows.

• Decide whether an fps floor belongs in CI. The calculus has shifted. The original
  objection stands — an fps threshold on shared CI hardware is notoriously flaky. But a
  floor is no longer the only option, because the wall now reports its own real numbers.
  A gate on the wall's report is worth more than a gate on a runner's, and costs
  nothing in CI.

One thing worth carrying out of here

Every figure in this issue was taken on Apple Silicon, and the readback hypothesis was
tested there and measured at 4% — which is why it was dismissed. On the wall's discrete
GPU the same code cost 32x. Unified memory makes readPixels nearly free; a PCIe round trip
does not.

Measuring GPU-adjacent cost on the development machine is not a weak version of measuring it
on the wall. It can point the opposite way.