[…] it seems the problem indeed only occurs on gtk3 version.

I can confirm, although I find it weird it does. I guess the GTK2 version of Scintilla forces more re-highlighting for some reason?

Anyway, I see 4 options:

• either not bother optimizing (e.g. re-colorize everything), effectively reverting #575. I guess this isn't wanted :)
• don't bother optimizing too much, and force re-colorizing up to the end of the visible area (sci_colourise(sci, 0, end_of_the_visible_area)). This is less expensive near the start of a document, but the same near the end.
• detect when typenames changed, and only re-highlight (all) in this case. This would be #518 I guess?
• update the visible area until we updated to the start. This is a fixed version of the current optimization, by continuously updating the visible area until we updated the start of the document.

I tried implementing the last option in 71b80ed (in my typename-highlight-fix branch). It's not that hard to do actually, as Scintilla generously does it for us going forward (the part after the visible area) -- which is why we don't suffer too much from the bug at hand currently --, so we only need to track what was the lowest position we updated since the request. This should be fairly cheap as it's incremental, and might even get "coalesced" with other scheduled updates.

What do you think? Also, @techee is this (or another) option OK regarding performances? I didn't perform the stress-tests you did leading to the current optimization, yet it might be interesting to.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub