Might be related to smooth scrolling. (I don’t like smooth scrolling at all, so that is my first suspection.)

I can confirm that pixel wise scrolling speed is limited too. If I configure my touchpad to scroll faster, scroll speed is limited to a speed similar to that in your video. But when I stop scrolling, it appears to jump directly to the position where it would have scrolled to without speed limitation.

In the original discussion about the smooth scrolling we diverged from the Qt defaults in some settings, you are probably affected by this configuration

https://invent.kde.org/kde/okular/-/blob/master/ui/pageview.cpp#L450

Unfortunately I don't have a mouse with that feature, are you able to test with that value increased from 1 to something like 5-10, at your liking?

I can provide you with a precompiled archlinux package if you trust random binaries from the internet

1. I don’t think that the touchpad driver sends mouse wheel scroll events like a mouse wheel does. The mouse wheel is discrete, while the touchpad has pixel-wise scrolling (which I really like very much).

2. Yes, I will be able to test that. I can compile Okular, and I also have a hyperscroll mouse “somewhere”. Otherwise there is nothing about converting my recently bought (so silly, why didn’t I just take the hyperscroll mouse?) USB mouse to a hyperscroll mouse. Other-otherwise, you can simply simulate discrete scroll events with e. g. `while [[ true ]] do sleep 0.002; xdotool click 5; done`

3. By the way, I don’t like smooth scrolling, is it possible to disable QScroller globally? That would be so nice!

Oh, and thanks for pointing that out so quickly, Kezik!

1) I don't clearly remember the details, but I remember the fact that I had to do a fair bunch of hacks because Qt on Linux doesn't give us precise informations on the matter, this is the reason we don't have the inertial scrolling on touchpad; if I remember correctly, unfortunately, everything goes down the same pipe: mouse discrete scrolling, mouse free scroll, touchpad scroll, etc.

And yes, I opened a Qt issue, and they told me to bugger off, you can see the details on the original discussion

And yes, this is quite sad and is currently the bottleneck in getting all of this working in a decent way, but I'm not sure if I have the energy to try and patch upstream Qt 

2) By "you" I was meaning to the bug OP, not you David :P I'm sure you can compile Okular 

3) It'be cool to have all the options in the Okular settings panel, I'm not aware on a method to disable it

I complied from source and tested out different MaximumVelocity values, trying 1, 10, and 100. Increasing the values made scrolling appear to accelerate faster, but it was still capped at the same maximum scroll speed.

