https://bugs.kde.org/show_bug.cgi?id=525187
Bug ID: 525187
Summary: KWin full-scene animations become extremely slow with
many visible windows
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: CachyOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: performance
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
Several KWin animations become progressively slower as the number of visible
windows on the affected virtual desktop increases.
This affects at least:
- virtual desktop switching using the Slide effect
- virtual desktop switching using the Fade effect
- Magic Lamp minimization
- animations when many visible windows are closed at once
The issue does not affect ordinary window movement.
With the exact same desktop containing approximately 15-20 visible windows,
KWin can maintain the full ~175 FPS refresh rate while moving a window,
including
with effects such as Wobbly Windows enabled. However, animations that affect
the
desktop/scene can drop as low as approximately 25 FPS.
The slowdown depends on the number of visible windows rather than the number of
running applications. For example, having a very large number of applications
running does not cause the problem if their windows are minimized.
Minimizing most of the visible windows immediately restores smooth animation
performance.
STEPS TO REPRODUCE
The Slide virtual desktop effect provides the easiest reproducible and
measurable
case:
1. Start a Plasma Wayland session.
2. Enable the standard KWin "Slide" virtual desktop switching effect.
3. Enable KWin's Show FPS diagnostic effect.
4. Use a high refresh rate display. My display runs at 175 Hz.
5. Create at least two virtual desktops.
6. Leave only 2-3 visible windows on the desktops involved in the transition.
7. Switch between the desktops using Slide.
8. Observe that the animation runs at approximately the full display refresh
rate (~175 FPS on my system).
9. Open approximately 15-20 visible windows on one of the desktops.
10. Move a window normally on that desktop and observe that KWin still
maintains
approximately 175 FPS.
11. Switch to/from that desktop using the Slide animation.
The issue is reproducible on demand.
OBSERVED RESULT
With only 2-3 visible windows, Slide runs at approximately the display refresh
rate (~175 FPS).
With approximately 15-20 visible windows, Slide can drop to roughly 25 FPS and
becomes visibly very stuttery.
With those exact same 15-20 windows still visible, simply moving a window
around
the desktop remains at approximately 175 FPS.
The problem is local to the virtual desktop containing many visible windows.
A different virtual desktop containing only a small number of visible windows
remains smooth.
Minimizing most of the windows immediately restores smooth Slide performance,
even though all of the applications remain running.
OTHER AFFECTED ANIMATIONS
The issue is not specific to the Slide effect.
I can also reproduce increasing stutter as the number of visible windows grows
with:
- Fade virtual desktop switching
- Magic Lamp minimization
- closing many visible windows at once
Completely disabling animations avoids the issue.
Normal movement of individual windows remains smooth even on a desktop where
the affected animations perform poorly.
EXPECTED RESULT
KWin animations should remain reasonably close to the compositor refresh rate
with this number of visible windows on hardware that can otherwise render the
same desktop at the full refresh rate.
In particular, having approximately 15 visible ordinary application windows
should not cause an animation to fall from ~175 FPS to ~25 FPS when ordinary
window movement on the same scene remains at ~175 FPS.
SYSTEM INFORMATION
Plasma: 6.7.4
KWin: 6.7.4
Session: Wayland
Compositing Type: OpenGL
OpenGL platform interface: EGL
GPU: AMD Radeon Pro W7500 / Navi 33
Driver: RadeonSI
Display refresh rate: 175 Hz
Example renderer information:
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon Pro W7500 (radeonsi, navi33, ACO)
OpenGL version: 4.6
ADDITIONAL TESTING
KWin CPU usage remains low during the problem.
The main kwin_wayland process remains at approximately 6-7% CPU even when the
animation is heavily stuttering.
GPU monitoring with amdgpu_top shows short high-utilization bursts during the
affected animations, while ordinary window movement remains smooth.
GPU clock scaling works correctly. The GPU raises its clocks under load, and
forcing the GPU performance level to "high" does not improve the problem.
The behavior was reproduced with both:
- Mesa 26.2.2
- Mesa 26.1.5
with no meaningful difference.
It was also reproduced with both:
- Linux 7.2.x
- Linux 6.18 LTS
with no meaningful difference.
Other tests that did not meaningfully affect the problem include:
- disabling Blur
- disabling Night Light / color-management related features
- forcing high GPU performance clocks
- changing between Mesa 26.1.x and 26.2.x
Therefore this does not appear to be a general GPU performance, power
management,
Mesa-version, or kernel regression.
DIAGNOSTIC KWIN BUILD
I also built a locally instrumented KWin 6.7.4.
During Slide, the number of paintWindow calls clearly increases with the number
of windows participating in the transition.
For example, depending on the involved virtual desktops and render passes, the
diagnostic build reported values such as:
KWIN_SLIDE_DIAG paintCalls=5
KWIN_SLIDE_DIAG paintCalls=10
with a small number of windows, and values such as:
KWIN_SLIDE_DIAG paintCalls=21
KWIN_SLIDE_DIAG paintCalls=42
KWIN_SLIDE_DIAG paintCalls=63
with a desktop containing many visible windows.
I do not interpret these values as a direct count of unique windows per frame
because multiple outputs/render views can contribute to the count, but they
demonstrate that the amount of work performed by the Slide path grows strongly
with the number of participating windows.
PROOF-OF-CONCEPT / DIAGNOSTIC EXPERIMENT
As a diagnostic experiment specifically for the Slide effect, I modified
SlideEffect to use KWin's existing OffscreenEffect infrastructure.
The modified SlideEffect inherits from OffscreenEffect and redirects the
windows
that participate in the virtual desktop transition. This allows the
participating
windows to be rendered into offscreen textures and reused during subsequent
frames of the animation, with the texture being updated when the corresponding
window is damaged.
With this modification, and with no other system changes, the Slide performance
problem disappears on the tested system.
The same desktop and the same number of visible windows that caused the stock
Slide effect to drop to approximately 25 FPS become smooth again after this
change.
This proof-of-concept is not intended to imply that this exact implementation
is necessarily the correct upstream solution, or that the same approach should
automatically be applied to every affected effect.
However, it demonstrates that repeatedly processing/rendering the windows
participating in the animation appears to be a major contributor to the
performance problem, and that reusing KWin's existing offscreen texture
infrastructure can eliminate the bottleneck for Slide.
The wider issue appears to affect multiple animations, not only Slide, so there
may be a more general optimization possible in KWin's handling of effects that
require transformed/full-scene rendering.
I can provide the proof-of-concept patch and additional measurements if useful.
--
You are receiving this mail because:
You are watching all bug changes.
