That didn’t really work out but there was a change that made a difference - moving scroll bar modifications onto a *low priority* idle task. That is, an idle task that triggers after GTK’s resize and redraw idle tasks. Possibly that allows GTK’s internal state to stabilize before making more changes. The change is attached to
It also helps with some of the other GTK problems such as when the vertical scroll bar stops moving.
The change could cause problems with applications that examine the scroll state directly after making changes (like loading a file) as it takes some time for the idle task to get its turn to run. If this is a problem, then there could be a notification after the idle task to resume the application’s work. The priorities of Scintilla’s other idle tasks (wrapping, styling, notifying app of cursor moves, ...) may need to be arranged to give this task a chance to run reasonably quickly.
It’s too late in the release cycle to commit this but it is worth trying by any GTK projects that have experienced drawing bugs.
Neil