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 issue could be seen in #1308 (comment 1012258), and here.
Current behavior
The scrolling with the touchpad is uncontrollably sensitive, a little movement of scrolling produces much more travel on the screen than expected.
Expected outcome
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.
Version information
GTK 3.24 - 4.1.0
Fedora 33 Workstation
Additional information
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 that happens: https://gitlab.gnome.org/GNOME/gtk/-/blob/65c38111f958bac66d578e3f81964ca3857105c1/gtk/gtkscrolledwindow.c#L1316.
In function 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 (for Wayland that is 10).
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). Hence, we should have different scroll units. But it couldn't be achieved, due to a limitation of Wayland (as @matthiasc said). Wayland should provide that info to GTK (there is a calculation of 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 the 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 use unaccelerated deltas for the 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.
TL, DR:
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.
Important Note:
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.