Editor Widget Update not triggering

[elextr]

20:49:15: Geany INFO : Geany 1.27 (git >= ad354b7), en_AU.UTF-8
20:49:15: Geany INFO : GTK 3.10.8, GLib 2.40.2

Ignore the commit, Geany Git is actually 27628c0 (I thought we fixed needing to re-configure to get the git version?)

After using Geany for a while sometimes when switching tabs [Edit: by clicking on the tabs, ie focus is outside the edit widget] only the line with the flashing caret displays the new file, then after a while some more displays etc.

If I move the cursor into the edit widget it all updates.

Its like Scintilla is not getting the correct triggers to cause full update.

This doesn't happen with all tabs, but the ones edited most.

@b4n any suggestions where to look?

[b4n]

It's odd if it doesn't reproduce always the same, and I thought we fixed all this kind of issues long ago…
But although I can't reproduce it (I guess I'd have seen this as I use the GTK3 build all the time), it might be related to using a compositing WM, that triggers less repaints and relies on more caching.

I'm afraid I don't really know where to look this time, but around the paint code in ScintillaGTK.cxx (or, less likely in PlatGTK.cxx)… maybe see if Neil got an idea, or give me more so I can reproduce it :)

[elextr]

More info:

I just noticed that the tab highlight is not moving either, so its not just Scintilla. The window header changes to the new name and the status bar to the new line no, so I know I clicked the tab, and Geany got it, but the notebook isn't updating.

[elextr]

Also seems to be easier to trigger with the tabs on the side rather than the top.

[elextr]

@b4n, looking at notebook.c it appears that the scintilla widget is focussed on the button-release event. And it is easier to provoke the problem by clicking on the tab and holding the button down, ie artificially delaying the button-release. Then sometimes when the button is released it seems to get ignored and the widget does not get focus and so does not update.

If the button-release can get lost in normal operation too then that would explain it.

Why is the focus on button-release which is an indeterminate time in the future, instead of when the switch signal happens?

[b4n]

I just noticed that the tab highlight is not moving either, so its not just Scintilla. The window header changes to the new name and the status bar to the new line no, so I know I clicked the tab, and Geany got it, but the notebook isn't updating.

If the notebook itself also misses updating, I'm afraid there's something wrong outside Scintilla at least. And if triggering an UI update helps (e.g. the display is not consistent with the underlying state, rather than the switch not having actually been made), I'm afraid it'd be a weird GTK issue.

Why is the focus on button-release which is an indeterminate time in the future, instead of when the switch signal happens?

Not sure, but I guess it's do avoid focusing if tab switch occurred by something else than a click (i.e. keybinding or alike).

[b4n]

Okay, I tried to reproduce this under GNOME3 (Adwaita), MATE with Mutter (Menta) and Cinnamon (Adwaita), no luck. All using GTK 3.18.5 under my Debian Sid.

[elextr]

So maybe its GTK version dependent, I'm using Ubuntu LTS based which is gonna be supported to 2019 and thats GTK 3.10.8.

On selecting adwaita, maybe its not "removed" but its not in the theme manager to select, so it is effectively "removed".

[elextr]

I incremented a counter in the button-down event handler and printfed it in the button-up handler and it appears some of the up events are getting lost ...

but only when the Geany window is full screen (you know, the + on the top bar on sensible DEs :)

Unless @b4n tells me we deliberately stop some button-up events from propagating then I will say this is a GTK problem, and I can live with the workaround of not making Geany full screen.

[elextr]

Of course if @b4n can reproduce with a full screen geany then maybe its worth reporting ... maybe.

[elextr]

Have updated to GTK 3.18.9 and it hasn't occurred so far, figners crossed it was GTK.

[elextr]

Damn, still happening, Geany git at 095d889, GTK 3.18.9, GLib 2.48.1, but only after running all day?

[lpaulsen93]

Today I noticed the problem again on windows. The tabs weren't reacting but the window title changed when I clicked on a tab. I accidentally touched the mouse wheel and suddenly the tabs were reacting and everything was normal after that. Not sure if that helps.

[elextr]

@LarsGit223 that kind of supports the theory of a signal being missed and the update not being completed, then when you generate a new signal from the mouse, Scintilla catches up with what it was doing.

[elextr]

Noticed today when modifying a document (C++ < 2000 lines) that hadn't been used for a while:

1. type return to get a new line
2. blank line is created and previous next line is moved down but the rest of the screen does not move
3. cause an update, eg type a char or move the cursor to a different line and the rest of the display updates

Only happens once per "stale" buffer, after that all additions are fast. System is not swapping or anything that should make a buffer that hasn't been shown for a while slow (AFAICT).

X11 Linux Mint 18.3 GTK 3.18.9, GLib 2.48.2.

[elextr]

Neil has noticed this on Scite recently (on latest Fedora), he has posted a possible workaround at https://sourceforge.net/p/scintilla/bugs/2322/. If anyone commonly sees this issue please test his patch and report back.