Poor/intermittent mousewheel scrolling with a "fast" mouse

[rwarren]

Description

If you have a "fast"/modern mousewheel, Sublime frequently misses the events, giving extremely poor/chunky scrolling performance. A slower mouse does not experience this problem.

"fast" in this case means the time between ButtonPress and ButtonRelease events. If the time between press/release is too short, Sublime can fail to recognize them (OS-dependent... see below).

This took me a while to figure out and I thought it was a mouse driver or window manager problem. It is not.

Investigation on both Windows and Linux showed that 100% of Press/Release events from the mouse were getting picked up by the OS perfectly. For example, here is an output stream from xev (on linux):

$ xev | grep "Button.*event"
ButtonPress event, serial 40, synthetic NO, window 0x6000001,
ButtonRelease event, serial 40, synthetic NO, window 0x6000001,
ButtonPress event, serial 40, synthetic NO, window 0x6000001,
ButtonRelease event, serial 40, synthetic NO, window 0x6000001,
ButtonPress event, serial 40, synthetic NO, window 0x6000001,
ButtonRelease event, serial 40, synthetic NO, window 0x6000001,
ButtonPress event, serial 40, synthetic NO, window 0x6000001,
ButtonRelease event, serial 40, synthetic NO, window 0x6000001,
ButtonPress event, serial 40, synthetic NO, window 0x6000001,
ButtonRelease event, serial 40, synthetic NO, window 0x6000001,
<snip>

Each one of those ButtonPress/ ButtonRelease pairs is a clean mousewheel movement (single dedent).

The vast majority of applications (Geany, Kate, hexchat, konsole, etc, etc) pick up these wheel events with no issue. Sublime misses, or has issues, with the occasional one.

Impact varies depending on whether you are running Sublime on Windows or Linux:

Linux: Press/Release events get outright missed. Maybe 70% of them? Windows: Press/Release event pickup is strangely laggy, resulting in jerky movement. Sinlge event pairs (move one dedent in the wheel) sometimes result in instant scroll action, other times there is a very noticeable lag before Sublime/whatever decides to recognize it as an actual mousewheel event.

If I switch to a different/"slower" mouse (less time between press/release) Sublime behaviour is 100% perfect. No weird behaviour. I did not time the actual press/release interval (but might, since I'm now very curious).

Steps to reproduce

1. Get yourself a mouse with a "fast" mousewheel

This is the one I ran into it with (apparently advertising a fast mousewheel isn't just marketing hoopla!): https://www.monoprice.com/product?p_id=37991 

2. Try and scroll in Sublime with the mousewheel

3. Cringe at the jankiness/absence of scrolling :)

Expected behavior

Scrolling should be perfect, and every dedent (ButtonPress/ButtonRelease) should cause a scroll event.

Actual behavior

Intermittent/chunky scrolling with fast mouse. Somewhat OS dependent, per description.

Environment

• Build: 3211
• Operating system and version:
  • Debian 10 (WM = KWin)
  • Windows 10

[BenjaminSchaaf]

It can be that events get consolidated by the OS if ST isn't responding fast enough. Do you have a high-dpi display by any chance?

[rwarren]

No high-dpi display. Just a 1080p laptop screen with a 1920x1200 secondary monitor.

Also, unless I misundersatnd you, the OS is not consolidating the events since several other applications perform perfectly, and event monitors (like xev) pick them up ok.

[BenjaminSchaaf]

It doesn't seem like any consolidation is happening, at least on linux. Does the scrolling "finish" when you stop the mouse wheel, ie. the wheel stops and sublime finishes scrolling to where you were scrolling?

[rwarren]

That happens on windows, but on Linux the mouse wheel event pair is lost entirely.

[BenjaminSchaaf]

We don't drop any scroll events on our end. My best guess is either GTK or something else is dropping events in that case.