Bug 146740 - incorrect background color fill after a window refresh
incorrect background color fill after a window refresh
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Depends On:
  Show dependency treegraph
Reported: 2005-01-31 22:22 EST by Charles R. Anderson
Modified: 2018-06-27 16:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-08 00:32:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
example .muttrc for reproducing problem (799 bytes, text/plain)
2005-01-31 22:24 EST, Charles R. Anderson
no flags Details
good.png screenshot of correct rendering (83.64 KB, image/png)
2005-01-31 22:25 EST, Charles R. Anderson
no flags Details
bad.png screenshot of incorrect rendering after window refresh (84.28 KB, image/png)
2005-01-31 22:26 EST, Charles R. Anderson
no flags Details

  None (edit)
Description Charles R. Anderson 2005-01-31 22:22:55 EST
Description of problem:

When causing xterm to refresh all or part of its window (e.g.
unobscuring part of it, changing virtual desktops) it does not always
redraw the background color correctly.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. xterm -bg black -fg white -fn 10x20
2. mutt (use attached minimal .muttrc with colors & threading)
3. open a folder ('c') with lots of deep threads
4. obscure part of the window, then unobscure it (alt-tab or mouse)
5. switch virtual desktops, then switch back
6. note corrupted background colors after threading arrows (->)
Actual results:

See attached screenshot "bad.png".

Expected results:

See attached screenshot "good.png".

Additional info:

gnome-terminal doesn't have this problem, but unfortunately it is
*much* slower at scrolling text.
Comment 1 Charles R. Anderson 2005-01-31 22:24:27 EST
Created attachment 110482 [details]
example .muttrc for reproducing problem
Comment 2 Charles R. Anderson 2005-01-31 22:25:37 EST
Created attachment 110483 [details]
good.png screenshot of correct rendering
Comment 3 Charles R. Anderson 2005-01-31 22:26:22 EST
Created attachment 110484 [details]
bad.png screenshot of incorrect rendering after window refresh
Comment 4 Charles R. Anderson 2005-01-31 22:32:53 EST
By the way, Ctrl-L restores the correct rendering by causing mutt to
clear and redraw the screen.

Comment 5 Thomas E. Dickey 2005-02-04 19:41:55 EST
That could be the same as Redhat Bugzilla #128341,
which was fixed in xterm-194. See

Comment 6 Mike A. Harris 2005-02-08 00:32:03 EST
I've updated to xterm-200 in Fedora devel (rawhide), which should
resolve this issue.  Please update to the new xterm and if the
problem persists, please reopen the report.  Thanks for testing.

Setting status to "RAWHIDE"
Comment 7 Charles R. Anderson 2005-02-15 22:33:35 EST
Can you push a build of this for FC3 updates?  Rebuilding the rawhide
package on FC3 solves the problem.

Comment 8 Mike A. Harris 2005-02-16 17:25:55 EST
You can file a request for enhancment to have xterm-200 as a
FC3 update if preferred, and we'll review that for consideration


Note You need to log in before you can comment on or make changes to this bug.