GNOME Bugzilla – Bug 122150
gnome-termnal 126.96.36.199 won't "redraw" text lines properly when scrolling back then forward
Last modified: 2005-07-22 18:29:29 UTC
Version: GNOME2.4.0 unspecified
Gnome-Distributor: Gentoo Linux
Synopsis: gnome-termnal 188.8.131.52 won't "redraw" text lines properly when
Description of Problem:
If i scroll back then forward in a gnome-terminal, text which was hidden
when i scrolled back is badly redisplayed :
4 lines displayed ok
1 line badly displayed (like 2 pixels high drawn instead of full
... (restart this 4,1 thing until the end of screen)
In fact, this x,y ratio changes with the scroll speed :
if slow, it would display all lines badly
if fast, it would display badly only one line every 5 or 7 lines
ex: if we have 8x8 chars, the bad line would contain only :
X beeing 0 or 1, depending of the char that was here but only partially
If i move a window above this artifact/glitch, then out, it seems the
terminal screen is redrawn properly
Steps to reproduce the problem:
1. fill 2 pages in gnome-term with what you want
2. scroll up one page
3. scroll down to where you were before
bad line redrawing
all text is where it was before, fully drawn
How often does this happen?
all new gnome 2.4 install. (gnome-term 184.108.40.206, glib 2.2.3, gtk+ 2.2.4)
would attach a screen capture soon
------- Bug moved to this database by firstname.lastname@example.org 2003-09-12 14:59 -------
The original reporter (email@example.com) of this bug does not have an account here.
Reassigning to the exporter, firstname.lastname@example.org.
Reassigning to the default owner of the component, email@example.com.
should not be here
please move to gnome-terminal-2.4.x
(version 2.4.x not in bug-buddy so i have put 'unspecified' and it
went in old gnome-core)
Screenshot of the display glitch :
I can't reproduce this in clean 2.4 gnome. Cc'ing Nalin, since things
is probably related to vte.
know other people that had this problem
*** Bug 124952 has been marked as a duplicate of this bug. ***
still same for gnome-terminal 2.4.1
Nalin, I can reproduce this systematically.
One easy way is setting a big font in a gnome-terminal and scrolling
(with the scrollbar) until you get one line to be half out of the
window, then scroll so that line goes up: the following line will be
This actually seems a vte bug. The problem can be reproduced in the
reflect-vte program from the vte-0.11.10 package.
Now, should this bug be re-reported as a vte bug?
Yeah. Moving to vte.
*** Bug 132688 has been marked as a duplicate of this bug. ***
bug still exists with vte 0.11.10 and gnome-terminal 2.6.0
Created attachment 27917 [details] [review]
Patch against HEAD that seems to work
I have attached a patch against HEAD that seems to fix the problem without
creating additional redraw. It also fixes the problem in 0.11.10 .
Created attachment 27918 [details] [review]
Unified format patch against HEAD
The same patch in unified format
nalin, can you please check/apply the patch?
I am new to Bugzilla and VTE. The patch from Brendan McCarthy, applied against
0.11.11, didn't work for me, because the value of the created variable row_count
is always equal to terminal->row_count. Seems there is no need to replace
terminal->row_count with row_count in the calc of row_stop, as done with the
patch. What solved the problem for me was simply change "terminal->row_count -
1" with "terminal->row_count" in the calc of row_stop, but I don't have a good
explanation about this because I have not understood the code very well. Below
is the patch (in the page I didn't find a way to attach a patch to my post, may
be it's done automatically?):
diff -ur vte-0.11.11.orig/src/vte.c vte-0.11.11/src/vte.c
--- vte-0.11.11.orig/src/vte.c 2004-05-02 03:43:01.000000000 -0300
+++ vte-0.11.11/src/vte.c 2004-07-09 21:21:01.000000000 -0300
@@ -13793,7 +13793,7 @@
row = MAX(0, (area->y - VTE_PAD_WIDTH) / height);
row_stop = MIN(howmany((area->y - VTE_PAD_WIDTH) + area->height,
- terminal->row_count - 1);
col = MAX(0, (area->x - VTE_PAD_WIDTH) / width);
col_stop = MIN(howmany((area->x - VTE_PAD_WIDTH) + area->width,
Created attachment 30677 [details] [review]
use correct row argument in vte_terminal_scroll_region
I believe the problem is that vte_terminal_scroll_region calls
vte_invalidate_cells with the wrong row argument when using the optimized path.
The attached patch fixes this.
I have been using the last patch attached by Benjamin Otte for more than one
month and did not have noticeable problems. Nalin, can you please check/apply
Nalin? Should this be applied?
Would help if someone filed a bug requesting a new maintainer? Or has VTE
already got a new maintainer?
Just installed FC3 which includes g-t 2.7.3 and vte 0.11.11 -- still a problem.
Is this ever going to get fixed?
*** Bug 158065 has been marked as a duplicate of this bug. ***
I think there are some new vte packages in rawhide or updates-testing that could
help here. Could you try those and see if your problem is fixed there?
I just updated to vte-0.11.11-14 from Fedora development; still broken.
I rebuilt the vte-0.11.11-14 package from Fedora dev, adding Benjamin Otte's
patch, and g-t seems to be redrawing fine now.
*** Bug 160253 has been marked as a duplicate of this bug. ***
any chance to have this patch applied upstream (in vte/gnome cvs) before gnome
2.10 ?? (bug reported 15 monthes ago, patch available for 4 monthes)
i'll try to push this patch to my distro (gentoo) gnome maintainer but it's not
the way to go
latest patch (patch #3) also applied on gentoo now, thanks to foser (gentoo
*** Bug 164045 has been marked as a duplicate of this bug. ***
Should go in. Nalin?
Kjartan, was this in the batch of commits you made? Looks like 'no' as far as I
can see. Seems like one (given that it has been tested in gentoo releases) that
someone should go ahead and commit.
I commited this now.
Then I'm closing the bug.
*** Bug 146925 has been marked as a duplicate of this bug. ***