[mainloop-] wait less time between quick replay commands #2635

[midichef]

Addresses #2634.

The problem is new to v3.1. It came from my patch 02432ff, which fixed slowness during replay of long CPU-heavy commands (#2369). Screen redraws happened too frequently, taking CPU time away from command execution. The fix introduced a delay of 0.1 seconds (nonidle_timeout) between screen redraws, as intended. But unfortunately, the delay also happens between each command. That slows down files that contain many replay commands. For example, a reply file (sheets.vdj in #2364) with 14 lines runs 1.5 seconds slower than it did in v3.0.

This PR gets rid of the 0.1 s wait for commands when no background thread is ongoing. The intention is to slow down redraws/replays only after running a threaded command that may run for a long time, like open-file. The change fixes most of the delay in replay, though it does not bring back the full speed of v3.0.

For the example file sheets.vdj, the slowness compared to v3.0 shrinks from +1.5 s to +0.6 s. The remaining +0.6 s occurs because there are 4 commands that create a 0.1 s delay: open-file and each of the three pivot commands. Each of those creates a new sheet, and each new sheet makes a background thread for reload(). Each background thread creates a 0.1s delay during replay.

Overall, the bugs #2369 and #2634 come from the structure of mainloop(): every time through the loop, it draws the screen and replays a command, and then waits out the delay. To get the speed back to the level of v3.0, we need the loop to use different delays for replay vs. redraw, simultaneously. So during replay, vd could run the mainloop more often than now, but not draw the screen every time through the loop, and not replay a command every time through. But implementing that change is too complex for me to tackle.