1554408 - [Wayland] Touchpad scrolling is janky like a step function

Status: NEW

(Core :: Widget: Gtk, defect, P3)

Description

[Yariv]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/73.0.3683.86 Chrome/73.0.3683.86 Safari/537.36

Steps to reproduce:

Download the latest version of Firefox Nightly.
Start Firefox with a Wayland backend:

GDK_BACKEND=wayland ~/Downloads/firefox/firefox

Go to about:support, scroll the page using an external touchpad. I use the Apple 'magic' trackpad v1.

I'm running Ubuntu 18.04, Gnome Shell Wayland session.
I'm using an Intel GPU. In the about:support page:

Graphics

Features
Compositing: WebRender

WEBRENDER:
opt-in by default: WebRender is an opt-in feature
available by user: Qualified enabled by pref

So I guess that WebRender is enabled.

Actual results:

Scrolling is like a step function.

Expected results:

Scrolling should be smooth.

Note that when using the keyboard 'down' key or a mouse scrollwheel scrolling is smooth, it is only with a touchpad that scrolling is janky.

This is not a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1545927

I ran mozregression and got the following result:

24:23.86 INFO: Narrowed inbound regression window from [292f7a04, 5eb6bcb8] (3 builds) to [292f7a04, f9699ae3] (2 builds) (~1 steps left)
24:23.86 INFO: No more inbound revisions, bisection finished.
24:23.86 INFO: Last good revision: 292f7a045dac73573103c9d07cd3f222109ff047
24:23.86 INFO: First bad revision: f9699ae30f4d5256b6af7c8493e84984aadb4568
24:23.86 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=292f7a045dac73573103c9d07cd3f222109ff047&tochange=f9699ae30f4d5256b6af7c8493e84984aadb4568

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Might be a dup of bug 1554365?

Comment 2

[Yariv]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

Might be a dup of bug 1554365?

No, bug 1554365 is about broken scrolling under Xorg/XWayland. This bug is about working scrolling, which is rough rather than smooth, under Wayland.

btw I just tested again on the latest nightly (build 20190526211422) and the bug seems to be gone - probably because the change was backed out, see bug 1213601 comment 56.

Should I close this bug now and re-open later if the regression is reintroduced?
I'll also mention that in bug 1213601.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Ok, let's close this bug by backing out bug 1213601. Presumably once we land bug 1213601 with fixing bug1554365, this issue should be fixed. (I think the root cause is the same)

Comment 4

[Yariv]

Just to clarify, the problem is with the 2-finger 'stick to finger' scroll gesture.

Comment 5

[Karl Tomlinson (:karlt)]

I'm confused by the concept of "stick of finger" with a touchpad, as there is nothing displayed on a touchpad to stick to a finger.

Is this the widely used swipe-two-fingers-in-the-same-direction gesture?

Comment 6

[Yariv]

Yep that's what I meant. In addition 'stick-to-finger' means that you don't lift your fingers up, and the content is supposed to move in lockstep with the gesture. This might be a GNOME nomenclature, sorry for the confusion.

Comment 7

[Yariv]

Attachment: Kinetic scroll disabled

Comment 8

[Yariv]

Attachment: Kinetic scroll enabled

Comment 9

[Yariv]

Attachment: Touchpad events record

Comment 10

[Yariv]

I attached 2 screen recordings, one with kinetic scroll enabled Attachment 9077983 [details] and one with it disabled Attachment 9077982 [details]. In order to see the recordings, please click on the 'details' of each attachment then on the Google Drive link. Save each video to your computer and view it locally using mpv (due to some reason GNOME's totem doesn't resize to video). If you view the recordings online you won't be able to see the differences.

The recordings were acquired on the 'Sway' Wayland compositor using the 'wf-recorder' utility. I first recorded the touchpad gestures using evemu-record then replayed the touch events using evemu-play. The touchpad events recording is in Attachment 9077984 [details]. I used the test build from https://queue.taskcluster.net/v1/task/DJmQKI18RvOo434RvFYwYA/runs/0/artifacts/public/build/target.tar.bz2 since it implements a better integration with Wayland, however any recent nightly will have similar results.

Basically the only difference between the 2 recordings is whether kinetic scroll is enabled or not. If you watch one video then the other the difference will immediately be apparent. I'm re-opening the bug since kinetic scroll is now enabled by default.

Comment 11

[Karl Tomlinson (:karlt)]

