Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

When running AetherSDR natively on Wayland (XDG_SESSION_TYPE=wayland and QT_QPA_PLATFORM=wayland) under Ubuntu 26.04, dragging or panning the spectrum display within the SpectrumWidget causes severe UI unresponsiveness lasting several seconds or longer. During this freeze, waterfall/FFT rendering stops, visual controls lock up, and the application fails to process incoming network payloads smoothly.

The root cause is that high-polling-rate mouse motion events completely overwhelm SpectrumWidget::mouseMoveEvent. Because SpectrumWidget::mouseMoveEvent processes every single event, the main event loop becomes hopelessly backlogged with a massive queue of raw motion deltas.

This issue is mitigated when forcing the application to use XWayland (QT_QPA_PLATFORM=xcb) or when running via the AppImage -- which likely falls back to XWayland. However, this mitigation is an implementation-specific coincidence of XWayland's translation overhead rather than a protocol guarantee. This could be an issue, present or future, on Mac or Windows as well.

Radio model & firmware

• Radio: FLEX-8600
• Firmware: 4.1.5.39794

OS & version

• OS: Ubuntu 26.04 LTS (Wayland Session)
• AetherSDR Version: 26.6.1.1
• Qt Version: 6.10.2

Developer Notes

1. Technical Analysis of the Bottleneck

Neither the Wayland/X11 protocols nor Qt's QPA make any API guarantees regarding the delivery frequency or automatic compression of pointer motion events. Wayland compositors routinely pass raw libinput events directly to the client at the hardware's native polling rate (often 500Hz to 1000Hz on modern devices).

Currently, during a drag, SpectrumWidget::mouseMoveEvent processes every single one of these back-to-back events. Within each invocation, the widget performs offset/rescaling calculations, triggers asynchronous packet composition via RadioModel::sendCmd, and calls update().

While RadioModel::sendCmd's invocation of RadioConnection::writeCommand is non-blocking/asynchronous, the cumulative CPU overhead of executing the coordinate math, state changes, and dispatch setup for every single mouse tick is high enough. Because update() enqueues a QEvent::UpdateRequest onto the back of the Qt event loop, the paint request gets stuck waiting behind the wall of uncompressed mouse motion events still sitting in the queue. The main thread spends 100% of its execution time burning through mouse deltas, starving the UI thread of the opportunity to process the actual paint events.

2. Suggested Solution Architecture

To resolve this permanently across all platform configurations, SpectrumWidget needs an application-side event throttling mechanism: Submitter's Note (jbettik): This is a general starting direction. There's variations on how this could be done, and details regarding the refresh rate, and the network communication that need to be analyzed.

• Event Accumulation: mouseMoveEvent should be modified to simply cache the latest cursor coordinates during a drag and start/restart a low-latency single-shot timer (e.g., a QTimer set to roughly 16ms to target 60Hz, or 33ms for 30Hz processing).
• Decoupled Execution: The actual offset calculation, RadioModel::sendCmd dispatch, and update() call should be decoupled from the raw event and shifted entirely to the slot handling that timer's timeout. This guarantees that no matter how many hundreds of motion packets the OS fires per second, the application event loop remains free to interleave painting and network processing smoothly.

3. Suggested File Paths and Functions to Inspect

• src/gui/SpectrumWidget.cpp
• Refactor SpectrumWidget::mouseMoveEvent(QMouseEvent *event) chain.

What did you expect?

The application should handle high-frequency mouse drag inputs gracefully regardless of the underlying windowing system or platform plugin. Instead of processing every cursor delta, input events should be throttled or compressed by the application so that UI rendering updates are not starved out by a backed-up event queue.

Steps to reproduce

1. Boot into an Ubuntu 26.04 Wayland desktop session (where XDG_SESSION_TYPE=wayland).
2. Launch the native build of AetherSDR natively on Wayland: QT_QPA_PLATFORM=wayland ./AetherSDR. This is the explicit way, and will be the default in a native wayland session. See main.cpp
3. Connect to a FLEX-8600 transceiver and open a panadapter view.
4. Using a high-resolution/high-polling-rate mouse, left-click and drag horizontally inside the SpectrumWidget canvas to pan across frequencies.
5. Observe that the user interface completely freezes/locks up for multiple seconds.
6. Workaround Verification: Relaunch using QT_QPA_PLATFORM=xcb ./AetherSDR, perform the same rapid drag gesture, and observe a smoother panning operation.

AetherSDR version

26.6.1.1

Radio model & firmware

FLEX-8600 v4.1.5.39794

Operating system

Linux

OS version and hardware

Ubuntu 26.04 LTS