fix(windows): stop resize drags from cancelling due gpu frames

[jhodges10]

The problem

The top-level WM_SIZE handler re-arms every child surface's pending emission:

if (wparam != SIZE_MINIMIZED) {
    for (auto &view_entry : host->native_views) {
        ...
        surface.gpu_emission_scheduled = false;
        gpuSurfaceScheduleFrameEmission(host, surface);
    }
}

That exists for restore-from-minimize, and the reasoning in its comment is sound: a heartbeat-paced deadline can be parked up to a second out, so superseding it returns full cadence without dropping a beat.

But WM_SIZE also arrives on every step of a live resize drag, where the pending emission is already grid-paced and already nearly due. Re-arming it there throws away a frame that was about to fire and restarts its wait. When drag steps outpace the frame interval — which is the normal case — the deadline is repeatedly reset just before it lands, and most emissions never happen.

Measurements

165 Hz Windows desktop, dragging a canvas window for ~10 s, counters on the emission pipeline:

resize=2192  sched=6996  folded=4357  emits=445  present=215  paints=2250

• Armed deadlines: 6996 − 4357 folded = 2,639. Only 445 fired — 17%.
• 2,250 window paints against 215 presents, so roughly nine of every ten frames on screen were the previous frame stretched to the new size, not content laid out at that size.

This hides well because scaling the last good frame is a convincing stand-in; a drag looks smooth while showing mostly interpolation. It also survived a machine reboot and got worse on an idle machine (27% → 17%), which rules out interference.

The fix

Record the pacing interval a deadline was scheduled against, and supersede only a parked heartbeat one:

if (surface.gpu_emit_pace_ns <= kGpuFrameIntervalNs) continue;

The restore-from-minimize path this was written for is unchanged — a parked deadline is still superseded. A grid-paced deadline during a drag is now left to fire.

The other re-arm site (show / policy-hidden reveal) is deliberately untouched: it runs once on a real occlusion transition rather than per message, so it has no equivalent problem.

Testing

zig build is clean. zig build test shows no new failures — canvas_widget_event_tests (target-less composition keys) and three package.test DMG/service cases fail identically on unmodified main on this machine, so they are pre-existing here.

Verified against unmodified main: the same re-arm is present and the same counters reproduce, so this is independent of #323 and can land in either order. The two touch the same block and will need a trivial conflict resolution depending on which merges first.

Caveat: measured on one Windows desktop. tools/windows-truth/perf-input-desktop.ps1 would be the authoritative check and has not been run against this change.

🤖 Generated with Claude Code

[vercel]

@jhodges10 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[jhodges10]

Folding this into #323 rather than keeping it standalone.

The two changes modify the same function, and this fix's correct implementation depends on which base it sits on: against main it guards a SetTimer deadline using kGpuFrameIntervalNs; against #323's timer queue it guards a CreateTimerQueueTimer deadline using gpuSurfaceFrameIntervalNs(surface). Maintaining two mutually-conflicting versions of one fix is a standing trap, and whichever merged second would have had to be rewritten anyway.

The commit is preserved verbatim in #323 (bf4da8c2), resolved against the timer queue. Nothing is lost.