I can reproduce something that is at least similar with MOZ_USE_XINPUT2=1 on plain X11 in Firefox Nightly and gtk3-demo ('Text View' -> 'Multiple Views).

On scrolling slowly with a touchpad and then aiming to scroll back to the original location, it is like the scrolling aims to snap to particular intervals. Scrolling will move small amounts on very small finger movements but then jump whole lines. When scrolling back, it always jumps to the same positions.

Does that sound like the same issue you are experiencing?

https://gitlab.gnome.org/GNOME/gtk/issues/2025

For me, with either Firefox or gtk3-demo, it reproduces with a builtin touchpad, but not with an external mouse, which can scroll pixel by pixel consistently with libinput Option "ScrollMethod" "button".

It actually exists regardless of the value of apz.gtk.kinetic_scroll.enabled (in Firefox), but appears to be smoothed out when apz.gtk.kinetic_scroll.enabled is false and the snap positions seem less consistent, perhaps due to the smoothing. Even with apz.gtk.kinetic_scroll.enabled false, it is not as good as the external mouse.

Comment 12

[Yariv]

(In reply to Karl Tomlinson (:karlt) from comment #11)

Does that sound like the same issue you are experiencing?

https://gitlab.gnome.org/GNOME/gtk/issues/2025

I'm not sure if what you describe is the same exact issue. I suspect that these might be 2 separate ones - the first is an inability to scroll in a 1-pixel resolution. The second is the general jerkiness experience of scrolling. The issue that I filed in the gtk bug tracker is about the second problem (general jerkiness). I think that I actually identified the root cause and even have a solution POC, though one that has to be built from source at the moment.

Generally I find X(Wayland) to give a sub-par experience with regard to scroll smoothness. If you want to test scroll related issues I suggest doing that in a pure Wayland session running programs in Wayland mode, otherwise the deficiencies of X could interfere with identifying the problem.

Comment 13

[Yariv]

I opened an MR for GDK 3 which deals with this issue: https://gitlab.gnome.org/GNOME/gtk/merge_requests/1117. It works well with Firefox on Wayland, but less so with Firefox on X11 - I'll investigate why. Other GDK-based apps (gedit, Epiphany etc) work well on both Wayland and pure X11 with this MR applied.

Comment 14

[Yariv]

(In reply to Yariv from comment #13)

I opened an MR for GDK 3 which deals with this issue: https://gitlab.gnome.org/GNOME/gtk/merge_requests/1117. It works well with Firefox on Wayland, but less so with Firefox on X11 - I'll investigate why. Other GDK-based apps (gedit, Epiphany etc) work well on both Wayland and pure X11 with this MR applied.

Turns out that Firefox received spurious scroll events on X11 due to some reason. That problem is now fixed. There are still some minor outstanding issues but nothing that seems critical.

Comment 15

[Yariv]

Eh, forgot to mention that in order to get smooth scrolling kinetic scrolling must be enabled, and on an X11 session MOZ_USE_XINPUT2=1 must be defined as well.

Comment 16

[Yariv]

(In reply to Kenny Levinsen :kennylevinsen from bug 1542808 comment #80)

Delaying event processing to render time will introduce input delay, especially so for lower refresh rate display (e.g. 60/75Hz). Web applications also need time to process events and will miss sampling deadlines (effectively input latency) or postpone render using rAF if rAF is spec compliant (missed frames). This will probably matter a lot for games and such.

Event processing doesn't strictly have to be delayed to render time. We just have to make sure that every frame receives exactly one input event. Sure, this will incur some latency. However this latency can be minimized. In addition right now only scroll events are to be interpolated, all other events will be handled as before, so a single display frame would receive a single scroll event (if any) + any other input events. I believe that most applications can sustain a little scroll latency.

Comment 17

[Yariv]

Due to some reason widget.wayland_vsync.enabled was reset to false following some nightly update, resulting in jittery scrolling. So anyone who is after smooth scroll under Wayland, don't forget to ensure it is set correctly (along with WebRender etc).

Another related issue is a recent kernel regression, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876449. This regression, starting at around kernel v5.4.0, makes input event timestamps jittery for certain devices, such as an external Apple touchpad. In turn this could result in jittery scroll, e.g. when using the aforementioned GTK MR (see comment #14).

Comment 18

[Darkspirit]

widget.wayland_vsync.enabled (bug 1629140) was disabled by bug 1632519 because of regressions (bug 1632519/bug 1632399).

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.