SUMMARY Updated to v0.9.3 and the opening animations are extremely sluggish. It takes over a second for it to finish sliding up, and for the icons to be hoverable. STEPS TO REPRODUCE 1. Let the dock close 2. Move mouse to dock to open it 3. Observe slow slide up, and long time before icons show gover animations OBSERVED RESULT Animation to slide up, and time before icons are hoverable is over a second. EXPECTED RESULT Slide up animation is as fast as it used to be, the icons where, for practical purposes, immediately hoverable. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.17 KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.0.0-32-generic OS Type: 64-bit Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 31.4 GiB of RAM ADDITIONAL INFORMATION This occurred today after updating all packages. Changing the delay or animation speed have no effect on this.
Changing Compositor animation speeds also do not affect the docks opening speed.
Can you provide a video link through Google drive or dropbox?
Here you go. This is with the default 200ms open delay. https://drive.google.com/file/d/1JmLv6mMm5KI0dVwbZqA4KSLlFe9MyInM/view?usp=sharing Notice how the items are not selectable very quickly due to the extended slide-up animation time. The video doesn't really do justice to how awkward it is to use now compared to before.
I've downgraded to 0.9.1 and the same behavior persists. Mainly the icons now being hoverable before the dock animation completes. Which also causes an awkward sudden "jump" in the width and height of the dock, as they resize to their zoom level suddenly. Is this a 3rd party package problem? What packages would affect this? I can try and downgrade them till I find what changes.
I don't see any problem in your video. All this is intentional. The zoom animation is activated only when the slide in has ended. Anything else?
Like I said, the video does not do it justice. The slide-in is much slower than it used to be, which is a hindrance. And it does not seem to be configurable. I'm not claiming that the zoom animation waiting for the slide in is the bug here.
Are you referring to how much time it takes to start or how much it takes to finish the slide in from the moment that the dock will be first shown?
I'm referring to how much time it takes to slide in once triggered. This used to be an imperceivable delay (ie. It wasn't noticeable, didn't get in the way). On the same note, the slide-out speed is also equally as slow now, but that isn't really a problem.
This is intentional, only thing it could be changed is that the animation speed with value x2 will be the one you observe now and x3 a little bit faster, x1 will be a little slower. Of course that will also increase/delay all your animations
(In reply to accounts+kde from comment #8) > I'm referring to how much time it takes to slide in once triggered. This > used to be an imperceivable delay (ie. It wasn't noticeable, didn't get in > the way). > > On the same note, the slide-out speed is also equally as slow now, but that > isn't really a problem. just checked... you assumptions are not valid... Slide in/out animation is already configurable through Effects->Animations Speed value... If you set the animation speed to x3 then the slide in/out is accelerated...
Hi Michail, Looks like I was wrong about the animation speed affecting the slide out speed, largely due to the max speed still being slower than before (My dock was at 2x before I updated). Even at 3x it's still slower than it used to be. I would not consider this to be resolved, no resolution or conclusion has been made... The behavior of the dock has changed for unknown reasons, and that is okay? If anything, I'd like to discover WHY and WHAT caused the change, so I can further diagnose this. Working with me to further discover would be appreciated, rather than closing the issue down as fast as possible.
I will setup a VM with an older version of Neon to compare to prove or disprove what I've observed. I will report back here with those results, and a video if necessary.
feel free to prove your statements. For me the animation speeds provided for slide ins/outs are fine... The fact that have changed does not mean that the new animation speeds are not ok. (In reply to accounts+kde from comment #11) > The behavior of the dock has changed for unknown reasons, and that is okay? yes as long as this was in the 1000 commits that were introduced for v0.9 and at the same time animation slide-in it is ok... > If anything, I'd like to discover WHY and WHAT caused the change, so I can > further diagnose this. feel free to play with this... the animation speed for slide-in and out is located at line: https://phabricator.kde.org/source/latte-dock/browse/master/containment/package/contents/ui/VisibilityManager.qml$44 > > Working with me to further discover would be appreciated, rather than > closing the issue down as fast as possible. the bug is closed until there is a bug... The fact that a behavior has changed is not a bug. A bug is when the slide-in/out is so slow that breaks the user workflow. From you current video this is not observed.... One other thing you can try is to accelerate the animations speed for your plasma environment. For Plasma 5.17 this is located at plasma systemsettings, Display and Monitors, Compositor, Animations speed
waiting for videos/details/ways to reproduce etc...
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!