View Issue Details

IDProjectCategoryView StatusLast Update
0015039MediaMonkey 5Generalpublic2021-10-18 16:01
Reportermichal Assigned To 
Status resolvedResolutionfixed 
Product Version5.0 
Target Version5.0.2Fixed in Version5.0 
Summary0015039: Add option to switch smooth scrolling off.
DescriptionWe use smooth scrolling, which is more fluent, but some users prefer previous scrolling (scrolling line by line, in discrete steps). We should add option to Options - General for this.
Additional Information
TagsNo tags attached.
Fixed in build2121


related to 0018191 closedLudek Scrolling in the Filelisting isn't smooth 



2018-08-20 12:44

developer   ~0050943

Fixed in build 2121.


2018-09-14 02:49

developer   ~0051110

Verified 2121


2021-02-08 00:44

developer   ~0061799

Disabling smooth scrolling no longer works as expected in build 2304. The scrolling behavior *does* appear different when smooth scrolling is disabled versus when enabled, but it still animates. (Note that the checkbox is now under the Performance panel, as decided in 0017134)

Performance optimizations can be quite important for people with old/slow computers, as was brought to my attention in this post:


2021-02-08 13:52

developer   ~0061802

There is not any animation, I am not sure what to do more, it is simply raw scrolling without smoothing animation steps.


2021-02-08 20:05

administrator   ~0061807

Last edited: 2021-02-08 20:06

View 2 revisions

Tested 2304:
I can confirm that on my system, enabling/disabling 'smooth scrolling' has no performance impact (intense scrolling with the mouse wheel of the Music [List] view yields 0000025:0000040% utilization in either case.


2021-02-08 20:24

administrator   ~0061808

Technically the difference is that either we do the scrolling ourselves ('smooth'), or leave it to Chromium. Chromium implementation is currently also quite smooth, even though slightly different (and a bit less smooth imho).

This leaves the option somewhat less useful, but I guess we can leave it there as is and possibly decide later whether to completely remove it?


2021-02-08 20:31

administrator   ~0061809

Last edited: 2021-02-08 20:36

View 2 revisions

OK, pushing to 5.0.1. This implementation doesn't solve the problem that it was intended to solve so we should:
a) decide which of the 2 implementations to standardize on (if there's no usability or performance difference)
b) determine if there's a solution to the high CPU utilization problem and if there isn't, remove the option entirely from performance options


2021-02-09 15:12

developer   ~0061824

Last edited: 2021-02-09 15:19

View 4 revisions

I'm pretty sure that the setting in previous builds caused scrolling to not be smooth/animated at all. When that happened, I noticed that CPU usage while scrolling was around half when it was disabled versus when enabled. I'll double check...

Edit: Check build 2273. When smooth scrolling is disabled (it's in the General panel in that build), it takes discrete steps instead of scrolling smoothly. There is a significant reduction in CPU usage. (Could it be due to Chromium flags?

Re: point a) I think that the custom smooth-scroll animation is more pleasant than Chromium's built-in smooth-scroll animation.


2021-05-25 12:25

administrator   ~0063458

My latest test shows that there's a visible difference in scrolling (the native not as smooth) and a slight difference in performance (nothing drastic though). I'd leave this option there for now and re-evaluate for future releases.


2021-10-14 00:20

administrator   ~0065188

On my (relatively underpowered) system when scrolling:
- list view: Smooth scrolling enabled: 30%, Smooth scrolling disabled: 21%
- list (by album) view: Smooth scrolling enabled: 25%, Smooth scrolling disabled: 24%
- Grid view: no difference

But in the first 2 cases, smooth scrolling is a much better experience since it doesn't result in the list getting 'stuck' periodically. This is currently the default option, so this issue can be resolved (we can leave the option for those users that prefer the slightly reduced CPU utilization of the 'internal' implementation).