Renderer: frame pacing — frame-rate limiter, update/render decoupling, frame-time smoothing

[drsnuggles8]

Problem

The window layer exposes only a vsync toggle (Platform/Windows/WindowsWindow.cpp glfwSwapInterval). There is no frame-rate cap, no frame-time smoothing, and update+render are fully coupled (one update per present) in Core/Application.cpp.

Why it matters (performance / feel)

• No way to cap to 60/120/144 for power/thermals or consistent pacing.
• Coupled update/render makes frame-time spikes jerk the simulation (largely mitigated once sim is on a fixed tick — see the determinism issue).

Proposed approach

• Configurable frame-rate limiter (sleep + short spin to hit target frame time).
• Decouple update (fixed tick) from render (display rate) with interpolation — pairs with the fixed-timestep work.
• Optional frame-time smoothing / EMA for the delta handed to interpolation.

Acceptance criteria

• Selectable frame cap (off / 60 / 120 / 144 / custom) that holds steady.
• Render rate decoupled from sim tick; smooth motion at non-multiple refresh rates.

---

Tier C — performance / feel.

Score

capability: 3
craft: 3
stability: 2
decay: 1
effort: 3
confidence: 0.8
learning: 3
fun: 3
kano: performance
blocked_by: []
blocks: []

_{Rated per issue-scoring · score = confidence × (capability + craft + stability + decay) / effort, derived by the picker.}

[drsnuggles8]

Slice 1 shipped in #501 — frame-rate limiter + frame-time smoothing

Done (acceptance criterion 1):

• Selectable frame cap (off / 60 / 120 / 144 / custom) via a new FramePacer (coarse sleep + short busy-spin to a target frame time). Composes with vsync (runs after SwapBuffers, no double-throttle); raises the Windows timer resolution to 1 ms while capped.
• EMA frame-time smoothing on the delta handed to layers (default off / identity).
• Application API + editor Performance-tab UI, persisted to EditorPreferences.yaml.
• 20 unit tests.

Deferred (acceptance criterion 2): "Render rate decoupled from sim tick; smooth motion at non-multiple refresh rates." — the update/render decoupling with interpolation is the large architectural piece and pairs with the #484 fixed tick (and relates to the #453 system-scheduler). Filed as a scored follow-up so this issue can track the remaining work: see the follow-up issue linked below.

Keeping this issue open until the decoupling slice lands.

[drsnuggles8]

Deferred decoupling slice filed as #502.

[drsnuggles8]

First slice delivered by #501 (merged 2026-07-01): the frame-rate limiter (off/60/120/144/custom, composes with vsync) and frame-time smoothing (EMA, default off). Worktree removed. The third listed item — update/render decoupling with interpolation (the large architectural piece, pairs with #484 fixed tick / relates to #453 scheduler) — remains; leaving this open for it.

[drsnuggles8]

Appears resolved by #501 ("Renderer: frame pacing — frame-rate limiter + frame-time smoothing (#456)", merged 2026-07-01). Flagging for closure.

[drsnuggles8]

Follow-up: the second acceptance criterion of this issue — "render rate decoupled from sim tick; smooth motion at non-multiple refresh rates" — is implemented in #579 (Closes #502). Together with slice 1 (frame-rate limiter + frame-time smoothing, shipped in #501), both acceptance criteria of #456 are now satisfied: the sim runs on the fixed timestep via the frame-delta accumulator and rendering interpolates between the last two sim states at alpha = accumulator / fixedStep, feeding the already-shipped FramePacer smoothed delta into the loop.