-
-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Many enabled highlighters make scrolling and cursor moving very slow and laggy #534
Comments
The same version works OK on MacOS, so the problem is OS-related. Kind of workaround - reduce the amount of lines in frame by:
|
That looks very strange. Could you check if by any chance debug logs are enabled in settings? Also is it the same when using light theme? |
@variar , suddenly I realized that my highlighter sets are the reason - I have many of them:
and most of them have been enabled. Disabling some sets is solving the problem. As for MacOS version - I guess it's just working faster :) |
Thanks! That explains why scrolling gets slower with more visible lines. One more reason to switch highlighters to hyperscan. It allows to check a string against a set of regex in one go. |
I've added hyperscan support for highlighters. It works as a pre-filter to skip highlighters that definetely can't match a line (hyperscan support for reporting exact match position is limited). All highlighters that do pass this pre-filter step are checked as normal to get exact matches. This should improve things when most highlighters don't match. Integrated into 24.11.0.1662. |
I've accidentaly disabled hyperscan in all builds. Fixed in 24.11.0.1681. Now pre-filtering using hyperscan quick matching should be fast again. |
OS: Windows 10 LTSC 2021 (version 21H2) x64
Klogg: 22.06.0.1289 Qt5
Here's the example of scrolling - I'm turning mouse wheel constantly but view is srolling as if I'm doing it once in a second.
Same with cursor moving, selection and Page Up / Page Down - when I'm pressing the key, klogg reacts only after 0,5-1 second.
It seems that the problem depends on log frame height, i.e. search results are being scrolled pretty fast 'cause their frame is usually short
The text was updated successfully, but these errors were encountered: