Bug 420755 - Option to disable animated scroll transitions
Summary: Option to disable animated scroll transitions
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.9.2
Platform: Microsoft Windows Microsoft Windows
: NOR wishlist
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
: 421039 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-04-29 14:52 UTC by Christoph Loy
Modified: 2021-02-18 15:48 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.12


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Loy 2020-04-29 14:52:47 UTC
SUMMARY

Jumping to a position in the pdf (e.g. by clicking a link to another page) is not done instantly. Instead a rather choppy animation plays that I'd like to deativate

STEPS TO REPRODUCE
1. Press a link in a pdf that leads to another page (or press back on the mouse)


OBSERVED RESULT

Choppy scrolling animation starts until the desired page is reached

EXPECTED RESULT

The desired page should be displayed instantly and without animation


SOFTWARE/OS VERSIONS
Windows: Windows 10 10.0.18363 Build 18363
KDE Plasma Version: None
KDE Frameworks Version: ?
Qt Version: ?
Comment 1 Till Schäfer 2020-04-29 20:40:29 UTC
fast scrolling is also very sluggish now -> +1 for an option in the settings
Comment 2 David Hurka 2020-04-29 22:32:30 UTC
Hi.

Technically, the “fast scrolling is too slow” problem is not related to this. The latter uses QScroller, and was introduced when smooth scrolling was implemented recently.

The animation described here is handled by PageView itself, and has been there for a long time. We call it animated scrolling in the code.

I think technically it would make sense to merge them both to use QScroller.

