GNOME Bugzilla – Bug 90919
GtkTextView displays overlapped charecters if line is too long
Last modified: 2010-10-04 08:06:12 UTC
Tested on Solaris Intel with sources taken on Aug 6 13:26:00 BST 2002 Desription: Gedit displays overlapped charecters if line is too long If a line contains lots of charecters (i've created this scenario by replacing find with findfind and repeat the replace operation for many times), we can find some charecters gets ovelapped. You can see this when you open the attached file with gedit and goes to the 8th line
Created attachment 10518 [details] open the file with gedit
Are you able to reproduce this bug with gtk-demo (GtkTextView demo) or testtext in the gtk+/tests directory or with bug-buddy?
As per Paolo's comment.
I am able to open the same file with testtext without any overlapped charecters. I think its a problem with gedit.
I'm attaching two screenshots. The fist one shows this problem (using the Courier New 13 font) The second one shows that the problem is not reproducible if you use the default theme font (this is the reason it is not reproducible using gtk-demo and testtext). I think this is a GtkTextView problem. hp: any idea?
Created attachment 10759 [details] The problem
Created attachment 10760 [details] Using the default theme font
I'll believe it's a textview bug, but offhand I have no idea what would cause it.
Should I file it against gtk+/GtkTextView, then?
Making all 'high' textview bugs 2.2.0 as per havoc's request.
Should be fixed in current Pango CVS *** This bug has been marked as a duplicate of 73199 ***
I still can reproduce it with gedit 2.14. May be it is a Pango issue. Bug #73199 does not seem related to this problem. To reproduce it, open the file in comment #1 with gedit.
I can reproduce also with gtk+ CVS HEAD. Using testtext on CVS HEAD I don't get overlapped charecters by I get some weird redrawing problems on the same line.
Reproduces in gtk-2.8, and in cvs head. You may not *see* the overlapping characters immediately; overlapping seems to always happen, but sometimes characters are drawn close enough to each other; apparently it depends on font used. I have boldish text as a result in testtext. Another part, the blank space in almost whole line, reproduces fine. So it looks like long line is broken into pieces, and those pieces areall drawn in the beginning of the line. It's enough to make 4800-chars line here to reproduce.
Created attachment 67860 [details] Only pango, no GtkTextView It doesn't reproduce with a simple pango layout drawn onto a drawing area, see the test case.
Created attachment 67861 [details] testtext You can see that the first line looks darker than the second one.
There are a set of bugs about text rendering problems with > 64k pixels, and that's due to X's 16bit offsets. There's a cairo bug open for it IIRC.
There are about 35 thousand pixels.
Sorry for the spam, but it does reproduce with a pango layout drawn to a drawing area, just resize it to 30,000 pixels.
Created attachment 67872 [details] pango only Test case with a pango layout and drawing area.
Setting GNOME version to 2.14 as per comment #12.
*** Bug 440383 has been marked as a duplicate of this bug. ***
Fixed this a while ago.
Created attachment 96840 [details] screenshot On this screenshot you can see a long line of 'w' characters, meaning that due to the bug you can't see anything. It's recentish gtk, from few weeks ago. So it's not fixed.
confirmed. I can still reproduce it too.
Created attachment 97504 [details] screenshot Something funny is going on, not just overlapping characters but also duplicated left part of the textview (on the second screenshot).
Created attachment 97505 [details] screenshot Note the scrollbar location, it's the left part of the textview drawn in the middle.
Created attachment 97506 [details] the text from screenshots
Anyone can confirm it with cairo-1.4.10? I tested now with latest git cairo and definitely can't reproduce it. What I can reproduce is that scrolling to the end of such a long line makes the line disappear. That's because of a known cairo 16-bit limitation that we are already working on fixing.
For what it's worth, I immediately get the text drawn in the middle of textview (i.e. screenshot from comment #27, without overlapping characters) when open file from comment #28. I have these versions of libraries (Debian testing): $ pkg-config --modversion pango cairo gtk+-2.0 1.18.4 1.4.14 2.12.1
(In reply to comment #29) > Anyone can confirm it with cairo-1.4.10? I tested now with latest git cairo > and definitely can't reproduce it. Yes, I can reproduce it with cairo-1.4.10 (it's shipped with Ubuntu Gutsy). Use the file that is linked from comment #19 of bug #114337 by Massimo and the GtkSourceView test in gtksourceview/tests/test-widgets. Note: It does not happen in a GtkTextView only application (like the GtkTextView test in gtk+), so it might be related to GtkSourceView.
I looked at this a while ago, fixed some bugs, and it was really working, except that scrolling to about the end of the line made the line disappear. That was caused by cairo's 16.16 fixed format. Should be improved by latest cairo 1.5.x that has switched to 24.8. Can someone test latest cairo 1.5.x?
> That was caused by cairo's 16.16 fixed format. Should be improved by latest > cairo 1.5.x that has switched to 24.8. Can someone test latest cairo 1.5.x? OK, Ubuntu to Hardy and yes, new cairo fixes it.
Fixed!!!
Ok, lets close!
Created attachment 171673 [details] Bug in gedit 2.30.3
This bug is still present in gedit 2.30.3 (gtksourceview 2.10.4-0ubuntu1). Please see attached screenshot and testcase.