Bug 258926 – [GTK4] Scrolling with high-res mouse wheel is slow/laggy due to smooth scrolling.

• Status: NEW
• Component: WebKitGTK

[Calvin Walton]

I'm running WebKitGTK 2.40.3 on Exherbo Linux (I do the webkitgtk packaging for this distro).

When I use a mouse with a high-res scroll wheel - I'm using a Logitech MX Master 3 with Magspeed wheel - I noticed that the scrolling feels somewhat slow or laggy - like, the page keeps moving after I stop moving the wheel.

Using MiniBrowser to test, I found out that the issue goes away if I disable "smooth scrolling".

Since a mouse with a high-res scroll wheel already scrolls in very small increments, the extra interpolation that "smooth scrolling" adds to transition between the large steps from a normal mouse wheel is unnecessary. It would probably be best to disable smooth scrolling automatically for high-res scroll events, similar to how it is already disabled for e.g. touchpad and trackpad scroll gesture events.

This appears to be case that was missed in the changes made in 218133

[Michael Catanzaro]

I wonder how to detect such high-resolution mouse wheels with GTK 4?

[Calvin Walton]

Duplicating some thoughts from this Epiphany issue: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1521

Right now, Epiphany is actually an outlier on the GNOME desktop - no other core GNOME Gtk4 application does "smooth" scrolling for any mouse wheel input. While turning off smooth scrolling for high res wheels would fix the issue I have noted, it might actually make sense to turn off smooth scrolling for *all* mouse wheels so the scroll behaviour on the GNOME desktop is consistent.

[Calvin Walton]

Looking at the Gtk4 EventControllerScroll stuff, I don't think there is any way at that level to directly distinguish whether or not a scroll event was from a high-res wheel.

Indirectly, you can figure it out because if the scroll signal handler is called with WHEEL units and the delta value is not an integer, then that event must have been caused by a high res wheel.

But I think Gtk accumulates multiple scroll events that happen in a single frame and emits the scroll signal once; it's possible that they could add up to an integer value.
Also, since it's still discrete events and not a continuous scroll with begin/end you can have weird cases like someone scrolling with two mouse wheels simultaneously, one high res and one not, and the resulting scroll events you get from Gtk will have them mixed together.

I think this reinforces my opinion that smooth scrolling should be disabled for all wheel events, at least on Gtk4.

[Calvin Walton]

There is a proposal to add smooth (animation-interpolated) scrolling to Gtk in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8042; the discussion there is relevant to this issue.

Some key points have come up in this discussion thread: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8042#note_2304039 where I've provided info about the behaviour of Logitech mice, including some event recordings:

* There is no way to distinguish events from a hi-res wheel vs non-hi-res wheel.
* Even if you try to by identifying "fractional" sized scrolls as from a hi-res wheel, you will still get some non-fractional values mixed in, depending on scroll speed (even multiple non-fractional values in a row).
* You can get *mixed* events from a hi-res wheel and a non-hi-res wheel in some circumstances, and have to deal with that.

Given all of the above, either:
* The WebKit smooth scrolling calculations need to be improved to reduce latency, and fix the bug where scroll speed is really slow when large scroll events are received, or
* Smooth scrolling should be disabled (by default) in WebKitGtk