GNOME Bugzilla – Bug 710972
gtk_text_view_get_iter_location scales badly with wrapping
Last modified: 2018-04-15 00:15:16 UTC
get_iter_location is a lot slower when setting wrap_mode to WORD (haven’t tested with other values) It also scales linearly with the length of the line. Doubling the length (and thus the number of wrapped lines) also doubles the runtime of get_iter_location.
Many things in gtktextview don't scale well if you have very long lines. That is not an easy thing to fix.
So the investigations I did in bug 710973 showed that parts in gtksourceview, namely show_line_numbers and draw_spaces call this function a lot with different lines, so the cache here https://git.gnome.org/browse/gtk+/tree/gtk/gtktextlayout.h#n147 does not work in this case. I see pango_layout_get_extents very high up in the profiles, which means it re-generates the lines over and over again. gtk_text_layout_free_line_display is also high in the profiles, supporting the hypothesis that the cache is pretty useless in this particular usecase. How feasible is it to keep around one GtkTextLineDisplay per visible line in the viewport?
It is also supporting the hypothesis that some of the features of GtkSourceView would be better off implemented inside GtkTextView
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new