perf(canvas): smooth zooming - compositor-synced frames, fixed measurement contract (DasherCore v0.2.5)

[willwade]

Summary

v0.1.17 user report (#35): "The zooming is very choppy... stuttering and robotic... happens in both standard mode and Direct Mode... the stuttering actually gets worse when going slow."

Instrumented the frame loop first. The ABI layer is exonerated — engine avg 0.33 ms, command-buffer marshal avg 0.01 ms per frame. What the numbers showed instead, and the fixes:

1. Frame pacing (the choppiness)

The engine was driven by a free-running 16 ms DispatcherTimer (Background priority) while presentation ran on the compositor's clock. Measured: ~26 ms average tick spacing, p95 32 ms, spikes to 64 ms, ~38 fps, with skipped/doubled updates as the two clocks beat against each other — classic judder, proportionally more visible at slow zoom (small per-frame movement makes timing error dominate).

• Drive the engine from TopLevel.RequestAnimationFrame (compositor frame clock — same approach as GTK's frame clock / Android's Choreographer). After: frames == renders, locked 1:1, zero skips.
• Feed the engine a clamped monotonic timeline (deltas capped at 50 ms) instead of wall-clock UtcNow sampled at each tick — the engine consumes raw deltas as zoom amount, so pause gaps (settings open) no longer inject multi-second jumps; ResumeTimer drops the wall-clock baseline likewise.

2. Text-measurement contract (v0.1.17 regression from #33)

Our OnTextSize returned 1 on success / 0 on failure — inverted against dasher.h ("fill out_width/out_height and return 0; return non-zero to fall back"). The engine therefore never accepted our measurements (the .17 squashing fix users saw was actually DasherCore v0.2.4's codepoint-count correction) and never cached anything, re-calling the callback ~21×/frame ≈ 2,500 FormattedText constructions per second. After the fix: textcb 2520 → 0 per 120-frame window once warm. Plus a frontend-side measurement cache for fresh labels.

3. Allocations (GC pressure)

• CommandRenderer now caches brushes, pens and FormattedText objects (was: one allocation per command, hundreds per frame).
• Command/string buffers reused across frames (was: fresh int[] + string[] every frame).
• SP_DASHER_FONT polled every 250 ms instead of every frame (was a P/Invoke + string alloc per frame).

4. DasherCore submodule v0.2.4 → v0.2.5

Picks up DasherCore #58 (probe call of dasher_get_parameter_string_values returned 0 before querying — found via Dasher-GTK). The settings string dropdowns now use probe-then-fetch, so the full alphabet list (622 entries) is no longer silently truncated by the old fixed 200-slot buffer.

Measurements (before → after, same machine, 120-frame windows)

metric	before	after
engine tick spacing	avg 26 ms, p95 32, max 64	locked to compositor cadence, 1:1 with renders
engine step	0.33 ms avg	0.13 ms avg
render	0.38 ms avg	0.34 ms avg
text-size callbacks	2,520/window (never cached)	0/window warm
skipped/doubled updates	renders 91-109 per 120 ticks	frames == renders exactly

(Note: absolute cadence in the capture environment is ~30 fps over RDP; on a 60 Hz desktop RAF tracks 60. The 1:1 lock and jitter removal are the fix, not the absolute rate.)

Issue / RFC: #35 (this issue), #28 (measurement-contract regression), DasherCore #58

Type of change

• Bug fix
• New feature
• Cross-platform / parity change (aligns Windows frame driving with GTK frame-clock / Android Choreographer practice; other frontends may want the same probe-then-fetch for Direct mode: every Enter resets the canvas; Outlook unusable (Word fine) — self-caused UIA selection-change re-seed loop #58)

Cross-platform impact

• This changes a capability that users see on other platforms.
• This introduces a new UX or hardware interaction.

Manual verification (RFC 0011)

• Build green 0 warnings; suite 43/43
• Instrumented before/after runs (numbers above)
• Smoke run: app launches, canvas renders, engine fault-free
• User acceptance: the reporter's slow-zoom pass in both standard and Direct Mode (her acceptance test)
• Font change while zooming still invalidates measurement correctly (250 ms poll)

Definition of Done

• CI is green
• Tests added for new behaviour (pacing/RAF is UI-thread plumbing, measured manually per RFC 0011; conversion logic unchanged)
• Feature matrix updated (n/a — correctness/perf fix)
• Docs updated (measurements documented here; DasherCore Direct mode: every Enter resets the canvas; Outlook unusable (Word fine) — self-caused UIA selection-change re-seed loop #58 noted)
• Commits are signed off (DCO)

Fixes #35

Greptile Summary

The PR replaces timer-driven canvas updates with compositor-synchronized frames, corrects text measurement semantics, and reduces steady-state rendering allocations.

• Adds generation-guarded animation-frame scheduling with a bounded monotonic engine timeline.
• Reuses native command and string buffers and caches rendering and text-measurement objects.
• Changes settings enumeration to probe and allocate the required result capacity.
• Updates DasherCore from v0.2.4 to v0.2.5.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/Dasher.Windows/Controls/DasherCanvas.cs	Replaces the dispatcher frame timer with generation-guarded compositor callbacks, introduces a bounded engine timeline, fixes the text-measurement callback contract, and reuses frame buffers.
src/Dasher.Windows/Controls/SettingsPanel.cs	Replaces the fixed-capacity string-value query with probe-then-fetch enumeration.
src/Dasher.Windows/Engine/CommandRenderer.cs	Adds bounded caches for brushes, pens, typefaces, and formatted text while rendering only the populated portions of reusable buffers.
DasherCore	Advances the submodule from v0.2.4 to v0.2.5; the referenced submodule commits were unavailable locally for direct source-level analysis.

Sequence Diagram

sequenceDiagram
    participant Settings
    participant Canvas
    participant Compositor
    participant Engine
    Settings->>Canvas: Shutdown()
    Canvas->>Canvas: Stop loop and increment generation
    Settings->>Canvas: Initialize() and StartEngine()
    Canvas->>Canvas: Increment and capture new generation
    Canvas->>Compositor: RequestAnimationFrame(new generation)
    Compositor-->>Canvas: Old queued callback
    Canvas->>Canvas: Reject stale generation
    Compositor-->>Canvas: Current callback
    Canvas->>Engine: StepFrame()
    Canvas->>Compositor: Request next frame

Loading

_{Reviews (2): Last reviewed commit: "fix(canvas): generation-guard the RAF lo..." | Re-trigger Greptile}