https://bugs.kde.org/show_bug.cgi?id=455521
--- Comment #14 from Alexandre Pereira <pereira.a...@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. Its strange, here it was "on par" with other effects, which I then used a 1.4 animation factor ( one tick just to the left of default ). > 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. Yes, i agree, the extreme values are way ... extreme :) If Nate has no issue, I could supply a patch to make it less "extreme" and more granular. Its extremely weird, because the other effects are all around 150ms~200ms. even old present windows. And here is very very noticeable. > 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. I can try a kde neon live cd in the weekend or earlier if I can. But that setting is correct here. I tend to keep an eye on it, because there was a bug that used to reset it, which David Edmundson fixed. ( he also fixed other bugs, like this one: https://invent.kde.org/plasma/kwin/-/commit/0bb3eb2baf5b0a4c0aacbe23bf55c47c0a2c39fd ). Just to clear one possible issue, you are also using kde git version, correct? Also as a workaround, the slide/glide effect allow to specify the duration. Overriding it to 400 makes it more similar in timings to the overview/present windows now. So something weird is happening here... I don't know if its not my system at fault, but I checked the kwinrc variable (it should NOT have one) and the kdeglobals one (which can actually be a custom number if one edits it manually). -- You are receiving this mail because: You are watching all bug changes.
