Adom Bridge

Taking this. Reviewed the patch; the diagnosis is right and the shape is the one I'd have picked.

handle_caption destroying the same-id window and sleeping 80 ms before recreating it is exactly the gap, and it contradicts what the verb's own docs promise ("same ID replaces in place"). Dispatching the new state to the existing window's UI thread and repainting is the correct fix, not a workaround.

Two changes I want to make before this ships, both in the areas you flagged for review:

1. SendMessageW has no timeout. It is a cross-thread send from the caller's blocking thread into the caption window's UI thread, and it blocks until that thread pumps. A wedged or busy caption thread would hang the calling verb with no way out. I am switching it to SendMessageTimeoutW with a bounded wait and falling back to the create path on timeout, so the worst case is one blink rather than a stuck call.

2. Two expect() calls on the state Option. expect("unconsumed caption update") and expect("caption update consumed once") are unreachable as written, but they sit on a Win32 callback path where a panic is a bad outcome. Making them graceful costs nothing.

Everything else reads correctly to me, including the ordering that matters: the repaint completes before the old fonts are deleted, and the null-GWLP_USERDATA check happens before the state is taken, so a window that died between lookup and dispatch falls through to creation instead of losing the payload.

On validation: agreed that screenshots cannot catch this, and I will not close it on a flag. I will record the screen through a burst of same-id updates and inspect consecutive frames for a blank-caption gap, plus assert HWND continuity across the burst, which is the half a video cannot prove. I will report the shipped version and the frame evidence here.

One note on your repro for the record: the 120 ms wait between calls was longer than the 80 ms sleep, so the blink you saw was not a race in your script. It was the implementation doing what it was written to do.

Shipped in 2.1.115 (insiders). Your patch is in, with the two changes I flagged above.

Frame-level evidence

Same harness both times on arav-rog: 18 same-id desktop_caption updates, 120 ms apart (your cadence), screen recorded at 30 fps, then every frame measured for caption ink inside the caption band.

The blink, caught: three consecutive frames, continuity 00 then bare wallpaper then continuity 01. Left is before, right is after at the same point in the burst.

(Left: before. Right: after, same point in the burst.)

One note on method, because it nearly produced a false pass. My first detector compared each frame against the run's median ink and found zero gaps on the build that definitely has the bug. The reason is that the caption text changes on every update, so ink legitimately moves frame to frame, and a fixed threshold cannot tell "text got shorter" from "caption disappeared". The detector now compares each frame only against its two immediate neighbours, where a blink is unmistakable: the measured signature is 385 -> 111 -> 361 in adjacent frames. I only trusted it after it found the bug on the old build first. A detector that has never seen the defect is not evidence of its absence.

The HWND count is the half a video cannot show, and it is the cleaner signal: 18 windows for 18 updates before, 1 after.

What changed relative to your patch

• SendMessageW -> SendMessageTimeoutW with SMTO_ABORTIFHUNG and a 750 ms bound, falling back to the create path. A cross-thread send blocks until the target pumps, so a wedged caption thread would have hung the calling verb with no way out. With the bound, the worst case degrades to the old behaviour (one blink) rather than a stuck call.
• The two expect() calls now fall through to creation. Both were unreachable as written, but a panic unwinding through a Win32 callback is undefined behaviour, and returning LRESULT(0) costs one blink instead.

Everything else is yours, including the ordering that matters: the repaint completes before the old fonts are freed, and the null-GWLP_USERDATA check precedes taking the payload, so a window that dies between lookup and dispatch falls through to creation instead of losing it.

Also worth recording: your 120 ms wait was longer than the 80 ms sleep, so the blink was not a race in your script. It was the implementation doing exactly what it was written to do.

tests/caption-update/ is committed as you sent it.