https://bugs.kde.org/show_bug.cgi?id=455521
--- Comment #13 from breakingsp...@gmail.com --- Interesting, I wonder if another factor is at play or causing the scaling to be wrong in cases. On my system and liveCD tests, the merged changes to duration and easing cause the WindowHeap transitions to match every other effect, when they didn't before. Even the old duration of 300ms is too quick. I just spun up a new local user with no config, tried plus and minus 2 ticks on the global Animation Speed slider, and compared the Overview and Desktop Grid against the open/close Window Animations (Fade, Glide, Scale) and Minimize effects, they still match up for me and look very consistent. Even extremes on the scale match up, and i'm honestly wondering why the scale is so large as the center 5 ticks are the most distinct. Could something in config be overriding the duration and throwing things off on some environments but not all? For instance, I removed this line in my config a year or so ago (around 5.23 release when things regressed) to fix the issue in the title: https://bbs.archlinux.org/viewtopic.php?id=263845. It makes me wonder if a similar thing is occurring with the Windowheap effects for some users, possibly even the systems that 400ms look good on (liveCD though..) I've also tested the durations with a 60hz laptop while on a trip this last week, to rule out higher refresh displays being an edge case. -- You are receiving this mail because: You are watching all bug changes.
