Mouse scroll problem

[krasnovpro]

On mouse scrolling vimr fucking up the file by sending some random keystrokes.
Macvim or console vim works proper.

[tobydeh]

Same issue here, it seems to move blocks of text around and occasionally splits the window to display the manual for TR (man://TR)

[qvacua]

Hm... I haven't seen this... Does this always happen or only when ... ?

[tobydeh]

If I scroll up and down quickly It happens pretty consistently.

[tobydeh]

Here's an example. In the video i opened a file and scrolled up and down quickly using the trackpad. It lagged, moved some text around then opened a split containing the man page for export?!

[qvacua]

I'll try to fix this scroll issue. (And yes, the scroll performance is an issue, cf. GH-371)

[qvacua]

Could you try https://github.com/qvacua/vimr/releases/tag/snapshot%2F165 and give me feedback?

[tobydeh]

That fixes the issue of moving text/opening a split but now it freezes for a second or two.

I'ts fine if I scroll around slowly but when i start scrolling around quickly it lags.

The lagging seems to be worse when i scroll further in the document. If i scroll quickly to beginning and end of the document repeatedly it lags for a few seconds every time it reaches the top / bottom.

[clason]

It's especially noticeable if you fast-swipe on a trackpad to scroll down multiple times, then immediately fast-swipe in the opposite direction: Likely, you have to wait several seconds until you hit the bottom of the file (and then some) before you scroll back up.

Compare this to how, eg., MacVim handles this, where every scroll event immediately cancels all previous events before their own scroll action (Probably every input should do that.)

[qvacua]

I think the main problem is that VimR's rendering and scrolling is not at all optimized. Currently it's kind of "make-it-work-and-don't-care-about-the-performance"... I hope with time it'll improve. For example, on my MBA from 2012 or on an MBP with i7 from 2014 the scroll performance it not an issue, even in fullscreen. However, on my current mac, the base model of 13" MBP 2016 with TouchBar, it is an issue when the window is big enough... I'll close this issue and work on GH-371 (optimize scroll perf.), please follow that issue from now on, thanks.

[clason]

It's not the performance of the scrolling per se (at least for me, although it is slow when having to apply complex syntax highlighting while scrolling), it's that scroll commands are "queued" when each command should rather cancel the previous ones. So I think this is a separate issue.

[qvacua]

Yes, maybe there's room for improvement in that respect. We're already throttling the scroll (trackpad) events from NSView, but there most probably is a better or more optimized way to do that. We'll try different things in GH-371. 😊

[clason]

Maybe related: equalsraf/neovim-qt#273