Summary: | [GTK4] Scrolling with high-res mouse wheel is slow/laggy due to smooth scrolling. | ||
---|---|---|---|
Product: | WebKit | Reporter: | Calvin Walton <calvin.walton> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | bugs-noreply, mcatanzaro, nekohayo |
Priority: | P2 | ||
Version: | WebKit Local Build | ||
Hardware: | PC | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 245783 |
Description
Calvin Walton
2023-07-06 07:07:02 PDT
I wonder how to detect such high-resolution mouse wheels with GTK 4? 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. 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. |