Minimize flashing when switching between main and alternate buffers

PuDB is a Python debugger that runs in the terminal. The debugger itself runs in the alternate terminal buffer, but whenever code is run (like stepping over a line or whatever), it switches to the main buffer so that terminal input/output can be processed correctly. Unfortunately, this causes a great deal of "flashing" when stepping over code, as it constantly switches buffers. This is the relevant PuDB issue https://github.com/inducer/pudb/issues/48. (note that I have minimal understanding of how this terminal stuff works, so hopefully everything I said is correct)

Andreas Klöckner (the main PuDB developer) pointed out that this doesn't happen in tmux (he uses Linux). I tested iTerm2 (2.9.20151117-nightly) and Terminal.app (OS X 10.11.3) with tmux 1.9a. Without tmux, both iTerm2 and Terminal.app are the same. Lots of flashing. With tmux in Terminal.app, there is no flashing. You can't even notice that the buffers change unless something is actually printed, and even then it isn't distracting. In iTerm2 with tmux, without integration, the flashing is even worse, in that it takes longer for the buffers to switch. With tmux integration, it's about the same as iTerm2 without tmux.

Here is a simple way to reproduce:

1. Clone pudb https://github.com/inducer/pudb
2. Run ./try-the-debugger.sh
3. Press Return a few times to clear the dialogs
4. Press 'n' several times to step through the code. Notice the flashing. Each time it runs over the "print" line, it prints a line.
5. Press 'qq' to exit.

Is there anything that can be done for iTerm2 to make this better? We've considered avoiding the buffer switching in PuDB, but that's nontrivial because it would require hooking stdin/stdout/stderr as well as creating some custom UI for dealing with them in the debugger.

Here's a debug log of it. Hope it helps. debuglog.txt

We do force the screen to redraw as soon as switching between alternate and primary buffers. At the cost of some weird behavior I could delay the redraw, but that doesn't get rid of the flashing entirely. I noticed that when stepping over the call to fermat(2) it takes about 250ms between the command to switch to the primary buffer and the command to switch to the alt buffer. There's no way it makes sense to delay a redraw that long as it would be really noticeable.

Not sure what tmux is doing—they may buffer more aggressively since redraws are expensive for them.

The downside of delaying redraw is that it creates a window for race conditions. For example, selections will copy the wrong data between the time of the buffer switch and the redraw.

I'll investigate the feasibility of a 1/30 second delay, which is small enough not to be likely to cause problems in practice and eliminates some of the flashing.

Commit 581a5dc5 introduces a short delay between buffer switching and redrawing. If you don't dawdle, there will be no flash.

Status changed to closed

Perfect. It works great.