GNOME Bugzilla – Bug 321548
speed up gtk_text_iter_set_visible_line_index
Last modified: 2005-12-12 19:36:23 UTC
gtk_text_iter_set_visible_line_index shows up quite high in the profiles of the following real life case: create a textview with line wrapping turned on and a pretty long line in it (so that it ends up being wrapped into ten lines or so) and then start moving up and down the cursor with the arrows keys.
Created attachment 54802 [details] sysprof dump (.tgz) of the above descripted operation
Created attachment 54803 [details] pathological bench This is a pathological test case that shows the huge differnce between gtk_text_iter_set_visible_line_index and gtk_text_iter_set_line_index even when there are no invisible tags
Created attachment 54806 [details] [review] proof of concept patch This proof of concept patch speeds up the pathological test case to almost the same speed of gtk_text_iter_set_line_index and takes the function away from the profile of the scenario descripted above. The downside is that the patch is only slightly tested and may be totally broken wrt to gtktextview internals: the assumption of the patch is that the visibility of a segment can be determined by the first character in the segment itself. Playing around with the patch a bit (moving the cursor with the mouse) also triggers this assertion: g_return_if_fail (byte_on_line <= bytes_in_line); which sounds pretty strange to me and might also be a bug in the caller code that was tolerated by the current gtk code
Created attachment 54820 [details] [review] updated patch By peeking around a bit more in gtktextiter.c this seems a better way to implement the same idea of the patch above. I also removed the assertion and kept the same behavior as before: if a too high index is passed, just move the iter to the next line.
2005-12-12 Matthias Clasen <mclasen@redhat.com> * gtk/gtktextiter.c (gtk_text_iter_set_visible_line_index): Speed this function up, using the fact that visibility is constant across segments. (#321548, Paolo Borelli)