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 332057 - improve GtkTextView rendering time
improve GtkTextView rendering time
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.8.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-02-21 16:57 UTC by Arnaud Charlet
Modified: 2018-02-10 03:33 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Arnaud Charlet 2006-02-21 16:57:20 UTC
When creating a new TextView associated with a TextBuffer containing many
tags, the current calls to gtk_text_layout_validate in an idle function
are very inneficient, and Gtk+ ends up spending more time handling the idle
overhead itself than rendering.

Here is a suggested simple patch that improves the situation:

--- gtk/gtktextview.c.old       2006-02-17 16:11:04.000000000 +0100
+++ gtk/gtktextview.c   2006-02-20 17:08:54.691581240 +0100
@@ -3273,7 +3273,7 @@ incremental_validate_callback (gpointer

   DV(g_print(G_STRLOC"\n"));

-  gtk_text_layout_validate (text_view->layout, 2000);
+  gtk_text_layout_validate (text_view->layout, 20000);

   gtk_text_view_update_adjustments (text_view);

Other information:
Comment 1 Matthias Clasen 2006-02-22 18:06:47 UTC
Can you explain why the number of tags plays a role in making this inefficient ?
A testcase showing the bad behaviour might also help understanding this better.
Comment 2 Arnaud Charlet 2006-02-23 10:25:27 UTC
The issue is more visible when the file is big (in the order of X * 10000 lines
or 100000s lines), and the more tags/colors, the more work pango needs to
perform to layout the text, but even without many tags, loading a big file takes
a huge number of calls to the idle function (incremental_validate_callback),
which is very inneficient.

You can also see this issue when loading a file, then going rapidly (either
programatically or via a user interface) to a line: since the rendering isn't
complete, the cursor will go back to line 1 when the rendering is done.

So instead, we register an idle function to implement the goto line capability
and going to the line is much faster when using bigger increments.

It's hard to extract a test case, since this comes from a complex IDE
application which makes heavy use of TextBuffer/TextView:

http://libre.adacore.com/gps

Arno
Comment 3 Massimo Cora' 2006-03-24 14:17:30 UTC
Seems like this bug is related to http://bugzilla.gnome.org/show_bug.cgi?id=172099.
I tried to compile gtk+-2.8.16 with the patch proposed by Arno and it seems it loads big files quickier than before. I tested this with gtk+-2.8.16/tests/testtext.

The scrollbar problem pointed out in Gedit's bug seems vanished, or at least the performance is improved. Btw: my test pc is a 1.8 GHz and 384 MB of ram.

IMHO it would be better to remove that hardcoded value of "2000" and let it specified somewhere else, perhaps with a explanation of what exactly it does.

Comment 4 Arnaud Charlet 2007-09-21 10:33:11 UTC
Any chance to incorporate this change, or to define maybe a property so
that users can change this value ?

Arno
Comment 5 Matthias Clasen 2018-02-10 03:33:30 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.