https://bugs.kde.org/show_bug.cgi?id=459467
Bug ID: 459467
Summary: WindowHeap-based transitions not consistent with
global animations
Classification: Plasma
Product: kwin
Version: 5.25.5
Platform: Archlinux
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: effects-various
Assignee: kwin-bugs-n...@kde.org
Reporter: breakingsp...@gmail.com
Target Milestone: ---
Created attachment 152298
--> https://bugs.kde.org/attachment.cgi?id=152298&action=edit
Patch to demonstrate all three animation duration values at once
SUMMARY
WindowHeap effects (Desktop Grid, Overview, Windowview) do not seem consistent
with the rest of KWin's existing effects. This was previously reported in
https://bugs.kde.org/show_bug.cgi?id=455521 with many notes in the comments,
I'll reiterate that this is the exact same issue as described in the other
report.
It's been suggested that this may be an issue only at fast global durations:
https://invent.kde.org/plasma/kwin/-/merge_requests/2948#note_527556, but I do
not believe this is the case as I can dial the global slider to the left and
observe the discrepancy even at slower durations. While I can't be 100% sure,
this does not seem to be an issue with compositor performance, framerate,
screen painting, or anything outside of simple duration timings/units.
I'm raising this bug to discuss this discrepancy and request feedback from more
people. There are surely more users and developers of the Desktop Grid that
noticed the animation speeds changing and know their old preference. Could
there be a lower-level function or logic unintentionally scaling the values?
I've also attached a patch for demonstration that will raise the Desktop Grid's
duration to 400ms and lower the Overview to 200ms, while leaving Windowview at
the current 300ms. All three effects can then be cycled between and compared
with the rest of the Kwin effects.
NOTES
The effect can be observed most easily on releases 5.24-5.25, where these
effects have a hardcoded duration value of 200ms. This duration was chosen
during development based on being a multiple of the standard Kirigami units, so
Overview and Windowview (replaced Present Windows) have used this duration
since their inception. The Desktop Grid was formerly keyed at 300ms, to note.
I noticed in the 5.24 beta that Overview (WindowHeap) seemed much too fast
compared to the existing Grid+Present Windows. When 5.24 was released, the
Overview effect's speed was still the same (too fast), but as a user of the
Desktop Grid, I was unbothered at the time. 5.25 switched the Grid over to the
new WindowHeap system, and suddenly the familiar Desktop Grid was "too fast" as
a result, using the same global animation duration value as I always had. I
use the Desktop Grid about every 5 minutes at work, often enough for a mouse
bind, so the effect was effectively broken for me.
My first attempt at a fix was simply to scale the value
`effect.animationDuration * 2` in the Desktop Grid's new QML source. This
restored the Grid to it's former feel without any other changes, but of course
did not affect the Overview and Windowview effects, and would not have been the
right fix.
I tried other scales in that early test without knowing which value they were
operating on yet: * 1.2 (240ms), *1.5 (300), * 1.8 (360), only * 2 (400) felt
correct and consistent.
In this semi-patched state, I bound these three effects to adjacent hotkeys and
would cycle between them one by one to ensure I wasn't going nutty. Desktop
Grid would perfectly match while Overview and Windowview would not. The effects
are always buttery smooth on 144hz screens when using default global KCM
Animation values, or plus/minus two ticks. They are simply faster than the
other effects by comparison (Open/Close, Minimize/Restore, Virtual Desktop
Slide, Slide Back).
I went back to the source after a few weeks of daily driver usage, and found
`setAnimationDuration(animationTime(200));` in each effect's source, increasing
it to 400 had the same effect as my previous * 2 scale attempt and appears to
be the right place to set this value. I researched further (full IDE+debugger
set up by now) and found that the earlier incarnation of the Grid ran at a
300ms duration. However, even 300ms is too fast, 400ms (or * 2) feels exactly
like the pre-5.24 effects did. 400ms seems like an extreme value considering
the old value of 300ms, but it matches right up.
I opened a MR with my findings, and it was considered and merged:
https://invent.kde.org/plasma/kwin/-/merge_requests/2781
We also uncovered improvements to the easing effects in the new Grid, and I
tested these against the old 300ms value to be sure, but they were not the root
cause of the discrepancy: Overview and Windowview already had the correct
easing. Once the change was in master and the neon testing ISO, I ran it on all
my machines for a final check, and was able to comment out a patch from my
personal build.
However, when building from latest master a few days ago to test the new window
placement improvments, I noticed right away that the change in
https://invent.kde.org/plasma/kwin/-/merge_requests/2948 has re-introduced the
inconsistency by lowering the duration to 300ms. At this point, I really did
think that I was going nutty, and forced myself to use the 300ms system for a
few hours. It did not feel not right, and I ended up changing it back for my
daily use.
STEPS TO REPRODUCE
1. Grab neon-testing-20220920-1824.iso (and optionally Kubuntu 21.10 or similar
with 5.22 for the last functional version of the old desktop grid)
2. Use the System Settings KCM to adjust the Animation Duration up and down,
and to set basic configuration for Desktop Grid+Virtual Desktops.
3. Engage the Overview (Meta+W), the Desktop Grid (Ctrl+F8), and Windowview
(Ctrl+F10) and compare to other effects such as Virtual Desktop slide.
OBSERVED RESULT
The WindowView effect transitions start and stop faster than the rest of the
Kwin effects.
EXPECTED RESULT
WindowView effects should match the rest of the system and feel consistent.
SOFTWARE/OS VERSIONS
Linux: Arch Linux 5.19.9
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
ADDITIONAL INFORMATION
I'm attempting a screen recording with OBS but can't record at an acceptable
framerate without configuring AMD hardware encoding first.
--
You are receiving this mail because:
You are watching all bug changes.
