> 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
