GNOME Bugzilla – Bug 114337
File containing a single long line causes gtktextview to use ~100% CPU
Last modified: 2008-08-02 21:20:09 UTC
Attach XML file causes test-widget to behave extremely slow. The file in question has Windows-style linebreaks (comes from a zip file which was zipped on Windows). This causes everything to appear on a single line.
Created attachment 17096 [details] xml file tar gzipped
I think the problem is due to the fact the all the text is on a single line. Have you tried it disabling syntax highlighting?
Indded, that's GtkTextView/Pango rendering the full line for every cursor movement. Surely highlighting makes that worse, since there are a lot more segments to process when building the pango layout, but it's a bug inherent to the way Pango renders paragraphs. I don't think we can do much about it. You easily verify this by breaking the line at the beginning. If you move the cursor horizontally in the first (short) line, everything works as normal. But going to the second line exhibits the intensive CPU usage.
Chaging the summary for clarity. Gustavo: should we change the product to gtk+?
Yes, IMO. I don't think we can do anything in GtkSourceView to improve this behavior.
Feel free to reopen and reassign to gedit to have it catch such files. Making this fast in GtkTextView would require major architecture changes.
*** Bug 151235 has been marked as a duplicate of this bug. ***
*** Bug 320991 has been marked as a duplicate of this bug. ***
*** Bug 331883 has been marked as a duplicate of this bug. ***
*** Bug 341407 has been marked as a duplicate of this bug. ***
*** Bug 347608 has been marked as a duplicate of this bug. ***
*** Bug 366060 has been marked as a duplicate of this bug. ***
We are still getting a lot of duplicates of this bug, and while I agree on the fact gedit should check for long lines, I think this is a real/big GtkTextView problem. I'm reopening it assigning it to gedit. IIRC, pbor said me the Tk guys solved this problem in their code (the one on which GtkTextView is based). When we will have some more info about it we will reassign this bug to gtk+.
Mmm... I don't recall :/ Though I seem to remember that when measuring this, we were hitting the performance limits caused by pango laying out the full line before hitting the limits caused by the Btree.
*** Bug 386425 has been marked as a duplicate of this bug. ***
*** Bug 382367 has been marked as a duplicate of this bug. ***
*** Bug 416713 has been marked as a duplicate of this bug. ***
*** Bug 464827 has been marked as a duplicate of this bug. ***
Created attachment 99720 [details] Little single-lined text file. Hi guys, I've encounter this bug too many many times. It is a real pain to wait two to five minutes for gedit to open a file of 27 kb. This slows down my work. I cannot know what's inside the file before opening it. I know there are some problems related also to bug #172099, but please fix these bugs coz they're really usage-critical for a modern desktop like gnome. regards, Massimo
OK, investigated this a bit, it's even worse. Opening the attached file in the gtksourceview test program or in gedit corrupts the line. It seems like there is some overflow and the characters are drawn above each other. Testing the same in the ./testtext program of GTK+ does not show this behaviour. This is a gtksourceview bug though (and a major one!). About the performance: GtkTextView seems to be designed to always draw the full line length and not only the part that's visible on-screen. It does only draw those lines that are on screen but it should probably only draw the characters that are on screen. This is a GtkTextView and no GtkSourceView bug.
(In reply to comment #20) > OK, investigated this a bit, it's even worse. > > Opening the attached file in the gtksourceview test program or in gedit > corrupts the line. It seems like there is some overflow and the characters are > drawn above each other. > > Testing the same in the ./testtext program of GTK+ does not show this > behaviour. This is a gtksourceview bug though (and a major one!). Pango bug. Reproducible in GtkTextView. > About the performance: GtkTextView seems to be designed to always draw the full > line length and not only the part that's visible on-screen. It does only draw > those lines that are on screen but it should probably only draw the characters > that are on screen. This is a GtkTextView and no GtkSourceView bug. It's not drawing that is slow, it's syntax highlighting.
(In reply to comment #20) > OK, investigated this a bit, it's even worse. > > Opening the attached file in the gtksourceview test program or in gedit > corrupts the line. It seems like there is some overflow and the characters are > drawn above each other. Here: http://bugzilla.gnome.org/show_bug.cgi?id=90919 It seems Behdad could not reproduce overlapping characters, so please comment on that bug. Perhaps you can convince Behdad that it's a bad bug ;)
> > About the performance: GtkTextView seems to be designed to always draw the full > > line length and not only the part that's visible on-screen. It does only draw > > those lines that are on screen but it should probably only draw the characters > > that are on screen. This is a GtkTextView and no GtkSourceView bug. > > It's not drawing that is slow, it's syntax highlighting. > No, it does happend with GtkTextView test program in GTK+, no GtkSourceView involved and thus no syntax highlighting. So, I guess the drawing is slow!
Hi! > Here: http://bugzilla.gnome.org/show_bug.cgi?id=90919 > It seems Behdad could not reproduce overlapping characters, so please comment > on that bug. Perhaps you can convince Behdad that it's a bad bug ;) This part seems to be fixed with cairo 1.5. Scrolling is a big better but still quite slow!
*** Bug 516005 has been marked as a duplicate of this bug. ***
Paolo and Paolo, how about turning highlighting off if highlighting a single line took longer than some 5 seconds or something? It's lame and stupid, but is better than a freeze.
2008-08-02 Yevgen Muntyan <muntyan@tamu.edu> Bug 114337 – long lines kill GtkSourceView. Worked it around by disabling syntax highlighting if analyzing single line took more than 2 seconds. * gtksourceview/gtksourcecontextengine.c: (GtkSourceContextEnginePrivate::disabled): new field, (gtk_source_context_engine_update_highlight): check that field, (analyze_line): check elapsed time on every iteration and abort in two seconds, (update_syntax): check whether analyze_line() has disabled highlighting, (disable_highlighting): new function to turn highlighting off.