GNOME Bugzilla – Bug 122150
gnome-termnal 2.4.0.1 won't "redraw" text lines properly when scrolling back then forward
Last modified: 2005-07-22 18:29:29 UTC
Distribution: Unknown Package: gnome-terminal Severity: normal Version: GNOME2.4.0 unspecified Gnome-Distributor: Gentoo Linux Synopsis: gnome-termnal 2.4.0.1 won't "redraw" text lines properly when scrolling back Bugzilla-Product: gnome-terminal Bugzilla-Component: general Bugzilla-Version: unspecified Description: 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 text-high) ... (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 : 00000000 00000000 00000000 00000000 XXXXXXX XXXXXXX 00000000 00000000 X beeing 0 or 1, depending of the char that was here but only partially redrawn 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 2.4.0.1, glib 2.2.3, gtk+ 2.2.4) would attach a screen capture soon ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-09-12 14:59 ------- The original reporter (stephane.loeuillet@tiscali.fr) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, gnome-core-maint@bugzilla.gnome.org.
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 : http://www.leroutier.net/Capture_gnome-term.png
I can't reproduce this in clean 2.4 gnome. Cc'ing Nalin, since things is probably related to vte.
vte v0.11.10 gnome-terminal v2.4.0.1 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 partially painted.
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? Many thanks.
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, 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, 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 the patch?
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 gnome maintainer)
*** 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. ***