I can confirm, although I find it weird it does. I guess the GTK2 version of Scintilla forces more re-highlighting for some reason?
Strange - I still don't seem to be able to reproduce it even on GTK3. But if this happens, couldn't it actually affect also fold points even when typenames actually don't change? Imagine you e.g. replace { with an empty space in the whole document and if the whole document doesn't contain any new typenames, there would be no change in typenames and the document wouldn't get re-lexed to the beginning and the fold points would be wrong. Have you tried something like that? If this is the case, then I think it's Scintilla that should be fixed.
Anyway, I see 4 options:
either not bother optimizing (e.g. re-colorize everything), effectively reverting #575. I guess this isn't wanted :)
We actually could do this if Neil accepted this patch:
https://sourceforge.net/p/scintilla/bugs/1734/
That would reduce the W*T (words in document times typename count) complexity to W*log(T) which would be fine. This is the simplest solution and we wouldn't need to do any crazy stuff in Geany. (In the pull request I was maybe pushing too hard to get the patch in and also made a mistake in absolute numbers when exactly the binary search gets better than linear search and it got eventually rejected and 40% performance loss for cases where it doesn't matter won over the 3000% performance loss in the case I tested and where the performance loss was really visible. But even if the linear part was used for some crazy number like 10000 typenames and the binary search for anything above to make really sure the result won't get slower in any case, this would solve the problem for us.)
The second option is to use SCI_SETIDENTIFIERS as Neil suggested - this works only for the cxx lexer but since almost all (if not all) languages for which we do typename highlighting use the cxx lexer, we'd probably be fine. But I haven't studied how exactly this works.
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.
That doesn't solve the scaleability issue, the complexity in average will be just one half of W*T.
detect when typenames changed, and only re-highlight (all) in this case. This would be #518 I guess?
#518 is probably too complex - we could maybe just simply compare the last typename string with the current typename string without detecting typename candidates in the document.
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.
That's possible, the question is whether it's not too complex to workaround some Scintilla issues. I think the simpler variant of #518 might be less LOCs but the best would be to either fix Scintilla or use the SCI_SETIDENTIFIERS option if it works.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/1022#issuecomment-219034491