Red Hat Bugzilla – Bug 14744
gnome-terminal scroll bug
Last modified: 2008-05-01 11:37:57 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).
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.
Also a problem in beta5 - highly annoying
This defect is considered MUST-FIX for Winston Gold-release
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.
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.
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...
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.
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.
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.
It's still present in the latest available packages (internally) and it makes
many operations really, really hard. Better slow than non-working.
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.
Still a problem using all the latest and greatest.
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 ;)
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.
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.
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.