On Sun, Jun 01, 2014 at 09:45:07PM +0300, Eli Zaretskii wrote: > > Date: Sun, 01 Jun 2014 13:18:17 -0400 > > From: Thomas Dickey > > Cc: Eli Zaretskii , 17497@debbugs.gnu.org > > > > What ncurses does when it's getting behind is to drop updates - the > > typeahead feature: > > > > The curses library does ``line-breakout optimization'' by looking for > > typeahead periodically while updating the screen. If input is found, > > and it is coming from a tty, the current update is postponed until re- > > fresh or doupdate is called again. This allows faster response to com- > > mands typed in advance. Normally, the input FILE pointer passed to > > newterm, or stdin in the case that initscr was used, will be used to do > > this typeahead checking. The typeahead routine specifies that the file > > descriptor fd is to be used to check for typeahead instead. If fd is > > -1, then no typeahead checking is done. > > So buffering output more aggressively could help, is that what you are > saying? > > We currently fflush the stream every 900 bytes and also every 10 > screen lines or so. Does that sound reasonable? I don't think that will be enough: the output stream simply is not fast enough to keep up. The typeahead feature is crude, but works. A more elegant approach (perhaps complicated) would be to keep track of the changes since the beginning of a repaint, and store _those_ into a buffer which could be discarded if it is not written before the next input character is detected. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net