gtk_text_view_set_vadjustment_values() called by gtk_text_view_update_adjustments() cancels scroll animation, discarding target scroll position
In my case, this issue makes searching in gedit basically unusable since it can't properly scroll when highlighting matches. Debugging hints that this may be a problem with gtk, so I'm reporting this here.
Background
gedit uses gtksourceview with syntax highlighting enabled, search feature uses gtk_text_view_scroll_to_mark()
which is animated. Based on my observations, when first applying the highlight for a given region (which also happens during scroll animation), line height sometimes increases a bit (1 pixel, barely visible). I don't know whether this is expected (maybe this is the real bug here?)
...and that's when the issue starts
-
gtk_text_view_paint()
(called bygtksourceview
?) indirectly callsgtk_text_view_update_adjustments()
which detects the height change and then callsgtk_text_view_set_vadjustment_values()
-
gtk_text_view_set_vadjustment_values()
reads the intermediate (vertical scroll position) value withgtk_adjustment_get_value()
and tries to readjust it so thatfirst_para
(?) is at the same place. - even though the readjusted
y
value is nearly the same,gtk_text_view_set_vadjustment_values()
concludes that they're not equal, since a value derived fromgint
is compared with agdouble
-
gtk_adjustment_set_value()
is called which cancels the animation and treats the readjusted intermediate value (scroll position) as the final one. - the original target scroll position is therefore lost (actually it's not even saved anywhere in a form that could still be meaningful after potential size change)
Reproduction notes
Reproducing this issue in gedit probably depends on timing and on font/theme/syntax setup. The edited file must be big enough and some regions must be unvisited (so that highlighting is "applied" while animating the scroll), but I hope my analysis above is sufficient...
Quick hack
Since gtk_text_view_set_vadjustment_values()
compares a gdouble
with a new value derived from gint
, these most likely won't match. It's already possible that the new value is less exact than the previous one. But if these were compared as gint
, unnecessary updates could be prevented without relative loss of precision (?). This seems to fix the issue for me most of the time, but it's not a real fix.
Versions
This issue exists in the latest version (and also in 3.24
, didn't try other versions)