v0.26.3

What changed and why

CvDispCtrl refits the moment its size changes — it no longer waits for the next frame.

On a screen where frames are rare (a monitoring display, a stopped line), resizing the window left the
picture at the old scale until the next frame arrived: margins when the window grew, cropping when it
shrank. It was reported from a production display — a borderless full-screen window whose monitor was
unplugged and plugged back in. Live views hid it because the next frame refitted within milliseconds.

The display surface reserved a refit when its size changed but did not ask to be redrawn. WPF draws a
resized element during arrange and delivers the size-change notification only after layout finishes
(checked against the WPF 8.0.31 runtime source), so the reservation always arrived after the draw and
sat there until something else drew.

The same cause had a second symptom: whatever drew next consumed the reservation — including the
first mouse-wheel zoom after a resize, which snapped back to fit instead of zooming.

Measured with a 1000×500 frame and no new frame after the resize:

	0.26.2	0.26.3	fit at the new size
grow 800 → 1400 px wide	776 px (old scale)	1126 px	1126 px
shrink 1400 → 800 px wide	663 px (old scale, right side cropped)	776 px	776 px
one wheel notch out after growing	1126 px (zoom lost — the picture got larger)	901 px (= 1126 / 1.25)	—

The regression ResizeRefitsWithoutANewFrame covers both directions; it fails on 0.26.2 and passes here.

If your host worked around this: invalidating the display from a parent SizeChanged handler does
not help — size notifications go to the outermost element first, and when a handler requests a redraw
WPF stops delivering them and re-runs layout, so the surface redraws before its own reservation exists.
Deferring the invalidation to Loaded priority does work. Such a workaround stays harmless on 0.26.3
(measured by a consumer) and can be removed.

Behaviour change to be aware of. Resizing always meant "refit"; what changes is when. Before, the
refit waited for the next draw, so a manual zoom survived a resize until the next frame or interaction.
Now, if the display area changes size — a side panel collapses, a banner appears above the display,
the toolbar is toggled — a manual zoom returns to fit immediately. Hiding and showing the control (a tab
switch, a collapsed parent) is not a resize: the zoom is kept unless the size changed while it was hidden.

Also

• GevCam logs discarded N queued frame(s) up to frame M before grabbing a fresh one at Info
  instead of Debug. It is written when a single grab finds leftover frames in the queue and drops them
  before starting — the situation 0.26.1 failed in — so a successful grab right after that line shows
  the 0.26.2 fix holding. At Debug it never reached a file log filtered at Info, and a field check could
  not tell "met the situation and passed" from "never met it". It shows up mostly on the first single
  grab after live view was stopped, and not on every such grab (the stop itself usually clears the
  queue). Two limits: frames that arrive after the drain and are rejected by the start-line check are
  still dropped without a log line, so a missing line does not prove nothing stale was met; and the
  similar line written when continuous acquisition stops (… left in the queue when acquisition stopped)
  stays at Debug.
• Comments in GevCam were corrected where they overstated: the stale-frame fix of 0.26.2 relies on
  the device clock, and on a camera that provides no clock (grabKey=frameId in the open log) and
  restarts its frame numbers, the 0.26.1 failure path is still open; which layer rejects an off-grid
  exposure; when an exposure read-back can be an echo of the value written. No code change.
• CvInspect.Wpf README: the Frame row now says a resize refits and replaces a manual zoom.

Version

0.26.3 — patch. No public API change: one display defect fix, one log-level change, comments.

Checks

• dotnet build CvInspect.sln -c Release --no-incremental reports 0 warnings
• main is an ancestor of this branch (the release-pr-guard job verifies it)
• the tag will be created on the merge commit, main merged back into dev afterwards, and dev bumped to the next -dev version