[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnome Terminal screen corruption

From: Thomas Dickey
Subject: Re: Gnome Terminal screen corruption
Date: Thu, 30 Dec 2010 20:10:13 -0500 (EST)

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-

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
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

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]