bug#17497: 24.4.50; TTY menu glitches

[Thomas Dickey]

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 <dickey@his.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 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 <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature