Hi kcbrown,
I checked the "CPU load" with your input/test setup, but this seems to be not a problem of CPU load ...
I didn't expect it would be. CPUs are generally really fast, and human perception is glacial in comparison. Your CPU could be 99.99% loaded and you'd never notice it in the UI. Try running something that burns 100% CPU on all of the cores on your computer and you'll see what I mean: the computer remains perfectly responsive.
The "load" I had in mind was more with respect to resource contention (such as access to a memory buffer that's continuously being written to and which requires locking to prevent race conditions). That is something that
will slow down a UI.
But the response on the controls is somehow linked to the screen update/buffer acquisition rate.
I have the impression, that the event input buffer is limited to the first or last event in the queue in this "slow" acquisition scenario or in general to avoid "unwanted overshot" w.r.t. changing the scope settings!?
That seems like a reasonable assessment. It should be noted that even with a faster update rate, the scope still misses events from the front panel from time to time (certainly more often than it should -- it shouldn't miss
any).
We can see much more "CPU load" for active FFT and/or Measuring tasks ... see attached pictures.
Yeah, that's not a surprise. I think you'll find that the CPU load can be high while the responsiveness to the front panel remains somewhat better than under the conditions I outlined.
Frankly, if you're playing with the controls like this, the scope should, if acquisition is what's interfering with UI responsiveness,
stop acquisition immediately, and restart it a short period of time after the user stops moving the controls. This is so because if you're playing with the timebase, vertical sensitivity, etc., the scope is going to throw away the current acquisition anyway, and will keep doing so until you stop moving the controls. Meanwhile, with acquisition stopped, the scope can direct all of its attention to the controls and the display updates that result from their manipulation, and the end result will be a UI that is ultra-responsive. But again, it should do so only if acquisition is interfering with UI responsiveness in the first place, something that I think may be true only to a limited degree.
How do I know? Well, try setting up the scope as described, let it do its acquisition, and then
stop the scope. Then play with the controls. You'll find that the responsiveness isn't much better than it was with the scope running. But obviously it should be
far better, because there's nothing that the scope is doing at that point
except interacting with the user.