https://bugs.kde.org/show_bug.cgi?id=386379
--- Comment #27 from Mark <mark...@gmail.com> --- @Patrick, thank you for marking my bug as duplicate of this. I couldn't find it. As for the bug itself, i had spend quite the large part of yesterday trying to understand what's going on with the scrolling in Dolphin and why it just doesn't feel smooth. First off, i don't think the 3-line-scroll is bad. Not even with big icons. It's just "how" the scrolling is done (it seems to "jump" with no animation or a very VERY short animation) which makes it look bad and makes you lose focus of where you are. I too find myself often grabbing the slider to scroll these days as scrolling with the mousewheel is just not a pleasant experience anymore. I don't fully understand it yet, but i have some findings that might be of interest. 1. Dolphin does in fact animate the scrolling with whatever the style's value for QStyle::SH_Widget_Animation_Duration is. See: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/private/kitemlistsmoothscroller.cpp#n37 That on it's own is doubtful as scrolling is most certainly something else compared to fading in or hover effect animations. I don't think that value should be used for scrolling. 2. In the same file (here to be exact: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/private/kitemlistsmoothscroller.cpp#n127) you can see that Dolphin uses the QEasingCurve::InOutQuad for a scroll animation and QEasingCurve::OutQuad for when you scroll _during_ an already running animation. The InOutQuad is likely causing some troubles as the duration is short, it starts of slow, then moves fast and ends slow. This can feel a bit jumpy with too short animations. Perhaps experiment with other curves if the animation time is kept as is. 3. The scrolling animation time itself. I'd say that the current animation is absurdly short. It's only sane in details view with small icons. I would advice to reconsider the animation logic and perhaps set it at 300ms. 4. Another cause for concern is re-layouting (code: https://cgit.kde.org/dolphin.git/tree/src/kitemviews/kitemlistview.cpp#n1650). If i understand the workings of the scrollview implementation correctly (it's a custom-made one on top of QGraphics*) then re-layouting is a fact we can't get around. You basically have a width x height view that is as large as your current viewport. Meaning that the viewport does not change when you scroll. Rather, the items within that viewport get a new X and Y position for every animation tick hence every animation tick needs a re-layout to make items visible and at the correct position while scrolling. It's a smart mechanism! But also really sensitive to changes. Now you know a bit about the re-layouting which makes explaining a bug i encountered in it a bit more easier to explain. When you scroll (and set the animation to something long) you can observe the items that are being scrolled to seemingly move back a pixel then jump forward two pixels at least ince during the animation. That is a bug in the re-layouting (i think). It could be as simple as an int rounding thingy where it should be a float, but it could also be as complex as just missing the animation frame. I'm assuming this alone causes a slightly jaggy scroll movement. Still it's extremely minor and you literally have to hug the screen at millimeters distance to notice it (and change the code to have longer animations) but it's there. This would explain a "it animates and looks smooth but doesn't feel smooth" experience. 5. Also for the re-layouting. It can use improvements to be as lightweight as possible. Right now it tries to show new items on every animation tick, that can be optimized to only do that if the next frame is going to show an item that isn't visible already. Also, the re-layouting runs on the GUI thread. You want to keep it as minimal and efficient as possible. Most notably, https://cgit.kde.org/dolphin.git/tree/src/kitemviews/kitemlistview.cpp#n1691 is (when you go into the recycleInvisibleItems function) looping through _all_ items on every animation tick to only determine if it can re-use items. Just to figure out that in - say - 80% (just a guess, depends on the animation and scroll speed) of the time it didn't need to know at all. That's as far as i went this time. What would be valuable to know is if we're making each animation frame in time. For instance, we could lose a frame (which causes jaggyness) if the above mentioned re-layouting is too expensive. Which i think it is in LARGE folders (say 100.000+). -- You are receiving this mail because: You are watching all bug changes.
