Bug 14744 - gnome-terminal scroll bug
gnome-terminal scroll bug
Product: Red Hat Linux
Classification: Retired
Component: gnome-libs (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Havoc Pennington
Winston gold
Depends On:
  Show dependency treegraph
Reported: 2000-07-27 15:00 EDT by Matthew Kirkwood
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-21 18:30:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Kirkwood 2000-07-27 15:00:55 EDT
(This is probably a zvt bug, hence gnome-libs.  I don't have Pinstripe yet,
hence beta 3.)

Gnome terminal does not always correctly paint itself on scroll when a
portion of its window is covered (as far as I can see, it has to be the
lower right portion).

To reproduce:

Fire up a gnome-terminal  (mine are about 130x35, but I don't think it's

Cover a few lines and a few dozen columns of the bottom right corner.

Hit return until you're causing the window to scroll.

Run a command which will produce a few lines of output (ls -l in a smallish
directory does it for me).

Some of the output lines will be missing or incomplete.  Drag another
window over it and they will paint OK.
Comment 1 Trond Eivind Glomsrxd 2000-07-27 16:09:56 EDT
Also a problem in beta5 - highly annoying
Comment 2 Glen Foster 2000-07-30 17:49:43 EDT
This defect is considered MUST-FIX for Winston Gold-release
Comment 3 Havoc Pennington 2000-08-04 20:57:56 EDT
This one is nasty. We have a theory which patch created the bug, but that patch 
fixed another similar bug, so simply removing it isn't going to work.
Comment 4 Alan Cox 2000-08-05 21:42:46 EDT
Does merging the expose events and then forcing a repaint of a rectangle the
width of the expose area and the height of the window fix this. I think it will
if the clip rectangle is adjusted for this.
Comment 5 Havoc Pennington 2000-08-06 00:44:09 EDT
The part that doesn't get redrawn shouldn't be getting an expose; the stuff that
gets graphics exposes gets redrawn properly. At least, with the way to reproduce
it I've found, the failure to redraw is on the left side of the term, not hte
side that's partially covered...
Comment 6 Tim Waugh 2000-08-09 10:35:16 EDT
I can reproduce this problem (or one very much like it) without partially
covering the window.  New gnome-terminal, "while :; do date; done", and on lines
which cause a scroll only the first three characters or so are drawn.
Comment 7 John Cagle 2000-08-10 03:43:14 EDT
I've seen this too on pinstripe, but it doesn't happen
on every installation -- it appears to be affected by
the video mode XFree is running in.
Comment 8 Havoc Pennington 2000-08-10 18:47:03 EDT
This bug is really horrible; the gnome-terminal redraw code is insanely
complicated, and changing any of it looks likely to break something else. 
We've spent many hours looking at fixing this already with no very good
idea how to fix it.

The only "definitely will work" solution so far is to always redraw the whole
terminal on scroll, but then we have a "gnome-terminal is pretty darn slow" bug.
Comment 9 Trond Eivind Glomsrxd 2000-08-14 22:37:50 EDT
It's still present in the latest available packages (internally) and it makes
many operations really, really hard. Better slow than non-working.
Comment 10 Havoc Pennington 2000-08-19 13:13:10 EDT
OK I'm putting the "slow but works" patch into the test tree.
Will close the bug when it goes into the real tree. I know someone is going to
flame us about how "Red Hat made gnome-terminal slow" or something, sigh.
Comment 11 Trond Eivind Glomsrxd 2000-08-21 17:34:49 EDT
Still a problem using all the latest and greatest.
Comment 12 Trond Eivind Glomsrxd 2000-08-21 17:36:36 EDT
Actually, the problem here seems to be that it doesn't want to start a new
line... painting everything on the same line OK, though ;)
Comment 13 Havoc Pennington 2000-08-21 18:25:09 EDT
Is it at least better? If it's better now, we'll leave it slow, if it's not
better, it may as well be fast so I'll back out the attempted fix. We can't fix
the draw code though; there is just no way to figure it out and feel confident
about it in 7 days, it's a fairly major rewrite-lots-of-code kind of project.
i.e. if slowing it down didn't fix it, it ain't getting fixed.
Comment 14 Trond Eivind Glomsrxd 2000-08-21 18:29:57 EDT
Yes, it's better. It does repaint correctly now, it just doesn't add a newline
so it goes on writing from the start of the current line.
Comment 15 Havoc Pennington 2001-07-05 22:41:25 EDT
The solution here is a reworked terminal widget. My time estimate on this task
is 1-2 months. Not planned in the immediate future. Though I wouldn't mind
seeing it done.

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