I did something similar at lecroy booths. take the timebase knob, spin it fast left, fast right, fast left and repeat that like 10 times. Then walk away while the scope goes nuts zooming in and out and displaying that dreaded "triggering..." with the slowly crawling progress bar at the bottom.
Ah, the good ol' "let's do computation in the UI event handler" antipattern. Causes the events to be queued, slowing down everything. Drives me crazy.
The correct solution is simple: you split the display update into a separate mechanism. On the web, you use
window.setTimeout(). On widget toolkits, you use an idle handler. For best results, update the numeric values showing the state, but postpone recalculating and redrawing the display until the UI event queue is empty. That way, you twirl the buttons and only the numbers change immediately; it'll take that 0.1s or so of inactivity for the entire display to be recalculated and redrawn. During long computation, if there are new UI events in the queue, drop and restart the computation, unless it has been say twice the maximum duration of a full calculation. That way you always get a display update in bounded time,
with the latest settings, even when twirling the button, but no event queueing beyond that, no matter what happens.
This is not new, and was well known and common in the 8-bit era already, especially games. It saddens me to hear that even LeCroy fell into this easily avoided UI trap...