Scroll is too slow on Gnome/Wayland

[akhilman]

Scrolling speed is very slow in Gnome/Wayland using glium backend.
Screencast

There must be a way to solve all this scrolling mess.

Scroll event handling happens here:

egui/egui_glium/src/lib.rs

Line 178 in 2af86cd

let line_height = 8.0; // magic value!

Related issue with useful comments: #159 (comment)

Screencast.from.04-06-21.12.06.19.mp4

[emilk]

See also #356

There must be a way to solve all this scrolling mess.

The solution is probably for people on different platforms to start contributing fixes to winit.

[akhilman]

Seem like related to rust-windowing/winit#22.

[akhilman]

egui/egui_glium/src/lib.rs

Line 178 in 2af86cd

let line_height = 8.0; // magic value!

So, winit emits one 1 / -1 line delta event for each click of the scroller.
Where does the magic number 8 come from?

If this is the approximate line height of egui text, can we have a configurable number of lines per click of the scroller?

Is it ok If we extend GliumInputState or/and WindowSettings to have scrolling speed?

[akhilman]

I tested the egui and winit's mouse_wheel example under Windows. Exactly the same result as in the gnome, one click - one event with a 1 / -1 delta and a scroll of only 8 pixels.

[akhilman]

Similar issue in flutter flutter/flutter#71385

The GTK code uses pow(page_size, 2.0 / 3.0) as the scroll delta when scroll events are received as steps (source). The page_size is the height of the area being scrolled.

The Chromium uses 53 as scroller step.
The X11 - 40.
The imgui scrolls 5 lines per one wheel click.
The Iced uses 60px per one scroller click.

[WeiPhil]

I'm also facing this issue on Windows with the glium backend. Could we maybe, while this is not fixed in winit, provide a builder parameter to the scroll area and/or window scroll? Even if fixed, I can imagine a user parameter being useful, similar to how the dragValue speed can be changed.

[akhilman]

Could we maybe, while this is not fixed in winit.

I don't think this is a winit problem, because it seems that one "line" of scroll means one click of the scroller, or about 15 degrees of wheel rotation.
In my opinion, the decision on what to do with this event depends on the application.

So we need to decide how to interpret one click of the scroll wheel.

There are also cases when the author of the application needs clicks, and not scrolling in pixels. For example, to change a value by one in the integer input area, or to select a weapon in a game.