Cud + Linux: very odd effect

Solved bugs are moved into this topic...
Post Reply
tmsg
Posts: 120
Joined: 20.05.2020 12:08

Cud + Linux: very odd effect

Post by tmsg »

Here's an oddity: Cud 101.5, Linux/64 bit. I load a small file, say 500 lines, window is maximised. Caret is on line 1, col 1 and I see around 75 lines on the screen. I press the down key and it takes between three and four seconds for the caret to travel down to line 75. I release the key and then again press it. Now the text begins to scroll but it takes less than two (yes, 2!) seconds for the next 75 lines to scroll up. So simply moving the caret down 75 lines takes more time than scrolling the screen up 75 lines. The lines in question are all of similar length and content. Any idea why that would happen? (It doesn't with the Windows version.)

EDIT:
And thanks to @Alexey for the new version... I've seen that the line with the found string is now highlighted :!:
No it isn't. Sorry for the noise.
Last edited by tmsg on 28.05.2020 13:55, edited 1 time in total.
Alexey
Posts: 1633
Joined: 05.10.2012 22:10

Post by Alexey »

I 've no idea... maybe try to toggle options to find the reason?
bracket_highlight
lexer_dynamic_hilite
minimap_show
links_hilite
ui_tree_auto_sync
+ toggle code-tree on/off
tmsg
Posts: 120
Joined: 20.05.2020 12:08

Post by tmsg »

Well, I tried those and a few other options... no change.

I also reverted to the original install (ie no changes to default) and no changes either. This is rather puzzling. :?:
Alexey
Posts: 1633
Joined: 05.10.2012 22:10

Post by Alexey »

I added the opt to 'play', 'track it down', pls try it?
beta updated,
https://github.com/Alexey-T/CudaText/issues/2605

//Size of lexer highlighting cache, in lines.
//Value should cover all editor's visible lines. If minimap is visible,
//value should be bigger (approx. by number of lines in minimap)
//to make cache effective.
//Too big value may slowdown the rendering.
"renderer_cache_lines": 100,
tmsg
Posts: 120
Joined: 20.05.2020 12:08

Post by tmsg »

@Alexey: I tested the beta with various values for renderer_cache_lines, from 0 to 10,000. There may be small variations but the general picture is the same. It takes significantly longer to move down 75 lines than scroll up 75 lines.

Moving down is somewhat (though not dramatically) faster when I disable the mini- and micromaps, but then scrolling is also faster :D

However, here are two observations which may help. First, if I simply press the down key myself in very fast succession, the caret moves faster than if I keep the key pressed, even with a high repeat rate. :o

Second, if I set the keyboard repeat rate very high (say >150) then the moving remains exactly as slow as before. However, the scrolling now seems to jump over some lines and is indeed even faster than before. :?:

EDIT: And, just to reiterate, this is strictly a Linux feature.
Alexey
Posts: 1633
Joined: 05.10.2012 22:10

Post by Alexey »

I give up, dont know what is happening, it seems like Lazarus/gtk2 issue (if Win32 widgetset is ok).
my code don't handle "key up" event, only "key down".
tmsg
Posts: 120
Joined: 20.05.2020 12:08

Post by tmsg »

@Alexey: no worries. It is not at the point that it's a real problem, it's just sort of puzzling. I will define either a macro or a plugin to jump around within the window anyway... I have a list of small things I have to add to each editor I use if they're not already included. Actually, Cud does most on that list already :D
tmsg
Posts: 120
Joined: 20.05.2020 12:08

Post by tmsg »

Wow :!: I don't know what you did but that keyboard change you mentioned (or another change) means that the strange effect described in this thread is now GONE :D

Also, the 100 x Line Down macro works in Linux as well. Good job.
Post Reply