After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 122150 - gnome-termnal won't "redraw" text lines properly when scrolling back then forward
gnome-termnal won't "redraw" text lines properly when scrolling back ...
Product: vte
Classification: Core
Component: general
Other other
: High normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 124952 132688 146925 158065 160253 164045 (view as bug list)
Depends on:
Reported: 2003-09-12 18:54 UTC by Stephane Loeuillet
Modified: 2005-07-22 18:29 UTC
See Also:
GNOME target: 2.10.0
GNOME version: 2.9/2.10

Patch against HEAD that seems to work (580 bytes, patch)
2004-05-21 23:36 UTC, Brendan McCarthy
none Details | Review
Unified format patch against HEAD (1.52 KB, patch)
2004-05-21 23:46 UTC, Brendan McCarthy
none Details | Review
use correct row argument in vte_terminal_scroll_region (697 bytes, patch)
2004-08-17 21:14 UTC, Benjamin Otte (Company)
none Details | Review

Description Stephane Loeuillet 2003-09-12 18:59:51 UTC
Distribution: Unknown
Package: gnome-terminal
Severity: normal
Version: GNOME2.4.0 unspecified
Gnome-Distributor: Gentoo Linux
Synopsis: gnome-termnal won't "redraw" text lines properly when
scrolling back
Bugzilla-Product: gnome-terminal
Bugzilla-Component: general
Bugzilla-Version: unspecified
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

Actual Results:

bad line redrawing

Expected Results:

all text is where it was before, fully drawn

How often does this happen?

each time

Additional Information:

all new gnome 2.4 install. (gnome-term, glib 2.2.3, gtk+ 2.2.4)

would attach a screen capture soon

------- Bug moved to this database by 2003-09-12 14:59 -------

The original reporter ( of this bug does not have an account here.
Reassigning to the exporter,
Reassigning to the default owner of the component,

Comment 1 Stephane Loeuillet 2003-09-12 19:15:38 UTC
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)
Comment 2 Stephane Loeuillet 2003-09-13 00:09:24 UTC
Screenshot of the display glitch :
Comment 3 Mariano Suárez-Alvarez 2003-09-16 20:36:39 UTC
I can't reproduce this in clean 2.4 gnome. Cc'ing Nalin, since things
is probably related to vte.
Comment 4 Stephane Loeuillet 2003-09-16 20:45:20 UTC
vte v0.11.10
gnome-terminal v2.4.0.1

know other people that had this problem
Comment 5 Olav Vitters 2003-10-19 12:03:34 UTC
*** Bug 124952 has been marked as a duplicate of this bug. ***
Comment 6 Stephane Loeuillet 2003-10-19 12:14:08 UTC
still same for gnome-terminal 2.4.1
Comment 7 Mariano Suárez-Alvarez 2003-10-20 10:44:17 UTC
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
partially painted.
Comment 8 Paweł Sakowski 2003-11-10 20:24:17 UTC
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?
Comment 9 Mariano Suárez-Alvarez 2003-11-12 23:22:28 UTC
Yeah. Moving to vte.
Comment 10 Mariano Suárez-Alvarez 2004-02-01 06:22:01 UTC
*** Bug 132688 has been marked as a duplicate of this bug. ***
Comment 11 Stephane Loeuillet 2004-03-25 21:38:47 UTC
bug still exists with vte 0.11.10 and gnome-terminal 2.6.0
Comment 12 Brendan McCarthy 2004-05-21 23:36:11 UTC
Created attachment 27917 [details] [review]
Patch against HEAD that seems to work
Comment 13 Brendan McCarthy 2004-05-21 23:37:55 UTC
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 .
Comment 14 Brendan McCarthy 2004-05-21 23:46:49 UTC
Created attachment 27918 [details] [review]
Unified format patch against HEAD

The same patch in unified format
Comment 15 Olav Vitters 2004-07-09 15:15:44 UTC
nalin, can you please check/apply the patch?

Many thanks.
Comment 16 Mateus César Gröess 2004-07-10 01:03:52 UTC
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);
+		       terminal->row_count);
 	col = MAX(0, (area->x - VTE_PAD_WIDTH) / width);
 	col_stop = MIN(howmany((area->x - VTE_PAD_WIDTH) + area->width,
Comment 17 Benjamin Otte (Company) 2004-08-17 21:14:04 UTC
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.
Comment 18 Mateus César Gröess 2004-10-01 14:18:23 UTC
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
the patch?
Comment 19 Kjartan Maraas 2004-10-18 09:46:02 UTC
Nalin? Should this be applied?
Comment 20 Mateus César Gröess 2004-11-12 14:14:00 UTC
Would help if someone filed a bug requesting a new maintainer? Or has VTE
already got a new maintainer?
Comment 21 Colin Murtaugh 2004-11-14 16:25:04 UTC
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? 
Comment 22 Mariano Suárez-Alvarez 2004-11-14 21:12:40 UTC
*** Bug 158065 has been marked as a duplicate of this bug. ***
Comment 23 Kjartan Maraas 2004-11-15 09:19:47 UTC
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?
Comment 24 Colin Murtaugh 2004-11-15 13:46:20 UTC
I just updated to vte-0.11.11-14 from Fedora development; still broken.
Comment 25 Colin Murtaugh 2004-11-16 13:14:09 UTC
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. 
Comment 26 Mariano Suárez-Alvarez 2004-12-03 00:18:21 UTC
*** Bug 160253 has been marked as a duplicate of this bug. ***
Comment 27 Stephane Loeuillet 2004-12-03 23:32:58 UTC
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
Comment 28 Stephane Loeuillet 2005-01-17 11:12:41 UTC
latest patch (patch #3) also applied on gentoo now, thanks to foser (gentoo
gnome maintainer)
Comment 29 Olav Vitters 2005-01-18 11:49:44 UTC
*** Bug 164045 has been marked as a duplicate of this bug. ***
Comment 30 Kjartan Maraas 2005-02-14 23:24:22 UTC
Should go in. Nalin?
Comment 31 Luis Villa 2005-02-28 04:37:38 UTC
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.
Comment 32 Kjartan Maraas 2005-02-28 21:12:35 UTC
I commited this now.
Comment 33 Luis Villa 2005-07-10 04:37:19 UTC
Then I'm closing the bug.
Comment 34 Teppo Turtiainen 2005-07-22 18:29:29 UTC
*** Bug 146925 has been marked as a duplicate of this bug. ***