Skip to content

fix(spectrum): FFT line width slider produces visible pixel-width line (#2705). Principle III.#2706

Merged
aethersdr-agent[bot] merged 1 commit into
mainfrom
aetherclaude/issue-2705
May 16, 2026
Merged

fix(spectrum): FFT line width slider produces visible pixel-width line (#2705). Principle III.#2706
aethersdr-agent[bot] merged 1 commit into
mainfrom
aetherclaude/issue-2705

Conversation

@aethersdr-agent

Copy link
Copy Markdown
Contributor

Summary

Fixes #2705

What was changed

fix(spectrum): FFT line width slider produces visible pixel-width line (#2705). Principle III.

Files modified

  • src/gui/SpectrumWidget.cpp
 src/gui/SpectrumWidget.cpp | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

Generated by AetherClaude (automated agent for AetherSDR)

#2705). Principle III.

The GPU triangle-strip line in SpectrumWidget computed its perpendicular
normal half-width in NDC X units only (`m_fftLineWidth / width()`). The
FFT trace is predominantly horizontal between adjacent bins, so the
perpendicular normal almost always points in the Y direction. The
spectrum viewport is `width × specH`, so the effective Y offset in screen
pixels was `m_fftLineWidth * specH / (2 * width())` — a fraction of a
pixel for any wide-screen panadapter (e.g. ~0.39 px at slider max on a
1920×300 viewport). The fill gradient drew right up to the line's
vertex Y, masking the missing line and making the slider appear inert
across all platforms.

Compute the normal in pixel space using both viewport dimensions
(`wPx`, `hPx = specH`), scale by `m_fftLineWidth`, then convert back to
NDC per-axis. The slider's numeric label is now a true pixel
measurement, honoring the user-visible label per Principle III.

Blast radius: hook reported risk_score=0.334 with 11 high-risk callers
(MainWindow::buildUI, wirePanadapter, etc.) — all reach SpectrumWidget
only through its public interface, which is unchanged. Edit is local
vertex-math arithmetic inside one block of `renderGpuFrame`; no
signature, member, or observable behavior change beyond the slider
acting as labeled.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@aethersdr-agent aethersdr-agent Bot requested a review from ten9876 as a code owner May 16, 2026 00:56
@aethersdr-agent aethersdr-agent Bot enabled auto-merge (squash) May 16, 2026 00:56
@aethersdr-agent aethersdr-agent Bot requested a review from jensenpat as a code owner May 16, 2026 00:56

@jensenpat jensenpat left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and working on macOS.

@aethersdr-agent aethersdr-agent Bot merged commit 44163fc into main May 16, 2026
4 checks passed
@aethersdr-agent aethersdr-agent Bot deleted the aetherclaude/issue-2705 branch May 16, 2026 01:04
aethersdr-agent Bot added a commit that referenced this pull request May 18, 2026
…nciple III.

The earlier fix in 44163fc (PR #2706) for issue #2705 patched only the
QRhi/GPU render path in renderGpuFrame(). The parallel software path
in drawSpectrum() hardcoded a 1.5 px pen and ignored m_fftLineWidth,
so the Display → "FFT Line:" slider was a no-op for any user whose
build lacked GPU acceleration (e.g., Windows builds where the
AETHER_GPU_SPECTRUM CMake block was disabled because Qt6GuiPrivate was
not found at configure time — confirmed in support-bundle-20260516-005340
which contains neither the QRhi success nor failure log line).

Fix in src/gui/SpectrumWidget.cpp::drawSpectrum:
- Use m_fftLineWidth on a cosmetic QPen so the requested pixel width
  survives high-DPI scaling on Windows.
- Skip the line draw entirely when m_fftLineWidth <= 0 ("Off"),
  mirroring the GPU path's behavior at L5065.
- Apply to both the heat-map and solid-fill branches.

Also call update() from setFftLineWidth() so the slider takes effect
immediately even when no FFT stream is flowing (matches the pattern in
setFftFillAlpha / setFftFillColor that already call markOverlayDirty()).

Honors Principle III: the UI label "FFT Line:" on the Display menu is
the user-facing contract; making the slider inert on one of two render
paths breaks that contract.

Blast radius: risk_score=0.310, 10 high-risk affected (top:
MainWindow::MainWindow, MainWindow::wirePanadapter, MainWindow::buildUI).
The seed change is internal to drawSpectrum's rendering branch and
setFftLineWidth's repaint trigger; the high-risk callers depend on
SpectrumWidget instantiation/wiring, not on the rendering details
modified here, so the wide reported surface does not reflect actual
behavioral reach.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FFT line slider has no effect on Windows 11

1 participant