Re: Gnome Terminal screen corruption

[Thomas Dickey]

On Fri, 31 Dec 2010, Andy Key wrote:

> Thanks for the clarification on the version.
> I had thought that the version number before the - was the underlying version,
> and the number(s) after were related to packaging.

rpm packages often have a small integer after a dash, which seems to be 
the patch-sequence number for the rpm spec-file.  But the 8-digit dates 
are from my patches.  (It's also possible for the spec-file to add other 
patches).

> I can confirm the problem happens with stock xterm (I tried xterm-261-
> 2.fc14.x86_64).
>
> Yes, the editor is moderately complex, so I am now trying to write the simplest
> possible program which shows the problem (so far unsuccessful).
>
> script is plan b.
>
> I also had a quick look inside ncurses itself.
> In tty_update.c, doupdate(), whats the rationale for check_pending() and goto
> cleanup?
> Does this ever produce a scenarios where queued keyboard input results in
> incompletely redrawn screens?

yes - that's 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.

Since screens are updated top-to-bottom, then interrupting it will leave
some lines at the bottom not updated.  (On the other hand, if curses 
doesn't do _this_, it's possible to get really bogged down - and it can
take a while to recover).

> In order to reproduce my problem, I must hold down the scrolling key.

Then typeahead is a possibility.  You can check this by turning it off
in your program (there are pros/cons).

> Individual keypresses don't cause the problem. I note that my corrupted 
> (ie: non updated) lines don't tend to happen right next to each other, 
> they tend to me 3, 4 or 5 lines apart, and I saw a CHECK_INTERVAL of 5 
> in the code. I'll admit this is what prompted me to ask on this forum 
> initially.
>
> That said, until I have a simpler testcase, the probability its something I'm
> doing wrong...
>
> {{{ Andy
>
>
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-ncurses

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net