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

[jhodges10]

Six commits that make a Windows canvas actually receive frames while its bounds are changing, and get those frames onto the glass. 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.

Rebased onto main at v0.9.3.

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.

A rendered frame then waited on WM_PAINT that never came. Presenting a packet invalidated the surface and left the blit to WM_PAINT, which Windows synthesizes only once the message queue drains — which is exactly what a resize prevents. On a 20-surface app, 4,570 renders reached the glass 338 times: the rest were correct frames overwritten before anyone saw them. This is the other half of "some panels resize live, others wait for the mouse", and it survives every scheduling fix above, because the frame was emitted and was rendered.

And the relayout rebuilt Z-order on every view, every step. native_sdk_windows_update_view reordered the window's whole child stack whenever a layer was supplied, not when it changed — and a shell relayout supplies one per view per WM_SIZE. Measured at ~300 SetWindowPos calls per resize step, rebuilding an order that already existed, and the single dominant cost of a live resize.

The commits

a1ffe867	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.
c518b0dc	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.
e5b5058f	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.
53530d43	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.
6cbb6798	Rebuild child Z-order only when a layer actually changes. A supplied layer is not a changed layer.
2abc44ad	UpdateWindow the surface after a present that rendered, so the blit happens now instead of waiting for a WM_PAINT the resize is starving.

The last two are new since the previous revision of this PR, and are the reason a resize now reaches the screen rather than merely being scheduled.

Results

Same 20-surface application, 240-step driven sweep, before → after the two new commits:

	before	after
resize step	~51 ms	~3.7 ms
sustained rate	14.8 Hz	~260 Hz (210–299 across runs)
SetWindowPos p50	—	3.5 ms
renders that never reached the glass	92.6%	0%

Read a single sweep as noise: the same binary measured six times in one sitting ranged 210–299 Hz. Only interleaved medians mean anything on this workload.

Validation

Full suite on Windows, against pristine main at the same commit as the control:

	steps	tests	failed
main b25cefe	478/481	3277/3333	4
this branch	478/481	3278/3334	4 — identical set

Net +1 passing test, no new failures. The four are pre-existing on main on a Windows host; two of them are macOS DMG packaging tests that cannot pass there at all.

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.

Not included

The instrumentation that found the last two commits is absent from both this PR and #330, because it needs a piece of each: a wmsize profile line splitting a resize step into the synchronous runtime callback, the WebView2 frame apply, and host work, plus how many view frames the relayout touched and how many actually moved a window. It writes through a seam into #330's GpuProfileLog, and it instruments the WM_SIZE handler this PR rewrites — so it cannot compile against either branch alone. Happy to send it as a follow-up once both land.

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