CapView 1.9.1
A video standard no longer travels to an input it says nothing about.
Reinitialise card
A video standard belongs to the analogue decoder, not to the card. Move between the analogue and the digital input and PAL D was left standing in the profile, where it means nothing over HDMI and pins the card to 720x576 at 50 Hz. What that looks like is a card stuck between decoder profiles after re-plugging.
There were three ways in, so there are three changes:
Changing the device forgets it. On a card whose analogue and digital inputs enumerate as separate devices, re-plugging is a device change. That path already cleared the format and the crossbar input — "format belongs to the old card" — and the standard belongs to the old card for the same reason. It was simply missing.
A source declared Digital never gets one. A card that does both still reports its analogue standards over a digital input, and that report says nothing about what is on the socket. Start now checks the signal type before applying anything.
And a button, for everything else. Reinitialise card, next to Configure card on the Source tab: releases the card, re-enumerates the device list — a re-plugged card can appear under a different path — puts the standard and the format back to automatic, and starts over.
The device and the crossbar input stay as they are. Those are decisions somebody made; the standard and the format are things CapView measured or guessed, and measurements are what a reinitialise is entitled to discard.
Confirmed on a StarTech PEXHDCAP60L: switch the card from composite to DVI, press it, and 1920x1080 at 60 is found on its own.
The crop overlay's buttons
Folded into 1.9 after it went out, and repeated here for anyone who took the first binary: dragging a crop edge over the overlay's own Apply and Cancel controls no longer turns them too dark to read. The dimming was on ImGui's foreground draw list, which is composited after every window rather than before.
Not changed, and why
The settings window can still hitch slightly while it is being dragged. That was measured this time rather than guessed at, across three drags on live hardware:
| Mouse messages during a drag | ~790 a second |
| CapView's share of the drag | 2.6 – 3.0 % |
| Time lost to gaps over 8 ms | 10.9 – 13.1 % |
| Gaps attributable to CapView | 1 of 181 |
Every one of the ten largest gaps in every drag had 0.00 ms of CapView's work immediately before it. Dragging the window clear of the preview made it slightly worse rather than better, which also rules out the composition of two overlapping windows — the explanation that had been assumed until it was measured.
There is no lever left inside CapView, so nothing was changed on a guess.