bug#17497: 24.4.50; TTY menu glitches

[Thomas Dickey <dickey@his.com>]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]