The frame keeps its budget on a weak GPU: the renderer picks its own pixel scale, and says what it picked #297

Every game here draws at Math.min(devicePixelRatio, 2) and hopes. src/engine/renderer.ts:294 sizes the drawing buffer to the canvas times that ratio and nothing ever reconsiders it, so a phone at DPR 3 draws 4x the pixels of a laptop at 1 with a tenth of the fill rate, and the only thing that gives is the frame. The pool counters, the budgets in src/budget.test.ts and the meter all measure the work a frame asks for; nothing measures the work the GPU could not do, and nothing reduces it.

This is engine work, not the shooter's: all three games hand in a devicePixelRatio supplier, and all three would take the same answer.

Done looks like

• [ ] createRenderer takes an optional frame-time budget (the default is off, so nothing changes for a caller that says nothing) and, when it is on, keeps a scale between a floor and 1 applied on top of the capped device ratio.
• [ ] The scale moves on measured frames, not on one: a rolling median over a handful of frames, a step down when it is over budget and a slower step back up when it is comfortably under, with a dead band so it cannot oscillate. The rule is written down in the module's own comment the way the pool's rule is.
• [ ] It is asked, not guessed: the renderer exposes the scale it is drawing at, and the game may read it. The shooter shows it where the frame meter already is and only when it is below 1 — a player whose game got softer deserves to know why.
• [ ] The scale never changes what a frame means: the camera, the projection and the overlay's CSS-pixel coordinates are unaffected, and the 2D HUD and the radar are still drawn at the capped device ratio, so text never gets soft. Say in the pull what you checked to prove that.
• [ ] Tests that would fail without this, all headless: a stub clock and a stub gl through fakePage, a sequence of long frames drives the scale down to the floor and no further, a sequence of short ones brings it back to exactly 1, a frame time that straddles the budget does not oscillate, and with no budget given the drawing buffer is byte-for-byte what it is today.
• [ ] The door, the pinned list in boundary.test.ts, bun run scripts/surface.ts --write, and the renderer section of GUIDE.md saying what the budget is and what a game gets for handing one in.
• [ ] The pull states measured numbers: the shooter's frame time at scale 1 and at the floor, on the same machine, and what the three bundles weigh after (a tool set ships whole, so the range and the example pay for this too — say what it costs them).

Files I expect to change

src/engine/renderer.ts and its test, src/engine/index.ts, src/engine/boundary.test.ts, src/engine/surface.json, src/engine/GUIDE.md, src/client/main.ts and src/client/hud.ts for the readout, src/games.ts if a ceiling moves.

Risks

• A scale that changes every frame is worse than a soft picture: the dead band and the median are the whole design, and a test that drives it with a hostile frame-time sequence is the one that matters.
• Do not resize the canvas element. This is the drawing buffer only; a layout shift would undo the point.
• #75 (booting becomes engine) touches the same sizing from the game's side — the two are independent but will meet in src/client/main.ts; whichever is second rebases.

Suggested: Vesper.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.