GNOME Bugzilla – Bug 72374
Cursor leaves "dirt" behind in textviewer
Last modified: 2011-02-04 16:11:56 UTC
The following scenarios causes the text widget to leave pixels behind in the text window: Case 1: 1. Run testtext 2. Press the sequence [Space] [Leftarrow]. Result: A single red pixels remain below the second column where the cursor was placed after [Space]. Case 2: 1. Run testtext 2. Press "a" [Enter] [Up arrow] Result: The second line contains a red line where the cursor was placed after [Enter].
Should be fixed in CVS
Test case 2 above still happens in gtk+-2.0.0.tar.gz (as taken from ftp.gtk.org before announcement).The line isn't red though, but black. 8-)
It only happens when the line is completely empty, inserting a space makes it go away, thus it's probably some overly eager optimization of not redrawing empty lines.
*** Bug 75872 has been marked as a duplicate of this bug. ***
*** Bug 75269 has been marked as a duplicate of this bug. ***
I fixed the empty-last-line scenario, but in gtk-demo the line with the various font sizes can still be used to trigger a problem; moving the cursor on and off this line doesn't seem to invalidate a large enough vertical area. Or alternatively, the cursor seems to be drawn in slightly the wrong place on this line and the line below it. I don't have any ideas on this one yet.
I've just noticed a new variant of the "empty last line" problem (even with your latest fixes included): Open the text buffer demo in gtk-demo. In the second view, click at the end of the first paragraph (ie the cursor is now at the end of the line "places.") Hit return to insert a new empty line. Everything looks ok, the cursor is now at the beginning (end?) of the new empty line. Now press the up arrow to get to the beginning of "places." Everything still ok. But if you now press the down arrow <emphasis>while the cursor is shown</>, the cursor is still displayed before "places." and not in the new empty line (although moving further down reveals that the cursor position <emphasis/is/ in the new empty line, only the display is borked. If I repeat this and leave the invisible cursor long enough in the new empty line, it will eventually be displayed there.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Move GtkTextView 2.0.4 bugs to 2.0.5
Any news on this issue ?
No, I haven't had time recently to go through TextView bugs as they have not been showstoppers for either GNOME 2 or Red Hat Linux and those are my priorities at the moment. I will do my best not to bottleneck any work others have time to do though, and will make a pass through TextView bugs at some point (hopefully sooner rather than later).
Moving bugs from older 2.0.x milestones to 2.0.10.
OK, found a good part of this ... the range that gtk_text_layout_validate_yrange() is is using to redraw is fairly wrong. Will look into creating a patch to fix the problem.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80500 has good reproduction instructions for one way of getting the cursor left behind (that's what I was using to debug here.)
Created attachment 13597 [details] [review] gtk_text_layout_validate_yrange() patch
Explanation of the patch ... gtk_text_validate_yrange is supposed to validate the range from y0 < y < y1, with coordinates with respect to the top of the line that @anchor is in. So, when we are doing the negative part -- y0 -> 0 by iterating backwards, we need to start with the line _before_ the anchor line, and the range for this line is [- seen - line_height, - seen ], not [- seen, - seen + line_height]. In limited testing, it seems fix all of the problems marked above as remaining; I'd appreciate review and testing.
Closing optimistically. Wed Jan 15 17:02:18 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtktextlayout.c (gtk_text_layout_validate_yrange): Fix off-by-one error on the backward iteration loop, that was causing the wrong range to be redrawn. (at least part of #72734)
*** Bug 78517 has been marked as a duplicate of this bug. ***