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 114337 - File containing a single long line causes gtktextview to use ~100% CPU
File containing a single long line causes gtktextview to use ~100% CPU
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: General
git master
Other All
: Urgent major
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
: 151235 320991 331883 341407 347608 366060 382367 386425 416713 464827 516005 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-06-03 12:40 UTC by Jeroen Zwartepoorte
Modified: 2008-08-02 21:20 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6


Attachments
xml file tar gzipped (941 bytes, application/octet-stream)
2003-06-03 12:41 UTC, Jeroen Zwartepoorte
Details
Little single-lined text file. (27.12 KB, text/plain)
2007-11-27 15:09 UTC, Massimo Cora'
Details

Description Jeroen Zwartepoorte 2003-06-03 12:40:52 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.
Comment 1 Jeroen Zwartepoorte 2003-06-03 12:41:53 UTC
Created attachment 17096 [details]
xml file tar gzipped
Comment 2 Paolo Maggi 2003-06-03 12:44:56 UTC
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? 
Comment 3 Gustavo Giráldez 2003-06-04 06:57:37 UTC
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.

Comment 4 Paolo Maggi 2004-01-02 10:10:36 UTC
Chaging the summary for clarity.

Gustavo: should we change the product to gtk+?
Comment 5 Gustavo Giráldez 2004-01-03 18:28:41 UTC
Yes, IMO.  I don't think we can do anything in GtkSourceView to
improve this behavior.
Comment 6 Owen Taylor 2004-01-05 17:13:16 UTC
Feel free to reopen and reassign to gedit to have it catch
such files. Making this fast in GtkTextView would require
major architecture changes.
Comment 7 Paolo Borelli 2004-12-17 13:34:01 UTC
*** Bug 151235 has been marked as a duplicate of this bug. ***
Comment 8 Paolo Borelli 2005-11-08 17:40:40 UTC
*** Bug 320991 has been marked as a duplicate of this bug. ***
Comment 9 Paolo Borelli 2006-02-20 10:33:44 UTC
*** Bug 331883 has been marked as a duplicate of this bug. ***
Comment 10 Steve Frécinaux 2006-05-14 11:51:57 UTC
*** Bug 341407 has been marked as a duplicate of this bug. ***
Comment 11 Paolo Borelli 2006-08-10 20:18:34 UTC
*** Bug 347608 has been marked as a duplicate of this bug. ***
Comment 12 Paolo Maggi 2006-10-29 09:55:24 UTC
*** Bug 366060 has been marked as a duplicate of this bug. ***
Comment 13 Paolo Maggi 2006-10-29 09:57:41 UTC
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+.
Comment 14 Paolo Borelli 2006-10-29 10:04:20 UTC
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.
Comment 15 Paolo Borelli 2006-12-29 11:11:26 UTC
*** Bug 386425 has been marked as a duplicate of this bug. ***
Comment 16 Paolo Borelli 2006-12-29 16:55:19 UTC
*** Bug 382367 has been marked as a duplicate of this bug. ***
Comment 17 Denis Jacquerye 2007-03-10 08:54:22 UTC
*** Bug 416713 has been marked as a duplicate of this bug. ***
Comment 18 Paolo Borelli 2007-08-16 13:44:01 UTC
*** Bug 464827 has been marked as a duplicate of this bug. ***
Comment 19 Massimo Cora' 2007-11-27 15:09:31 UTC
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
Comment 20 Johannes Schmid 2008-03-05 10:20:43 UTC
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.
Comment 21 Yevgen Muntyan 2008-03-05 14:13:07 UTC
(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.
Comment 22 Yevgen Muntyan 2008-03-05 20:43:34 UTC
(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 ;)
Comment 23 Johannes Schmid 2008-03-10 22:18:44 UTC
> > 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!
Comment 24 Johannes Schmid 2008-03-11 11:00:21 UTC
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!

Comment 25 Yevgen Muntyan 2008-06-20 01:26:12 UTC
*** Bug 516005 has been marked as a duplicate of this bug. ***
Comment 26 Yevgen Muntyan 2008-06-20 01:27:14 UTC
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.
Comment 27 Yevgen Muntyan 2008-08-02 21:20:09 UTC
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.