CapView 1.6.2

Bugfix release. The settings-as-a-window stutter, measured rather than reasoned about.

Three separate causes, in the order the measurements found them. The dialog's present cost 12–17 ms and up to 41, about thirty-five times a second — better than half of every second with the thread that owns both windows parked and not pumping messages, which is why the desktop's cursor stuttered. A flip-model swapchain with sync interval zero and no tearing flag still waits, whatever the comment in the code claimed. Then SetMaximumFrameLatency(1) — what makes the preview's latency as short as it is — applies to the device, so two swapchains sharing one frame of queue each waited for the other. And the preview redrew on every wake-up of the message loop: the whole pipeline ran 235 times a second for a source delivering 25.

Dragging the window froze the preview for up to 1.24 seconds. Windows' modal move loop does not return until the mouse is released. There was a timer meant to cover that; measuring showed it firing 7 times a second instead of 125, because WM_TIMER is the lowest-priority message there is and a drag never leaves the queue empty. It hangs off WM_MOVING now, and the preview runs at better than 30/s through a drag at 0.6 ms a frame.

What is left is not CapView's: dragging the dialog across the preview still hitches, because two overlapping windows must be composed together and one is repainting thirty times a second. Off the preview it is smooth.

Also: the open tab survives moving the settings between the preview and their own window; "What is new" opens the release page; and checking for updates by hand no longer raises the startup popup.