View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015039 | MMW 5 | General | public | 2018-08-20 12:00 | 2024-03-28 15:42 |
| Reporter | michal | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.2 | Fixed in Version | 5.0 | ||
| Summary | 0015039: Add option to switch smooth scrolling off. | ||||
| Description | We 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 | http://www.mediamonkey.com/forum/viewtopic.php?p=448451#p448451 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2121 | ||||
|
|
Fixed in build 2121. |
|
|
Verified 2121 |
|
|
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: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=98325 |
|
|
There is not any animation, I am not sure what to do more, it is simply raw scrolling without smoothing animation steps. |
|
|
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. |
|
|
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? |
|
|
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 |
|
|
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? https://www.tenforums.com/tutorials/112915-enable-disable-smooth-scrolling-google-chrome.html) Re: point a) I think that the custom smooth-scroll animation is more pleasant than Chromium's built-in smooth-scroll animation. |
|
|
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. |
|
|
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). |
