#2322 Partial updates on GTK 3.24.31 with Xorg

[Neil Hodgson]

Using Scintilla and SciTE 5.2.1 (or current repository state) on Fedora 35 with GTK 3.24.31, SciTE does not always update all of the contents when switching between files. This does not occur with other Linux installations, in particular Ubuntu 21.10 with GTK 3.24.30. The line containing the caret updates and sometimes some other lines but not all lines. This occurs randomly so is not completely reproducible. It may be more likely when the mouse is outside the application and the application has been resized. Short files seem more likely to show the problem.

Reproduction technique: open SciTE with a long (>1000 lines) and short (30 lines) file. Resize SciTE and move the mouse outside the app. Use the Alt+1 and Alt+2 key combinations to switch between the files. After about 5-20 repetitions there will be a semi-updated window with portions of both files.

Thinking this was a problem with a recent change like [58bb44] (Fix re-entrant painting to maintain update region), tried reverting to earlier revisions. The problem was present in Scintilla and SciTE 5.0.0 so was not caused by a recent change.

[Neil Hodgson]

It appears this is an Xorg issue. The problematic system was running Xorg instead of Wayland. Changing to Wayland stopped the problem. Changing the Ubuntu system with GTK 3.24.30 to Xorg reproduced the problem there.

[Neil Hodgson]

Attached is a patch that defers scroll bar changes to a low priority idle task. This is similar to some of the other work on deferring resize events and differs by concentrating on the scroll bars and using a low priority idle. There is a chance that applications will be depending on updated scroll bars in some cases so there could be new problems.

[Neil Hodgson]

Updated patch that changes priority of scroll bar change so it is ahead of wrapping since wrapping may take a while. Scroll bar positions are no longer set as this duplicates other code.

[Neil Hodgson]

The scroll bar position setting from DeferScrollbars5.patch is needed for the case where a scroll position was set before the scroll range was widened enough to fit it.

For example, when an application switches from a short document to a long document and scrolls to the end of the long document. The scroll to end is performed before the scroll bar range is set asynchronously to the full file range so the scroll thumb positioning fails as the position is (at that time) invalid. The user sees the correct portion of the document but the scroll bar appears to show that the file is near the start. Moving the scroll position within the scroll bar range setting ensures that it is moved and appears correct.

There was a little more display flashing under heavy load with the priorities used in previous patches. Moving the priority to G_PRIORITY_HIGH_IDLE + 15 which is between GTK's resize and redraw idle priorities improves this as no drawing is performed before the scroll bar is set. It still occurs after the resize is complete which seems to be what is needed to fix the bug.

[Neil Hodgson]

A potential fix has been committed as [0b5fb5]. After seeing one partial update when using G_PRIORITY_HIGH_IDLE + 15, it was changed to GDK_PRIORITY_REDRAW + 5 (125) which is 10 lower so that it occurs after redrawing. This may slow some drawing or cause extra flash. Its possible there are other causes of partial updates.

This change may not be needed in all cases and scroll bars could be changed synchronously where safe. The problem has not been apparent with Wayland but it may have occurred with Wayland in the past. Each call path to SetScrollBars could be tried with synchronous / asynchronous behaviour.