Bug 455489 - Window Open/Close Animation cannot trigger right away when just switching to another virtual desktop
Summary: Window Open/Close Animation cannot trigger right away when just switching to ...
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (other bugs)
Version First Reported In: 5.25.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-17 14:44 UTC by Angelo Fallaria
Modified: 2025-07-09 05:11 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Shows the animations not playing for a few seconds after switching virtual desktops (1.80 MB, video/webm)
2022-06-17 14:44 UTC, Angelo Fallaria
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Angelo Fallaria 2022-06-17 14:44:05 UTC
Created attachment 149861 [details]
Shows the animations not playing for a few seconds after switching virtual desktops

SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

When I switch to another virtual desktop, the window open/close animations do not trigger when I open/close a window for around three seconds after switching. They only start to trigger once I'm in the virtual desktop for more than three seconds. This is inconvenient as I switch between virtual desktops all the time in my workflow.

STEPS TO REPRODUCE
1. Set a Window Open/Close Animation in Desktop Effects settings
1. Switch from one virtual desktop to another
2. Open/close a window within ~2-3 seconds from switching

OBSERVED RESULT

Windows do not trigger their open/close animations, as if no open/close animation was set in the settings.

EXPECTED RESULT

Windows trigger their open/close animations as usual.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Artix Linux 5.18.3-zen1-1-zen (64-bit)
(available in About System)
KDE Plasma Version: 5.25.0
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4

ADDITIONAL INFORMATION

Graphics Platform: Wayland
Mesa version: 22.1.1-2
CPU/GPU: Ryzen 7 5700G
Comment 1 Angelo Fallaria 2022-06-19 07:25:48 UTC
Update: I've narrowed down the cause of the bug. When the virtual desktop switching effect (Fade/Slide) is still active, the window open/close effects do not play. If I disable the switching effects, the open/close animations trigger as usual.

So right now, I think the bug is that the virtual desktop switching effects and window open/close effects cannot play at the same time.
Comment 2 Răzvan Avram 2025-07-04 19:05:05 UTC
Not just window open/close animations are affected by this, but also the application launcher & applet animations. And it's a problem primarily when using the default Slide effect (since it takes quite long for the animation to end), the Fade desktop (although it has its own issues) is a bit shorter by default (and has a configurable duration as well).

Steps to reproduce (as of Plasma 6.4.2):
1) Enable virtual desktops
2) Switch to a different virtual desktop and then quickly open the application launcher
3) Observe the launcher appearing instantly without the usual opening animation
Comment 3 Răzvan Avram 2025-07-09 05:11:52 UTC
(In reply to Răzvan Avram from comment #2)
> Not just window open/close animations are affected by this, but also the
> application launcher & applet animations. And it's a problem primarily when
> using the default Slide effect (since it takes quite long for the animation
> to end), the Fade desktop (although it has its own issues) is a bit shorter
> by default (and has a configurable duration as well).
> 
> Steps to reproduce (as of Plasma 6.4.2):
> 1) Enable virtual desktops
> 2) Switch to a different virtual desktop and then quickly open the
> application launcher
> 3) Observe the launcher appearing instantly without the usual opening
> animation

I've opened a different bug for the applet animations here: bug 506779

Fixing this bug might not be as straight forward, as (unlike with applets) one might not want window animations to play in the middle of a desktop animation, instead queuing them to play afterwards.