fix(spectrum): spot display setters use update() instead of markOverlayDirty() (#3338)#3411
Conversation
…ayDirty() (aethersdr#3338) The 9 spot-display setters in SpectrumWidget.h call update(), which on the GPU path reuses the cached m_overlayStatic chrome texture without re-baking it. drawSpotMarkers() never re-runs, so toggling Spot Lines (or changing spot font size, start %, colors, etc.) has no immediate visual effect — the change only takes hold when something else causes markOverlayDirty() to fire (e.g. a new incoming spot). Root cause: GPU chrome overlay caching was introduced in aethersdr#3124. The spot setters pre-date that change and were never updated to use the correct invalidation primitive. Regression became consistently visible after aethersdr#3299 (discrete GPU preference on Windows hybrid laptops) caused more users to run the GPU path. Fix: replace update() with markOverlayDirty() in all 9 setters. markOverlayDirty() calls update() internally, so CPU-path behaviour is identical. On the GPU path it additionally sets m_overlayStaticDirty so the next paint re-bakes the chrome texture. All other display setters in the file (background opacity, MQTT display, prop forecast, etc.) already use markOverlayDirty() — the spot setters were the only outliers. Fixes aethersdr#3338
There was a problem hiding this comment.
Verified the fix against SpectrumWidget.h — markOverlayDirty() (line 1064) sets m_overlayStaticDirty = true under AETHER_GPU_SPECTRUM and then calls update(), so the change is a strict superset of the prior behaviour: CPU path unchanged, GPU path now correctly re-bakes the chrome overlay so drawSpotMarkers() re-runs.
Diff is exactly what the description claims — all 9 spot setters now match the convention used by the surrounding setBackgroundOpacity, setPropForecastVisible, MQTT, etc. setters in the same file (lines 221, 232, 234, 260). No other behavioural changes, no scope creep.
Looks good — thanks for the careful root-cause analysis (#3124 → #3299 regression chain) and for keeping the patch minimal. Visual confirmation on a Windows discrete-GPU box from the #3338 reporter would be the last thing to lock this in.
🤖 aethersdr-agent · cost: $9.1168 · model: claude-opus-4-7
NF0T
left a comment
There was a problem hiding this comment.
Correct fix for the right reason, @M7HNF-Ian. Verified markOverlayDirty() at line 1064 — it sets m_overlayStaticDirty = true then calls update(), making it a strict superset of the prior behaviour: CPU path unchanged, GPU path correctly re-bakes the chrome overlay so drawSpotMarkers() runs with the new setter values. All 9 spot setters now match the convention used by setBackgroundOpacity, setPropForecastVisible, and the MQTT display setters in the same file.
The regression chain (#3124 → #3299) is well-documented and the fix is logically sound. Worth noting there are a handful of other setters in the file (setShowBandPlan, setShowSpots, setShowSHistory, etc.) still using update() that might warrant the same treatment in a follow-on pass — but that's a separate scope.
All 5 CI checks green.
73,
Ryan NF0T
…ayDirty() (aethersdr#3338) (aethersdr#3411) ## Problem The 9 spot-display setters in `SpectrumWidget.h` call `update()`, which on the GPU path reuses the cached `m_overlayStatic` chrome texture without re-baking it. `drawSpotMarkers()` never re-runs, so toggling **Spot Lines** (or changing spot font size, start %, colours, etc.) has no immediate visual effect — the change only takes hold when something else triggers `markOverlayDirty()` (e.g. a new incoming spot). This regression was introduced by aethersdr#3124 (GPU path caches the chrome overlay) and became consistently visible after aethersdr#3299 (discrete GPU preference on Windows) caused more users to hit the GPU path. ## Fix Replace `update()` with `markOverlayDirty()` in all 9 setters. `markOverlayDirty()` calls `update()` internally — identical behaviour on the CPU path, correct invalidation on the GPU path. All other display setters in the file (background opacity, MQTT display, prop forecast, etc.) already use `markOverlayDirty()`. The spot setters were the only outliers. ## Testing Verified build compiles cleanly on macOS. GPU-path visual verification (toggle Spot Lines with spots visible → lines appear/disappear immediately) requires Windows with discrete GPU — the reporter in aethersdr#3338 should be able to confirm. Fixes aethersdr#3338
Problem
The 9 spot-display setters in
SpectrumWidget.hcallupdate(), which on the GPU path reuses the cachedm_overlayStaticchrome texture without re-baking it.drawSpotMarkers()never re-runs, so toggling Spot Lines (or changing spot font size, start %, colours, etc.) has no immediate visual effect — the change only takes hold when something else triggersmarkOverlayDirty()(e.g. a new incoming spot).This regression was introduced by #3124 (GPU path caches the chrome overlay) and became consistently visible after #3299 (discrete GPU preference on Windows) caused more users to hit the GPU path.
Fix
Replace
update()withmarkOverlayDirty()in all 9 setters.markOverlayDirty()callsupdate()internally — identical behaviour on the CPU path, correct invalidation on the GPU path.All other display setters in the file (background opacity, MQTT display, prop forecast, etc.) already use
markOverlayDirty(). The spot setters were the only outliers.Testing
Verified build compiles cleanly on macOS. GPU-path visual verification (toggle Spot Lines with spots visible → lines appear/disappear immediately) requires Windows with discrete GPU — the reporter in #3338 should be able to confirm.
Fixes #3338