GNOME Bugzilla – Bug 332057
improve GtkTextView rendering time
Last modified: 2018-02-10 03:33:30 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:
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.
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
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.
Any chance to incorporate this change, or to define maybe a property so that users can change this value ? Arno
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.