Bug 1367846

Presumably counter to the demands of bug 1344042

Hmmm that's interesting... I wonder if we could somehow meter it, maybe with a document and its rough HTML equivalent in Firefox, and replaying scroll events with event emulation? Do you know any standard tools for that? Should I try to figure it out? I really wouldn't care about a small difference, but scrolling is close to unusable for me in Writer, enough that I reverted to using the keyboard and/or Word in Wine :-\

So I tried evemu for the fun of it, here is what I did:

1. Write a simple HTML page with 1000 line, see test.html attachment
2. Open that page in Firefox
3. Copy paste the text in Writer. On my laptop, the text ends up being the same size, so if I resize the Firefox window so that the top border matches the page top in Writer, lines are pretty much "in sync" between Firefox and Writer. For example, on my 13" laptop, I see lines 0000 to 0019.
4. Record a "two finger vertical scroll" using evemu-record. Such a trace is available in the attachments (sudo evemu-record /dev/input/eventXX evemu.out where XX matches the ID of your trackpad).
5. Replay the trace once with the mouse pointer over Firefox, once with the mouse pointer over Writer (sleep 3 && sudo evemu-play /dev/input/eventXX < evemu.out , sleep so that I have the time to alt-tab to Firefox or Writer ☺)

In Firefox, I get a smooth scroll down to line 45. In Writer, I get a crazy jumpy scroll down to line 150. To make sure Firefox's smooth scrolling wasn't changing the results, I checked GEdit as well (because of the reduced interline, I see line 0000 to 0025 on the first screen), which scrolls down to line 73.

Created attachment 1191750 [details]
Test HTML page with 1001 lines

Created attachment 1191751 [details]
evemu trace for two-finger scroll

I presume this is the same bug I have noticed on arch and reported here:
https://bugs.documentfoundation.org/show_bug.cgi?id=103174

This is just to confirm that I also suffer from the same issue on Fedora 25 (Xorg). Following the suggestion included in first comment to the bug report mentioned in the previous comment, i.e. starting libreoffice from the terminal with this command:

SAL_USE_VCLPLUGIN=gtk libreoffice --writer

solves the issue for me. 

But yes, still a bug.

I also have the issue in the sense that on Fedora 25 + GNOME on Xorg, scrolling with a touchpad is "jerky" in LibreOffice 5.2.x but not in native GTK3 apps (such as Evince) or Firefox.

Using "SAL_USE_VCLPLUGIN=gtk libreoffice --writer" improves the problem a tiny bit because at least it doesn't jerk around up and down in some sort of imprecise way, however that's still far from being "smooth" scrolling like what I'm seeing in Evince or Firefox, which is what LibreOffice should aim for (is this still the right bug report for that or it needs a separate bug report?)

The problem for me is one of perception, I just can't properly "feel the problem in order to fix it", touchpad scrolling is not a thing I do comfortably.

vcl/unx/gtk3/gtk3gtkframe.cxx GtkSalFrame::signalScroll is the method in question and case GDK_SCROLL_SMOOTH: if anyone wants to play around what that themselves.

@coalan: trust me this has nothing to do with perception, it's just that you haven't been able to reproduce the problem. I think the issue Jean-François is is having must be different because in my case, it's not just a bit "jerky" with gtk3, it's just plain unusable, it will actually move in erratic directions the UI freezes for many seconds while scrolling and CPU is 100%.

I think UI freeze and CPU at 100% are well beyond the issue reported by Adrien Bustany in this bug, which describes accurately what I have. 

But to be clear: this is not a matter of perception. If you experience this bug, scroll is evidently wrong, i.e. going multiple times quicker than it should... it makes scroll impossible to use, totally unlike what you have in other applications in the same session, or in Libreoffice in Fedora in another installation where I don't have this bug. 

starting libreoffice with the following command:

SAL_USE_VCLPLUGIN=gtk libreoffice --writer

solves the issue for me, i.e. libreoffice scrolls back to normal speed (even if, for example, I don't get the dark color scheme I have set in Gnome)

Could it be the same problem exacerbated by HiDPI? Now this is subjective, but I feel that if I disable HiDPI, I can relate to that more subtle problem of it just being a bit fast and jerky.

Actually, I was not specific enough in my reproduction instructions: the scrolling problems get revealed when you scroll *slowly* with the touchpad (either using edge scroll or two-fingers scroll, though edge scroll usually allows greater precision).

By simply having a finger on the scrolling edge and "slanting" that finger you can achieve very slow scrolling speeds, which in Evince and Firefox translates to smooth scrolling, but in LibreOffice:
- without SAL_USE_VCLPLUGIN=gtk it tends to jerk a bit up and down, in addition to being non-smooth (non-continous)
- with SAL_USE_VCLPLUGIN=gtk it still scrolls in a non-continous way, though at least it doesn't have the up & down erratic behavior.

FWIW SAL_USE_VCLPLUGIN=gtk of course just starts with the gtk2 backend instead of the gtk3 backend

This is probably a simple problem at the root, especially if its ok for firefox. Does wayland vs X make any difference ?

In my case it makes zero difference whether it's on X or Wayland.

got something that looks encouraging thats worth testing, will update when build is available

libreoffice-5.2.7.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-edf2fc2b5d

The update kills the "crazyness" in the scrolling for me, so it's definitely a welcome improvement! Scrolling is still very "laggy" though, ie. if I do a two finger "swipe" up, I don't get smooth scrolling, but instead nothing while I'm swiping, and a jump at the end (to the expected location). This problem is not present when scrolling slowly, nor when dragging the scrollbar manually.

I imagine (while I can't reproduce it) that the lag + jump is us not able to keep up with the scrolling event so maybe queuing up the scrolls and merging scrolls together if we haven't processed the earlier scroll yet might be of some use there

libreoffice-5.2.7.2-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-edf2fc2b5d

locally queueing and merging scroll events and scrolling a huge document sometimes results in merges so its plausible that may help. I'll make that change available to see if it matters

libreoffice-5.2.7.2-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

libreoffice-5.2.7.2-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-50b4095c16

libreoffice-5.2.7.2-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-50b4095c16

With libreoffice-5.2.7.2-3.fc25 scrolling works perfectly for me: I can scroll both fast and slow, and the behaviour feels natural. Thanks Caolan for following up on this issue!

so that works then, good, I'll merge these to upstream 5-3 then

*** Bug 1420504 has been marked as a duplicate of this bug. ***

libreoffice-5.2.7.2-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

running 5.2.7.2-3.fc25 here and still seeing finding it hard to scroll slow.

with the workaround: SAL_USE_VCLPLUGIN=gtk libreoffice --calc its perfect.

it seems slow scrolling up until a threshold is ignored, then beyond that point it scrolls fast, like we are loosing any fractional movements, whereas with the workaround however slow i track my fingers down the pad all the small movements accumulate and eventually cause a page movement.

I saw a similar issue in Gnome Wayland where there was a float to int cast in the input event handling that was causing a similar effect on the cursor movements, only deltas > 1.0 had any effect.

cheers