Thanks for this, @svabi79 — well-diagnosed and cleanly executed. The instrumentation-first approach (Principle XI) and the before/after aether.perf table make the root cause and fix easy to trust, and the per-row-frame design is genuinely more correct than the old global-reproject-on-every-pan, not just faster.

I traced the central claim through the code and it holds:

• Cost is off the pan hot path. The pan drag (SpectrumWidget.cpp:4485) and zoom drag (:4435) call only reprojectWaterfall, which now touches just the visible waterfall. The new per-row remapHistoryRowInto runs exclusively inside rebuildWaterfallViewport, reached from scrollback/resize/live-toggle paths — never from a frequency pan.
• History pixels are consumed for display only in rebuildWaterfallViewport (the other m_waterfallHistory reads are index/timestamp math), so dropping the global history reprojection is safe.
• Fast path preserved on the common case. When you scroll back in time without having panned, every row's frame equals the current frame, so remapHistoryRowInto falls into the memcpy branch — the resample only engages when a row was genuinely captured at a different center/bandwidth. Nice.
• Vectors stay consistent. The width-change scaled() branch in ensureWaterfallHistory leaves the per-row vectors intact (height unchanged, frames are frequency-domain so still valid), and the haveFrames size check plus the rowBwMhz <= 0.0 guard cover the degenerate/uninitialized cases.

Conventions and portability are fine — no QSettings/flat-key issues, RAII intact, and the extracted free functions only use QPainter/QImage/qRgb/std::memcpy already present in the TU, so no Qt-version or transitive-include risk on Linux CI. All six checks are green.

One non-blocking note: remapHistoryRowInto uses nearest-neighbour gather, consistent with the visible reproject's SmoothPixmapTransform(false), so on zoom-out scrollback older history loses some columns — but that's an inherent, acceptable trade for the perf win and matches the live path's behaviour, so no change requested.

Looks good to me. 👍

_{🤖 aethersdr-agent · cost: $2.6849 · model: claude-opus-4-8}

Well-diagnosed and cleanly executed. The instrumented root-cause split (histMs avg 108 ms vs visMs 3.3 ms) makes the fix easy to trust, and the per-row-frame design is more correct than the old global-reproject-on-every-pan, not just faster — rows captured at different centers during a fast scroll are each placed by their own frame.

Traced the implementation through:

• Fast path is correct. remapHistoryRowInto() short-circuits to memcpy when rowBwMhz ≤ 0.0 (unwritten/cleared rows) or when both frame components match the current frame (bit-identical doubles from the same member fields — valid here). If any FP epsilon difference sneaks in, the cost is one extra nearest-neighbour remap, not a wrong result.
• Remap path is correct. Nearest-neighbour gather, consistent with SmoothPixmapTransform(false) in reprojectWaterfallImage(). Out-of-bounds columns black-filled; srcX < 0.0 guard covers the negative edge before truncation.
• haveFrames guard in rebuildWaterfallViewport() is good defensive programming — if the parallel arrays ever don't match m_waterfallHistory.height(), the fallback passes current frame to both sides of remapHistoryRowInto(), triggering memcpy rather than a bad remap.
• Lifecycle coverage is complete. Arrays allocated alongside m_wfHistoryTimestamps in ensureWaterfallHistory(), stamped in appendHistoryRow(), cleared in clearDisplay() — all three sites consistent.
• reprojectWaterfallImage() extraction is a faithful refactor of the old reprojectImage lambda; logic is identical, the image.isNull() guard is promoted to the function top, and reprojectWaterfall() correctly leaves m_waterfallHistory untouched with a comment explaining why.

Two non-blocking notes for awareness:

• newStartMhz is computed early in reprojectWaterfallImage() but overlapStartMhz re-derives it inline as newCenterMhz - newBandwidthMhz / 2.0 rather than using the named variable — newStartMhz is then used correctly on the dstLeft/dstRight lines below. Cosmetically inconsistent, not a bug.
• static_cast<int>(sizeof(QRgb)) in the memcpy call is harmless (sizeof is never negative) but slightly unusual; pre-existing style carried from the old implementation.

6/6 CI green. Approved.