But I agree that it would be nice to disable smooth scrolling and animated scrolling, because I don’t like them either. Adding such minor options is currently not really accepted. (IMHO, smooth scrolling is a try to satisfy the majority of users. But it can really upset the minority, so it’s no gain overall.)
Comment 3 Christoph Loy 2020-04-29 22:41:24 UTC
(In reply to David Hurka from comment #2)
> Hi.
> 
> Technically, the “fast scrolling is too slow” problem is not related to
> this. The latter uses QScroller, and was introduced when smooth scrolling
> was implemented recently.
> 
> The animation described here is handled by PageView itself, and has been
> there for a long time. We call it animated scrolling in the code.
> 
> I think technically it would make sense to merge them both to use QScroller.
> 
> But I agree that it would be nice to disable smooth scrolling and animated
> scrolling, because I don’t like them either. Adding such minor options is
> currently not really accepted. (IMHO, smooth scrolling is a try to satisfy
> the majority of users. But it can really upset the minority, so it’s no gain
> overall.)

Thanks for your response!

Since this is my first bug filing, I am not really sure what your response means in the end... Is this basically a WONTFIX? Or is this topic still up for discussion?

I hope I don't waste your time too much with my maybe naive questions :P
Comment 4 David Hurka 2020-04-30 13:17:50 UTC
This topic is still being discussed. You can sort the Okular bug list by date of last change, there are some more bugs about scrolling. In particular, Kezik submitted a patch to disable smooth scrolling for now, to implement it better later.

WONTFIX would be INTENDED, but this might also be NOT A BUG. This animated scrolling is probably not worth a configuration option, because you use it much less often than regular scrolling, and so is much less annoying. Maybe it should follow the system setting for GUI animations.

If you want to disable it now, and can compile Okular yourself, you could look into PageView and change the animation duration to e. g. 1ms.
Comment 5 Nate Graham 2020-05-01 14:51:06 UTC
Nitpick: you're not objecting to smooth scrolling (which refers to pixel-by-pixel touchpad scrolling) but rather animated scroll transitions when using a mouse wheel or keyboard navigation. Re-titling appropriately.

Also note that animated scroll transitions for wheel scrolling were reverted in Okular 1.10.1 to fix some regressions encountered by people with free-wheeling scroll wheels.

Finally, I agree with David H that Okular could respect the global setting for animation duration here, turning off animated scroll transitions entirely when the user has disabled all animations. I don't think it makes sense to add an option only in Okular though. That seems like over-configuration.
Comment 6 Christoph Loy 2020-05-02 09:47:28 UTC
First, thanks for fixing up my bug report.

For KDE users, I agree, a global setting would be perfect. But what would that mean for a windows user like me? I totally do understand that windows is probably not your number one priority, but I'd still be interested how a solution for windows would look like.
Comment 7 David Hurka 2020-05-02 12:02:49 UTC
(In reply to Christoph Loy from comment #6)
> For KDE users, I agree, a global setting would be perfect. But what would
> that mean for a windows user like me?

I don’t know, but you will probably not be able to configure it. It will probably depend on the style you use (Aero or Classic).

(In reply to Nate Graham from comment #5)
> Nitpick: you're not objecting to smooth scrolling (which refers to
> pixel-by-pixel touchpad scrolling) but rather animated scroll transitions
> when using a mouse wheel or keyboard navigation. Re-titling appropriately.

Sounds like you expect that smooth scroll transitions (mouse wheel step / arrow key) and smooth scroll transitions (clicking a navigation link) will use the same code soon.
Comment 8 David Hurka 2020-05-05 17:45:31 UTC
*** Bug 421039 has been marked as a duplicate of this bug. ***
Comment 9 nfxjfg 2020-05-05 18:14:14 UTC
If this was introduced for touchpad use, you should really reconsider the impact on normal desktop users. I'm not sure if you can detect touchpad use, but if you can, disabling this by default for mouse/keyboard would be a sensible thing to do.
Comment 10 Christoph Loy 2020-05-05 18:31:28 UTC
(In reply to nfxjfg from comment #9)
> If this was introduced for touchpad use, you should really reconsider the
> impact on normal desktop users. I'm not sure if you can detect touchpad use,
> but if you can, disabling this by default for mouse/keyboard would be a
> sensible thing to do.

I am not really sure what clicking on links has to do with using a touchpad or a mouse...
Comment 11 gwarser 2020-05-05 18:38:38 UTC
Should I create new bug if I want to disable inertial scrolling after scroll by mouse dragging? I should note that it seems to "explode" sometimes - happened to me once, after dragging, 50-page document was very fast scrolled to the end.
Comment 12 nfxjfg 2020-05-05 18:46:04 UTC
Christoph Loy: I don't know. My bug was closed as duplicate of this, and it wasn't about any links at all.

gwarser: Judging from the closing of my bug report, what you suggest is part of this bug.
Comment 13 Tristan Miller 2020-05-25 14:51:40 UTC
Another important reason to provide a mechanism for disabling this new feature: the scrolling animation makes Okular all but unusable when running remotely over a slow Internet connection.
Comment 14 nfxjfg 2020-06-16 11:54:00 UTC
In addition, this new behavior seems to make the page up/page down keys scroll VERY slowly and VERy annoyingly (animated scroll down for half a second, full stop for half a second, repeat).

This is absolutely unusable.
Comment 15 Florent Rougon 2020-07-02 12:01:56 UTC
I fully agree with comment #14. I love Okular, but having Page Up and Page Down take so much time is absolutely terrible. One can't reasonably browse through a largish PDF file anymore. Please restore quick Page Up and Page Down behavior. The animation I see in Okular 1.10.2 is a big usability regression for useless eye candy; that is a pretty bad tradeoff, IMHO. Thank you very much for all the great work (yes, all the rest! :-).
Comment 16 Till Schäfer 2020-07-02 13:42:05 UTC
(In reply to Florent Rougon from comment #15)
> I fully agree with comment #14. I love Okular, but having Page Up and Page
> Down take so much time is absolutely terrible. One can't reasonably browse
> through a largish PDF file anymore. Please restore quick Page Up and Page
> Down behavior. The animation I see in Okular 1.10.2 is a big usability
> regression for useless eye candy; that is a pretty bad tradeoff, IMHO. Thank
> you very much for all the great work (yes, all the rest! :-).

+1 
I would further stress, that the global animation speed is not good choice for the current implementation. Page Up/Down repeat rate should is not limited by the animation speed. This overrides the keyboard repeat rate, which is quite counter intuitive. Furthermore, it ignores some user input during the animation (e.g., a second key press) because the animation is not finished. This is rather disruptive. It makes you wait for the animation, you cant trust your intuition of fast input anymore. To make this more clear: imagine blocking a second alt+tab window switching because the animation is not finished...

Thus, I think the implementation should respect the following things:
- Animation should never block user input
- Animation should not limit scroll speed. 
- If animation is applied it should always animate to the scroll position where you would have been without any animation and without resource limitations (e.g. processor power to render the page). Thus, it is much more sensible to speak of animation time, rather than speed. The animated scroll speed should be faster if your press Page Up/Down multiple times to catch up to the desired scroll position. Currently this is vise versa.  
- Make it optional: Making an animation optional is not an unusual thing in KDE/Plasma. For example, the desktop effects can be enabled/disabled separately. While I usually like some animations, because they can actually increase the visual perception of what is happening, they should never stand in the way and hinder productivity. I would further not like to adjust the otherwise useful global animation speed to get rid of an annoyance in a specific application.
Comment 17 Nate Graham 2020-09-14 18:09:58 UTC
Git commit 2d6fafe25505b0f7a521cd867f41063f0ea73c5d by Nate Graham.
Committed on 14/09/2020 at 17:02.
Pushed by ngraham into branch 'master'.

Scale smooth scroll durations according to the global animation speed

Now people who don't like animations can set thenm to "Instant" globally
and smooth scrolling will be effectively disabled off in Okular.

There is no change in speed for people using the default global
animation duration.
FIXED-IN: 1.12.0

M  +7    -0    ui/pageview.cpp

https://invent.kde.org/graphics/okular/commit/2d6fafe25505b0f7a521cd867f41063f0ea73c5d
Comment 18 Nate Graham 2020-09-14 23:00:36 UTC
Re-opening since after discussion, this will require a setting in Okular's own UI for people not using it in Plasma.
Comment 19 nfxjfg 2020-09-17 08:47:37 UTC
> Re-opening since after discussion, this will require a setting in Okular's own UI for people not using it in Plasma.

As a user, I agree.

(Also, I guess page up/down doing a choppy scroll animation is still a separate bug?)
Comment 20 Bug Janitor Service 2020-09-21 20:15:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/282
Comment 21 Nate Graham 2020-09-24 13:44:30 UTC
Git commit 122528d3fe96f6f4962136accd06f2be1ee1b323 by Nate Graham.
Committed on 24/09/2020 at 13:43.
Pushed by ngraham into branch 'master'.

Add option to disable smooth scrolling

Even though the animated smooth scrolling transitions are now affected
by the global animation speed setting in Plasma, this is not totally
satisfactory for the full pool of people who hate smooth scrolling, as
it does not address the cases of people using Okular outside of Plasma
or people who generally want animations but just not in Okular's
scrolling implementation.

Accordingly, there is now a GUI option to disable smooth scrolling in
Okular's settings window.
FIXED-IN: 20.12

M  +7    -0    conf/dlggeneralbase.ui
M  +3    -0    conf/okular.kcfg
M  +6    -0    doc/index.docbook
M  +13   -1    ui/pageview.cpp

https://invent.kde.org/graphics/okular/commit/122528d3fe96f6f4962136accd06f2be1ee1b323