HC_APTBS/docs/gotcha-pump-change-ui-jank.md

Gotcha: OnPumpChanged UI-thread jank — deferred fixes

Status

Deferred. These two issues cause a small but measurable hitch on the UI thread during manual pump selection. For pumps without an immobilizer unlocker the jank is not perceptible enough to justify the work. Document kept so the cost is understood if we ever need to address it (e.g. if disk I/O gets slower, pump catalogs grow, or the jank stacks with a future UI change).

The separate unlocker-pump delay issue was fixed independently by making the unlock state observer event-driven via CanBusParameter.ValueChanged.

Issue 1 — ConfigurationService.LoadPumpStatus does disk I/O on the UI thread

Symptom

On pump change, up to ~20–200 ms of UI thread blocking (worst case on cold cache or spinning disk) before OnPumpChanged returns. Two XML parses per pump change.

Why it happens

MainViewModel.OnPumpChanged calls _config.LoadPumpStatus(...) twice (once for the Status word, once for Empf3) while building the status displays. LoadPumpStatus caches by statusId, but on pump switch the new pump usually carries a different Type, so both lookups miss and trigger XDocument.Load(StatusXml) — a full file read plus XML parse. Runs synchronously on the UI thread.

Fix (when needed)

Preload every <PumpStatus> entry into _statusCache during ConfigurationService construction (or app bootstrap). The file is small and status definitions never change at runtime. After that, LoadPumpStatus degenerates to a pure dictionary lookup and disk I/O is gone from the pump-change path.

Alternative (smaller change, slower fix): wrap both calls in Task.Run and apply results via Dispatcher.InvokeAsync. PumpStatusDefinition is a plain POCO, so it's safe to construct off-thread.

Issue 2 — TestPanelViewModel.LoadAllTests allocation burst on the UI thread

Symptom

~5–30 ms synchronous burst on pump change while the test panel is rebuilt. On slower machines or pumps with many tests the operator sees a visible hitch between clicking the pump and the page settling.

Why it happens

LoadAllTests clears the Tests collection and synchronously creates one TestSectionViewModel per test definition, each spawning child PhaseCardViewModel and GraphicIndicatorViewModel instances. For a typical pump that's ~100+ view models constructed in a single tight loop, each raising INotifyPropertyChanged setters. The ObservableCollection.Add calls also dispatch CollectionChanged synchronously through any ItemsControl already bound to Tests.

Fix (when needed)

In OnPumpChanged, yield before LoadAllTests so the already-queued render frame commits first:

// ...all the lightweight synchronous bookkeeping (senders, CAN param swap,
// slider gate, unlock startup)...

// Let the frame with the slider-enable + pump-name update paint before
// we do the heavy test-panel rebuild.
await Dispatcher.Yield(DispatcherPriority.Background);
TestPanel.LoadAllTests(pump);

This turns OnPumpChanged into an async void handler — acceptable here because the caller is the SelectedPump partial-method hook which does not observe the returned Task. Operator sees the slider gate open and the unlock dialog appear instantly; the test panel fills in on the next dispatcher tick.

Alternative: keep OnPumpChanged synchronous and wrap only the rebuild in Dispatcher.BeginInvoke(..., DispatcherPriority.Background). Same effect; easier to keep the void signature.

Why we're not fixing these now

• Non-unlocker pumps: the combined ~25–230 ms worst case is absorbed by the operator's own reaction time after clicking the pump. Not flagged as a UX problem in field use.
• Unlocker pumps: the original 1 s unlock-dialog delay was the dominant visible symptom. That was fixed by the event-driven observer — the remaining jank from issues 1 and 2 sits under the noise floor of the unlock dialog appearing.

Revisit if:

• Pump catalogs grow to the point that LoadAllTests crosses the ~50 ms mark
• status.xml grows (new status types) or storage latency regresses
• Any future UI change on DashboardPage / PumpPage makes the pump-change transition visually tighter and exposes the hitch

Files involved

• ViewModels/MainViewModel.cs — OnPumpChanged (lines 391–470)
• Services/Impl/ConfigurationService.cs — LoadPumpStatus (lines 364–435)
• ViewModels/TestPanelViewModel.cs — LoadAllTests (lines 110–125)