Bug 1367846 - Scrolling is way too fast in writer
Summary: Scrolling is way too fast in writer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1420504 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-17 15:59 UTC by Adrien Bustany
Modified: 2017-06-17 23:28 UTC (History)
11 users (show)

Fixed In Version: libreoffice-5.2.7.2-3.fc25 libreoffice-5.2.7.2-2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-24 05:01:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Test HTML page with 1001 lines (33.44 KB, text/html)
2016-08-17 22:46 UTC, Adrien Bustany
no flags Details
evemu trace for two-finger scroll (171.26 KB, text/plain)
2016-08-17 22:46 UTC, Adrien Bustany
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Document Foundation 103174 0 None None None 2017-05-16 09:46:44 UTC

Description Adrien Bustany 2016-08-17 15:59:33 UTC
Description of problem:
When doing two-finger (trackpad) scrolling on a document in writer, a small movement causes a very important "scroll", way more than eg. firefox or other apps. This is using libreoffice-gtk3. It somehow looks like the higher resolution scrolling steps from GTK3 are taken as-is by libreoffice, demultiplicating the scrolling speed.

Version-Release number of selected component (if applicable):
libreoffice-gtk3-5.1.5.2-3.fc24.x86_64 (same version for all libreoffice components)

How reproducible:
Open a multi page document in Writer

Steps to Reproduce:
1. Test scrolling in another application like firefox, or the gnome mouse settings
2. Compare to the scrolling speed in libreoffice

Actual results:
Scrolling speed should feel the same

Expected results:
Scrolling is way too fast in writer

Comment 1 Caolan McNamara 2016-08-17 20:00:47 UTC
Presumably counter to the demands of bug 1344042

Comment 2 Adrien Bustany 2016-08-17 22:09:00 UTC
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 :-\

Comment 3 Adrien Bustany 2016-08-17 22:46:00 UTC
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.

Comment 4 Adrien Bustany 2016-08-17 22:46:28 UTC
Created attachment 1191750 [details]
Test HTML page with 1001 lines

Comment 5 Adrien Bustany 2016-08-17 22:46:58 UTC
Created attachment 1191751 [details]
evemu trace for two-finger scroll

Comment 6 kubrick@fgv6.net 2016-10-16 08:28:40 UTC
I presume this is the same bug I have noticed on arch and reported here:
https://bugs.documentfoundation.org/show_bug.cgi?id=103174

Comment 7 gsoundsgood 2017-03-25 20:45:09 UTC
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.

Comment 8 Jean-François Fortin Tam 2017-04-28 23:52:46 UTC
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?)

Comment 9 Caolan McNamara 2017-04-29 19:17:11 UTC
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.

Comment 10 kubrick@fgv6.net 2017-04-29 19:23:47 UTC
@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%.

Comment 11 gsoundsgood 2017-04-29 20:22:34 UTC
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)

Comment 12 kubrick@fgv6.net 2017-04-30 12:45:32 UTC
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.

Comment 13 Jean-François Fortin Tam 2017-04-30 15:37:24 UTC
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.

Comment 14 Caolan McNamara 2017-04-30 19:01:05 UTC
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 ?

Comment 15 Jean-François Fortin Tam 2017-04-30 19:24:15 UTC
In my case it makes zero difference whether it's on X or Wayland.

Comment 16 Caolan McNamara 2017-05-16 09:46:44 UTC
got something that looks encouraging thats worth testing, will update when build is available

Comment 17 Fedora Update System 2017-05-16 20:50:53 UTC
libreoffice-5.2.7.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-edf2fc2b5d

Comment 18 Adrien Bustany 2017-05-17 10:04:49 UTC
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.

Comment 19 Caolan McNamara 2017-05-17 14:07:01 UTC
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

Comment 20 Fedora Update System 2017-05-17 23:12:35 UTC
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

Comment 21 Caolan McNamara 2017-05-18 15:15:58 UTC
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

Comment 22 Fedora Update System 2017-05-19 23:03:43 UTC
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.

Comment 23 Fedora Update System 2017-05-21 13:10:30 UTC
libreoffice-5.2.7.2-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-50b4095c16

Comment 24 Fedora Update System 2017-05-22 09:28:42 UTC
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

Comment 25 Adrien Bustany 2017-05-22 14:41:38 UTC
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!

Comment 26 Caolan McNamara 2017-05-22 16:05:03 UTC
so that works then, good, I'll merge these to upstream 5-3 then

Comment 27 Caolan McNamara 2017-05-22 16:10:30 UTC
*** Bug 1420504 has been marked as a duplicate of this bug. ***

Comment 28 Fedora Update System 2017-05-24 05:01:50 UTC
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.

Comment 29 adamsomerville 2017-06-17 23:28:48 UTC
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


Note You need to log in before you can comment on or make changes to this bug.