Created attachment 132248 [details] jittery scrolling with v1.11.2 SUMMARY When using a free-scrolling mouse (Logitech G502), there is a regression in scrolling behaviors. It is jittery and jumps to the next section rather than moving smoothly. The scrolling also is slow to start and takes a few seconds to pick up speed, like it is using inertial scrolling. STEPS TO REPRODUCE 1. Update to Okular 1.11.2 2. Open a long PDF 3. scroll with a free-scroll mouse OBSERVED RESULT jittery scrolling (see the video) EXPECTED RESULT scrolling should be smooth as in previous version 1.11.1 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION Doing a git bisect narrowed down the bad commit to https://github.com/KDE/okular/commit/a5be0149ec627fbc086e5b26cbbe7be13cde49b8 This issue is currently fixed in master with commit https://github.com/KDE/okular/commit/d78e2ff9e719d2e14abd11083d3a7466f5ea2736 However, it is present as of the latest release.
Created attachment 132249 [details] expected scroll behavior with 1.11.1 Here is the expected behavior for comparison. The bug is difficult to show on video but most noticeable in comparing the scrollbar behavior.
I suspect that this introduced with https://invent.kde.org/graphics/okular/-/commit/c54c38f761fb79efd0d552bdb88c7977f22b3a88. > The scrolling also is slow to start and takes a few seconds to pick up speed, > like it is using inertial scrolling. Yes, that's intentional. We turned back on animated smooth scrolling for mouse wheels in Okular 1.11.2 after fixing the outstanding regressions with it. I guess we regressed it for you, sorry. :( In the upcoming Okular 1.12 AKA 20.12, yo'll be able to disable smooth scrolling, which should fix this for you. In the meantime, I wonder if there's any way to detect free-scrolling mice and handle the scroll input as though it was a touchpad, or turn off smooth scrolling for that case Or maybe there's a bug in how the animations are handled or something. These mise are probably sending hundreds of scroll events per second. I don't have relevant hardware to test, sadly. Just a touchpad, touchscreen, and regular clicky mouse wheel mouse.
I understand I have a pretty niche use case, so having the fix in the form of disabling smooth scrolling in the next release is good enough for me. As for detecting free-scrolling mice, it might be quite difficult unfortunately. Based on the last thread, I suspect that my mouse is just sending a couple hundred to a couple thousand normal scroll events. https://bugs.kde.org/show_bug.cgi?id=420492#c15 I'd be willing to help test this with my hardware if possible.
Perhaps we should try to detect this by the rate of sent scroll events or something.
Created attachment 132319 [details] Slightly jittery scrolling with `xdotool key Down` This is what I get with `xdotool key --delay 5 Down Down [...] Down`. Afaik arrow key events go the same code path as wheel events. These are arrow key events at 200Hz. Scrolling is slightly jittery, but not always. This is the relevant code from slotScrollDown(): > d->scroller->scrollTo(d->scroller->finalPosition() + QPoint(0, 100 * nSteps), 100); This makes an undamped regulator/controller. If you consider the animation timer a feedback loop, the feedback loop is probably undamped too. The 100ms could be considered the “length” of the feedback loop. If you generate a constant stream of scroll events, the way you begin the stream can make the regulator oscillate. Since there is no damping, oscillation will continue until you accelerate or decelerate. I don’t think we should include damping code in Okular, it is more a QScroller bug. At least I don’t know what would work in Okular. Maybe we should reduce the 100ms at high event frequencies, like Nate indicated(?); or maybe it is enough to add a random component to the 100ms.
I'm not sure what changed since the last version, but the issue has gone away with 1.12.0, even when smooth scrolling is enabled.
I am also on Arch Linux with a different free scrolling Logitech mouse and it very much has not gone away for me unfortunately.
(In reply to Bernhard from comment #7) > I am also on Arch Linux with a different free scrolling Logitech mouse and > it very much has not gone away for me unfortunately. Are you able to attach a video and relevant logs? I can't seem to reproduce the issue on the current release (20.12.1) or the latest master.
Created attachment 135383 [details] scrollbar jumps when stopping (In reply to roger truong from comment #8) > Are you able to attach a video and relevant logs? I can't seem to reproduce > the issue on the current release (20.12.1) or the latest master. I'm not sure how or what logs I can provide, is there a command you want me to execute? I just tested this on kde neon unstable (less than on week old) it is there on wayland and x11. The problem seems to be not so much the 'jitter' (although it is noticeable) as the thing that I may have misattributed to jitter: When you scroll fast and then tap the scroll wheel to stop, the scroll bar jumps forward quite a few pages. See attached video.
> When you scroll fast and then tap the scroll wheel to stop, the scroll bar > jumps forward quite a few pages. See attached video. It goes away when smooth scrolling is disabled, but I have to say that is also not a solution because I keep losing the line I was reading that way. Smooth scrolling otoh is something I can only describe as extremely unresponsive. It does not seem to accelerate or slow down to with the mouse wheel but on it's own time. If I want to scroll one page exactly it will slowly begin scrolling (no matter how fast the wheel goes) and then decelerate (while the scroll wheel is already stopped) going pages further than it should.
Chiming in in 2023 to say that this problem is also very much still present for me.