(In reply to Keziolio from comment #5)
> this is the reason we don't have the inertial
> scrolling on touchpad;

What do you mean? My Okular from git master always supported inertial scrolling with the touchpad. You just need to enable it in System Settings.

(In reply to David Hurka from comment #7)
> (In reply to Keziolio from comment #5)
> > this is the reason we don't have the inertial
> > scrolling on touchpad;
> 
> What do you mean? My Okular from git master always supported inertial
> scrolling with the touchpad. You just need to enable it in System Settings.
You must be using the Synaptics driver. With this older driver, inertial scrolling can be provided by the driver itself sending scroll events with some falloff. When using the successor Libinput driver (which seems to be installed by default in most distros these days), inertial scrolling is not a driver feature and must be handled by the toolkit or application.

(In reply to Keziolio from comment #5)
> And yes, this is quite sad and is currently the bottleneck in getting all of
> this working in a decent way, but I'm not sure if I have the energy to try
> and patch upstream Qt 

Honestly that's not a good enough answer, if you break something, you fix it, those are the rules. Whether you have to fix things in Okular, Qt or X11 shouln't matter.

Albert,
Regarding the touchpad, nothing was broken, the behavior is the same as before


Regarding the hyperscroll mouse, I have no idea since I don't have that device, it's still not "broken"

My digression was an answer to David's comment, regarding the fact that the hyperscoll device events are probably handled in the same way as a regular mouse / touchpad, and that's quite suboptimal if we want to achieve a polished experience, but it's not worse than it was before

There is no major breakage, calm down


Regarding the original bug, the behaviour of the scroll events is programmed to be literally the same as it was before, probably QScroller::scrollTo behaves in a suboptimal way if it's flooded with events, I'll see if something comes to mind

(In reply to Keziolio from comment #10)
> Albert,
> Regarding the touchpad, nothing was broken, the behavior is the same as
> before
> 
> 
> Regarding the hyperscroll mouse, I have no idea since I don't have that
> device, it's still not "broken"

Well, if i read the bug it says it previously worked and now it doesn't, to me that says something broke.

@Albert, Kezik:
I think that both your views don’t are ultimately right. It’s not that something clearly broke, neither is it that nothing broke.

When Kezik implemented the smooth scroll feature, the funktional feature set of Okular didn’t change. It just looks a bit better now. Let us say, scrolling has  more “wow” now.

Now it turns out that Okular performs worse at fast scrolling. Again, the functional feature set of Okular didn’t change. It is just a bit slower now. Let us say, fast scrolling has less “wow” now.

So I think that no one strictly needs to fix this now. I also don’t think that we shouldn’t do anything now. I think we should evaluate the improvements and regressions, and how we could fix the regressions, and whether it is worth the work.

I suggest to look at QScroller, to investigate why it doesn’t scroll fast enough. But I fear that its arithmetics implicate some limit, so it would be much work to fix it.

After looking through the rest of pageview.cpp, I think I narrowed down the problem to the auto limit_value function. 

https://invent.kde.org/kde/okular/-/blob/master/ui/pageview.cpp#L5369
https://invent.kde.org/kde/okular/-/blob/master/ui/pageview.cpp#L5400


(In reply to Keziolio from comment #10)
> Regarding the original bug, the behaviour of the scroll events is programmed
> to be literally the same as it was before, probably QScroller::scrollTo
> behaves in a suboptimal way if it's flooded with events, I'll see if
> something comes to mind

Changing the value for nSteps to 2000 from 200 brought back the scrolling from previous versions. It seems that the regression may be in animation speed rather than scrolling if none of the code has changed.

It also brought up another bug in the animations with the Contents view. When continuously scrolling, the headings don't advance as they did in 1.9.x. It jumps to whatever heading the current page is on once scrolling has stopped. I'm unsure if this qualifies for a separate bug report, as the synchronous nature of the animations lead me to believe these bugs may be related. The effect can be seen in Contents pane of the videos attached in the OP as well.

I just stumbled over this. This is really painful. I am only able to scroll 1-2 pages per second. It is happening with my notebook and the synaptics driver as well with my desktop and a free spin scroll wheel. I am using the scroll bar again.. :-/ 

I do not think, that scroll speed should be limited at all. I would like to have a 1:1 relation between my wheel speed and the scroll speed to get an intuitive experience. previously i just new how long my wheel needs to be spun until i reach \approx 20 pages.

If there is no time to fix this, please revert back to the old model. I like inertial scrolling, but its not worth this bug. This one really limits productivity.

> Changing the value for nSteps to 2000 from 200 brought back the scrolling
> from previous versions. It seems that the regression may be in animation
> speed rather than scrolling if none of the code has changed.

So it turns out that the hyperscroll mouse doesn't do per pixel scrolling, it just sends normal mouse events at an ungodly rate

(In reply to roger truong from comment #13)
> After looking through the rest of pageview.cpp, I think I narrowed down the
> problem to the auto limit_value function. 
> 
> https://invent.kde.org/kde/okular/-/blob/master/ui/pageview.cpp#L5369
> https://invent.kde.org/kde/okular/-/blob/master/ui/pageview.cpp#L5400
> 

 //if we are too far behind the animation, do nothing and let it catch up
    auto limit_value = nSteps ? 200 : verticalScrollBar()->rect().height();

Does this mean, scrolling waits for the animation? If that is the case: 
I think, that the scroll behavior should never ever wait for the animation. This is horrible on slow computers (and also on fast ones while they are doing some heavy workload). Please, just skip the animation in this case. Does this imply, that the max scroll speed depends on the system load?

The animation is controlled by time and it's independent from system performance

(In reply to Keziolio from comment #17)
> The animation is controlled by time and it's independent from system
> performance

oh, that makes me feel better. thx for the fast reply. and sry for my rushed/harsh comment here (shouldn't read some political articles and comment at the same time :P).

Git commit 08d368c13b0fa7368be9720b8de1b7a67188b8e9 by Nate Graham, on behalf of Kezi Olio.
Committed on 29/04/2020 at 22:15.
Pushed by ngraham into branch 'release/20.04'.

Fix scroll speed with free-spinning mouse wheels
FIXED-IN: 1.10.1

This just removes the smooth mouse wheel scrolling, fixing that problem.

M  +4    -10   ui/pageview.cpp

https://invent.kde.org/kde/okular/commit/08d368c13b0fa7368be9720b8de1b7a67188b8e9

(In reply to Nate Graham from comment #19)
> Git commit 08d368c13b0fa7368be9720b8de1b7a67188b8e9 by Nate Graham, on
> behalf of Kezi Olio.

I just tested the commit and that fixed my issues, thank you!