Touchpad scrolling is too fast-sensitive
Steps to reproduce
- Open a GTK3 or GTK4 window-app (that should be scrollable).
- Try to scroll with a two-finger.
The scrolling with the touchpad is uncontrollably sensitive, a little movement of scrolling produces much more travel on the screen than expected.
It should be slower, more importantly, the calculation of get_scroll_unit https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gtk/gtkscrolledwindow.c#L1186 should be robust.
GTK 3.24 - 4.1.0
Fedora 33 Workstation
The old issue could be found at #1308 (closed). Here are my findings:
Here is the calculation function of a unit of scroll: https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gtk/gtkscrolledwindow.c#L1186. Here's the actual scrolling happens: https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gtk/gtkscrolledwindow.c#L1316.
scrolled_window_scroll, we have delta values
delta_x (horizontal) and
delta_y (vertical). AFAIK they are 1 (it means one pixel) if the delta coming to Mutter -or whatever platform's compositor- is 15, basically. And
scroll_unit is calculated, then we have
delta * scroll_unit movement per input device click. For my touchpad, the delta value is something like
0.02, which should be already divided by 15 before coming to that function.
Chrome (on Windows) implements their scroll unit like 100px per scroll wheel click, 40px per every keyboard up-down event (on Linux they are all 53px), and so on. I think that we should produce a scroll unit per every input device (there's the link for input devices implemented in GTK: https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gdk/gdkdevice.h#L54) (we have deltas as pixels, I tested that also), didn't try other platforms for measurement (reporting are encouraged and needed for other platforms for other toolkits-browsers-apps) but I could get slower touchpad scrolling and quicker mouse wheel scrolling at the same time, which couldn't be achieved the same calculation of scroll unit (believe me, I did try every possible action; furthermore, I'm thinking to create then feed a deep learning -or machine learning- model to calculate a better scrolling unit function.
input_source: https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gtk/gtkscrolledwindow.c#L1259 but it doesn't work on Wayland, and also X11 with flatpak. It produces always 0, as enum). Someone should also open an issue (or provide a fix) on Wayland, then flatpak (or snap, don't sure), and finally someone could fix this bug.
In Windows, for UWP apps, they uses unaccelerated deltas for touchpad, and percent-based scrolling for mouse wheels, which is interesting for me because that is likely the same technique used in GTK at the moment.
The scrolling behavior is not the same as other platforms.
GTK should calculate the scrolling unit for every input device which has the capability of scrolling.
GTK should get the input device that is scrolling.
Wayland should provide the input device that is actively scrolling at the time of scrolling event is happening.
Copying from #1308 (comment 789067):
Please, everyone: don't add a comment just to say "it's too fast on my laptop too". First of all, the laptop maker and model tells us nothing about the touchpad or input driver, or kernel version that you're using; additionally, you're just generating random emails for the 18 people subscribed to this issue, and for everyone who's watching the GTK issue tracker. Use the "thumbs up" icon at the top of the issue description; you'll be subscribed if anything changes. Of course, somebody working on this issue and proposing a merge request would be much more appreciated.