Scrolling speed for LineDelta too high

[eugenesvk]

Previously ~1 wheel "notch" moved by ~1line as expected, now it jumps to the end of a ~2-page app

Maybe due to this?

https://github.com/linebender/xilem/pull/925

[eugenesvk]

While it's not as bad as before, the issue still remains - the scroll factor is way too high.

It seems there are at least 2 mistakes:

• The default 120 factor is wrong: the comment says its from Chrome, but Chrome doesn't jump as much, and from its source it's 100px/3 lines, not 120px

https://github.com/chromium/chromium/blob/496d64d1a0930c818b4a546366617bf4d352a52a/ui/events/blink/web_input_event_builders_win.cc#L327-L331

• Currently # of lines isn't taken into account, I've changed 1 to 3 in SetPoint logitech mouse app on Windows, and the scrolling distance didn't change in a Xilem app (but it did in other apps)

So to match Chrome the factor should be 33.33px and then get multiplied by the number of lines

[DJMcNab]

I took on trust the claim that it was 120px in #925. @xorgy can you explain where that number came from?

Can you confirm that Masonry is getting the right number of lines from Winit? As far as I know, we multiply that value returned by Winit. If the setting isn't being taken account for in Winit, it seems likely to be a Winit bug.

[xorgy]

The LineDelta is handled very differently on different platforms. On winit for Windows, all values (including fine deltas from fine wheels and touchpad scroll) are smuggled through a fractional LineDelta, whereas on X11 LineDelta is always magnitude 1 because that's what winit translates the wheel ‘button’ events from X11 as; pixel deltas are delivered completely separately through XInput2. The underlying unit for conventional scroll wheels is angular, although actual mouse wheels do NOT report the same amount of angle for the same angular movement. On Windows, this set of concepts is exposed, but it is also wrapped up with fine deltas, and it seems that the winit Windows platform impl just gives up on distinguishing the two (although there IS a pixel equivalent for conventional wheel events also delivered by Windows, or at least a quantity that many applications interpret as a pixel equivalent).

If we adjust to the Windows Chrome standard as @eugenesvk suggests, then scrolling will be painfully slow on X11 because it always reports magnitude 1 LineDelta.

So the reason 120 dp is reasonable for me on X11 is incidental, because of how wheel buttons are translated.

Basically, in order to handle this with winit in its current state, we need to special case Windows and X11 (and possibly Wayland) because each platform_impl uses these very differently.

[xorgy]

To get the behavior where the line equivalent from user settings is respected, we would need to get that information separately with the windows API (which from what I've read is doable), or fix the winit windows platform_impl... but even then behavior will be inconsistent.

When we get around to writing a raw windows adapter for ui-events, we will figure this all out to the best of our ability, and hopefully that work can make it into winit (or maybe they just adopt our pointer code).

[xStrom]

I think we should aim for a higher standard than whatever winit happens to be doing right now. Which is to say, our goal should be based on data that does not involve winit. Then later we can see if winit helps us, or if we need to fix winit.

I wonder, is Chrome scrolling roughly similarly sized crossplatform?

[xorgy]

There might be a way to fix this in ui-events-winit (using platform detection), I can take a look at it.