Thanks for the careful work on this — the diff is well-organized, the lcPerf category is reused (rather than introducing a new one), aether.perf gating keeps the cost near zero when disabled, AppSettings is used (not QSettings), and the RAII PerfInputScope / PerfUpdateScope / ScopeExit helpers are the right shape. The signal-signature change for spectrumReady / waterfallRowReady looks complete — all three connection points in MainWindow.cpp accept the new qint64 emittedNs.

A few small things worth a look:

1. Ctrl+F collides with Find conventions

MainWindow.cpp:6577 binds the FPS Meters toggle to Ctrl+F, but Ctrl+F (QKeySequence::Find) is already used as window-scoped Find in MemoryDialog.cpp:331 and HelpDialog.cpp, and it's the cross-platform OS convention. While dialog-scoped shortcuts will win when those dialogs are focused, users will likely hit Ctrl+F in the main window expecting search behavior and toggle FPS instead. Suggest Ctrl+Shift+F, Ctrl+Alt+F, or a dedicated F-key — purely advisory, not a bug.

2. Redundant FPS-meter broadcast / settings write

MainWindow.cpp:6580 already iterates all panadapter applets and calls sw->setShowFpsMeters(on) for each. SpectrumWidget::setShowFpsMeters (line ~531) then also writes DisplayFpsMeters to AppSettings and re-broadcasts to findChildren<SpectrumWidget*>() siblings on the top-level window. With N panadapters that's N redundant AppSettings saves and O(N²) applyFpsMeterVisibility calls. Not buggy, but I'd suggest having MainWindow call applyFpsMeterVisibility directly (or letting setShowFpsMeters do the broadcast and just calling it once on any one widget). The single-write path is cleaner and avoids the AppSettings save thrash.

3. setShowFpsMeters AppSettings key is not pan-scoped

Most other display keys in this widget use settingsKey(...) to namespace per pan (e.g. DisplayShowGrid, DisplayFftHeatMap), but DisplayFpsMeters is global. That's actually consistent with the "global FPS meter" intent and the menu wiring in MainWindow, but it's worth a code comment explaining why this one bypasses settingsKey() so future readers don't try to "fix" the inconsistency.

Otherwise the implementation looks solid — beginRecord correctly gates the cold path with m_wasEnabled.exchange() and the per-window reset, percentile/stall thresholds are reasonable, and the frame-restart detection in decodeFFT/decodeWaterfallTile correctly checks frame.totalBins > 0 && !frame.isComplete() to avoid false positives on first frame. Nice work.