fix(windows): make a resize deliver frames at the new size

[jhodges10]

Four commits that make a Windows canvas actually receive frames while its bounds are changing. Host-side only — webview2_host.cpp, its source pins, and four lines of build/app.zig; no renderer files — so it can land independently of the flip-model migration in #330, which it was previously sitting behind.

Absorbs #324 (now closed): that fix's correct shape depends on whether the timer queue is present, so keeping it as a separate PR meant maintaining two conflicting versions of it.

What was wrong

A geometry change was not a reason to draw. Emissions are scheduled by input, by animation, and by explicit frame requests. The top-level WM_SIZE handler re-arms child surfaces, but only ones that already had an emission pending — so a panel that happened to be idle when the window (or a dock divider) moved never got a frame event carrying its new size. It kept presenting the packet it rendered for the old bounds until the pointer wandered in and woke it for something unrelated. On a 20-surface app, of the seven panels whose bounds moved in a divider drag, one re-rendered and six waited. Which panels fall on which side is pure accident of what happened to be animating.

That same re-arm cancels frames during a drag. It exists for restore-from-minimize, where a heartbeat-paced deadline can be parked up to a second out and superseding it returns full cadence. But WM_SIZE also arrives on every step of a live resize, where the pending emission is already grid-paced and already nearly due — re-arming there discards a frame that was about to fire and restarts its wait. Measured on a 165 Hz desktop over a ~10 s drag: 2,639 deadlines armed, 445 fired (17%). The window painted 2,250 times against 215 presents, so roughly nine of every ten frames on screen were the previous frame stretched to the new size. It hides well, because a scaled last-good frame is a convincing stand-in for a laid-out one.

And the deadline itself was coarse. A nominal 16.67 ms SetTimer is commonly rounded to the legacy timer grid, and WM_TIMER is only generated after higher-priority input has drained — so a high-rate trackpad or wheel could hold a due frame pending for hundreds of milliseconds.

The commits

672f682e	Arm emissions with CreateTimerQueueTimer and deliver them as a posted kGpuEmitMessage, with a process-owned high-resolution waitable timer following the earliest deadline. A generation counter fences a re-arm against a callback already in flight.
2976afbb	Re-point two source pins at that shape. Without this the commit above fails its own tests — they still asserted KillTimer(hwnd, kGpuEmitTimerId); and if (wparam == kGpuEmitTimerId), neither of which survives the change.
bf4da8c2	Record which cadence a deadline was placed on, and supersede only a parked heartbeat one. The show/policy-hidden re-arm is deliberately untouched: it runs once on a real occlusion transition, not once per message.
43f4d06f	Schedule from the surface's own WM_SIZE, with a forced full repaint — the runtime plans an idle frame for an unchanged scene, and a resize changes the viewport, not the scene. Gated on the geometry actually changing, so a stream of WM_SIZE cannot hold a full-rate loop open.

Validation

zig build test-desktop-platform — 210 pass, 1 skip, 0 fail on this branch standalone.

Worth stating plainly: this is not observable on the SDK's own examples. They are single-surface and light enough that the old scheduling kept up; the numbers above come from a 20-surface application. tools/gpu-image-fixture (added in #330) does not help here either — it prices texture-cache cost, not frame scheduling.

🤖 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.

[vercel]

Additional Suggestion:

Pointer button up/down events are emitted immediately while queued (coalesced) pointer motion/scroll is only flushed on the next frame, so a fast click-drag-release within one frame delivers a stale drag/move sample AFTER the pointer-up/down.