Bug 455585

This is a pretty noticeable regression. Is there anything else I can provide to help get this fixed ASAP?

Is the new Desktop Grid effect the same? How about the Overview effect? I ask because they all use the same basic backend infrastructure code, so knowing which ones are affected--or all--will help us understand where this needs to be fixed.

@Nate Ever since the introduction of all those effects you mentioned (that are based on one codebase as i understand) they are very choppy while invoking.( on 60hz monitor they dip to 30fps -at least this what frame counte effect shows) but it "feels" like its just few frames from invoking to the end of animation. I have a older pc with nvidia graphics and i cant run wayland  so im running X11( your recent changes made sure of it) but the previous implementation of the effects worked smoothly without any issues. I can provide more info if needed.

(In reply to Nate Graham from comment #2)
> Is the new Desktop Grid effect the same? How about the Overview effect? I
> ask because they all use the same basic backend infrastructure code, so
> knowing which ones are affected--or all--will help us understand where this
> needs to be fixed.

Yup, they're all affected. Basically anything that incorporates Present Windows seems to be affected the same way, and the problems only started as of 5.25.0. In fact, after noticing that the overview effect performed similarly in 5.24.5, I assumed it'd somehow gotten enabled in place of the present windows effect, so I think the new backend code is the likely culprit here.

*** Bug 455763 has been marked as a duplicate of this bug. ***

Want to add this detail from my bug report here too: After several minutes using the session, the effect’s FPS improve! This is always reproducible for me. Like there was a handbrake and then it’s suddenly gone.

This is not a matter of refresh rate. If you set the animation speed (startpage of system settings) to the lowest possible setting, you can exactly see the stutters, because they are way slower as the whole animation takes more time. With this we can conclude that it isn't tied to the refresh rate but stutters in general.

This is a wild guess, but maybe it is due to doing rough rounding? That would probably lead to an uneven, stuttery animation....

(In reply to Maximilian Böhm from comment #6)
> Want to add this detail from my bug report here too: After several minutes
> using the session, the effect’s FPS improve! This is always reproducible for
> me. Like there was a handbrake and then it’s suddenly gone.

Just for completeness's sake, I have not had this experience, but that sounds like how the whole compositor used to run for me back in 4.x and early 5.x.

*** This bug has been marked as a duplicate of bug 451590 ***

The behaviors mentioned in bug 451590 do not match the ones I'm running into.

*** Bug 455930 has been marked as a duplicate of this bug. ***

Update: I forgot to mention I have two monitors with different refresh rates. On the slower monitor (75hz), the effects seem to run as expected, but on the faster one (144hz) I think they may be running at 75 hz as well.

I've got the same bug on a 144Hz display and it applies to any of the effects that are using the new Overview effect code including Overview, present windows, and show virtual desktops. The older present windows & show virtual desktop effects on Kwin 5.24 were extremely smooth and the difference is very noticeable.

I'll note that other effects outside of the Overview effect like switching desktops or moving/resizing windows are still smooth like expected for a 144Hz display, and I have confirmed that the display actually runs at 144Hz with the built-in refresh rate monitor tool.

Notes: Kwin 5.25.3 [just updated today], Arch Linux, AMD Graphics with 5.18 kernel and latest Mesa.

I'm on Arch Linux with Plasma 5.25.3, x11 session, nvidia rtx2080 and 3 monitors (2x 1440p, 1x 1080p) and desktop at 165Hz with FPS indicator showing.

When I move my mouse to the top left corner it is hit or miss if it activates the effect. It seems to trigger partially and show the search box pop up on one screen, but just the search box pops in and out with a couple of the windows changing stacking order. While this is happening the FPS is fluctuating. If I keep pressing the mouse in the top left corner for > 3 seconds I get the full effect to trigger.  I think it's something about how "perfect" you move your mouse onto that top-left-most pixel without it bouncing around.

When I use a global keyboard shortcut the effect works every time, but using a stopwatch it seems like my screen does not show any sign of changing for a whole 1 second after the keyboard buttons have been pressed. FPS will be 165Hz during this 1 sec, then it will drop down to 20s briefly as the effect happens.

*** This bug has been marked as a duplicate of bug 451590 ***

(In reply to David Edmundson from comment #15)
> 
> *** This bug has been marked as a duplicate of bug 451590 ***

A significant change was made in 5.25.4 with 63bf8112006acb37504c5d0b0cc850a74d3eb1da that improves performance a lot in some situations. I'll close this bug report as being affected by that.

Performance may still not be perfect, and we'll continue to iterate on that over time.

When re-opening a resolved issue, please explain why, what you're seeing, what happens now, etc.

Sorry, I never hit "Save" on my response!

I don't think this was affected by the linked commit. On the surface, this looks like it's simply grabbing the wrong refresh rate, as the animation is always smooth, but running at a framerate that looks like exactly 60 FPS. From setting my monitor to 60 hz and eyeballing the animation smoothness, I can confirm that the appearance is consistent with the behavior I've observed with the Present Windows effect. If someone is willing to point me in the right direction, I'd be happy to give it a whirl myself.

According the the FPS counter Kwin effect, the WindowHeap effects are running @ ~144 Hz. But counter-testing with a 60 Hz monitor setting, I can confirm that there seems to be no difference. To my eyes, its rendered in 60 fps. The Plasma 5.24 effects were much smoother. Thanks for the reopening, I was just glad before that the speed-up issue in 5.25 was fixed… Tested on Plasma 5.26.0.

I have to correct myself: After several minutes, the rendered FPS improve to my eye. I have reported this phenomenon before in a issue with Plasma 5.25+. When I switch back to 60 Hz, the 60 Hz now look significantly worse. It’s like there is a blocker on a new session limiting the rendering to 60 fps and after a couple minutes, they are unleashed.

(In reply to Tim Robertson from comment #19)
> I don't think this was affected by the linked commit. On the surface, this
> looks like it's simply grabbing the wrong refresh rate, as the animation is
> always smooth, but running at a framerate that looks like exactly 60 FPS.

(In reply to Maximilian Böhm from comment #21)
> It’s like there is a blocker on a new session limiting the rendering to 60 fps
> and after a couple minutes, they are unleashed.

I'm encountering this in 5.26, while 5.25 did not seem to have this problem for me. 
After starting Kwin, the Windowheap effects are choppy, and after a few minutes it corrects itself, I can't tell yet if a certain action causes it to sync up, or if it's simply time. This can be reproduced by simply restarting Kwin in-session.

Interestingly, i'm only encountering this in my personal user profile and newly-created test profiles, while my existing work user does NOT encounter any choppy animations/framerates at all. I can restart Kwin in the work profile, all effects are seemingly 144hz as usual. I want to look over config/cache in case anything there is a factor, as the two profiles should have an identical Kwin config (aside from window rules and related).

*** Bug 448266 has been marked as a duplicate of this bug. ***

The state of this bug is still like in my comment 21.
Interesting additional finding: Wanted to try out the Kwin script "Exquisite", a tiling overlay. After session relogin with this Kwin script activated, my Kwin WindowHeap effects speed @144 Hz is once again highly accelerated, at least 2x. Removing the script has fixed it.

Can confirm in Plasma 5.27.9 with a 100Hz monitor plugged into an AMD card. However, a workaround exists in bug 448538 comment 6 where dragging any window to either the left or right edge causes the choppy framerate in WindowHeap-based effects to stop, which I was able to reproduce successfully.

*** This bug has been marked as a duplicate of bug 455780 ***

(In reply to David Edmundson from comment #26)
> 
> *** This bug has been marked as a duplicate of bug 455780 ***

No David, this isn’t a duplicate of bug 455780. The problem isn’t a slight delay in activation, but a totally wrong framerate!

(In reply to Maximilian Böhm from comment #27)
> (In reply to David Edmundson from comment #26)
> > 
> > *** This bug has been marked as a duplicate of bug 455780 ***
> 
> No David, this isn’t a duplicate of bug 455780. The problem isn’t a slight
> delay in activation, but a totally wrong framerate!

I completely agree. The workaround I mentioned in comment 25, which I suspect that posting it led to getting this bug marked as a duplicate, has *nothing* to do with delays in activating such effects.

I’m fairly confident about this mistake and now I’m reopening this issue. Way too important to let this bug sweep under the carpet.

Confirmed that this is still an issue for me as well on 5.27.9, and that the steps in https://bugs.kde.org/show_bug.cgi?id=455585#c25 do work to correct the framerate on these Windowheap effects. I didn't realize this was the fix until the recent comment, my workflow always involved tiling windows like this within the first few minutes of a session.

This is the old "Workspace Behavior -> Screen Edges -> Tile: Windows dragged to left or right edge" behavior, to note. Now it makes me wonder if there's a line or function in that tiling code to check the monitor refresh rate, which could affect other effects.

Created attachment 163736 [details]
Overview effect with choppiness slowed down from 100Hz to 60Hz

I finally had the chance to provide video evidence of this bug. Here I slowed the original footage from 100 FPS to 60 FPS using Avidemux and reencoded it to make the file size fit below the 4MB limit. If you look through the video frame by frame, you'll notice that there are missed frames in the transition going in and out of the Overview effect. Every 2-3 frames appear to be a duplicate of the previous one, which indicates that the effect ran about 60 FPS instead of the expected 100.

Created attachment 163737 [details]
Expected behavior after dragging window to edge, slowed down from 100Hz to 60Hz

After upgrading to Plasma 6, it now occurs consistently with the Overview effect on Wayland, even after performing the window drag workaround outside the effect. What's interesting this time is when I drag any window in Overview, it moves with the cursor at the expected full 100 FPS until I release my mouse button. I've also upgraded my GPU from a Radeon 570 to a Radeon 6750 XT since the previous comment while keeping the same 100 Hz monitor, so I'm still using the same AMDGPU graphics driver.

I haven't tested it on X11 but getting this fixed for Wayland at the very least would be great, since it's the path forward for windowing systems these days.

UPDATED SYSTEM INFO:
Plasma version: 6.0.2 (waiting for 6.0.3 to be released in my distro)
Frameworks version: 6.0
Qt version: 6.6.2

Plasma 6.0.5 behaves as the previous comment says
"Show FPS" desktop effect is always showing 144 fps or very close to it.
And in general moving windows around or switching workspaces behaves as expected.

But overview animations look like they run at 60 fps, while "show fps" still always reports 144 fps.
However, dragging windows within the overview is done at 144 fps. The only animations that are locked to low framerate are opening the overview and moving between workspaces in the overview.

when I say "workspace" I just mean "virtual desktop" btw

Can you try again with Plasma 6.1, to be released next week? The new triple buffering makes these effects buttery-smooth for me even with my weak Intel HD620 iGPU.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

I finally updated to Plasma 6.1, but the choppiness in the Overview and Present Windows effect are still there. I also noticed the same exact behavior in the new Edit Mode interface.

I'm still at 6.0.5 but I switched to x11 because wayland breaks some things I currently need to run, and I remember reading somewhere that triple buffering was already enabled on x11 which means animations should be smooth, but they actually work exactly the same as they do on wayland, most animations are smooth but overview looks like it's locked to 60hz.

Yeah I'm not sure this is a frame scheduling issue anymore. Feels more like actually bad performance in the effects themselves, like they're doing too much while animating and slowing down the system. It wouldn't be the first time that exact thing happened, and we fixed a prior occurrence of it already.

FWIW I can still reproduce this issue a bit with my hardware (HD620 iGPU + 4K screen @ 225% scale). It's nowhere near as bad as it was before, and quite tolerable now. But still not what I'd call buttery smooth. Downgrading severity and marking as CONFIRMED again.

One thing that makes it sound like it's not a real system slowdown is that "show fps" desktop effect still shows 140+ fps during animations. Also while I was trying to confirm this again on X11 just now everything was working perfectly smoothly! But then I logged out and logged in and it's back to "60fps" again. So far I have no idea what could have temporarily fixed it. Turning on the fps counter wasn't it, and running a fullscreen game that I played during previous session which restarts the compositor cause it's off when the game is running also wasn't it, not was suspend.

I have radeon rx6600 here and 1080p here btw

(In reply to Nate Graham from comment #40)
> FWIW I can still reproduce this issue a bit with my hardware (HD620 iGPU +
> 4K screen @ 225% scale).

What is the refresh rate of your display? Most of us here including myself are using displays that run at least 75 Hz.

ShowFPS does show an FPS drop for me. Also, CPU usage spikes while activating the effect. If I remember correctly, one core jumps to 100%. I run on a 3440x1440 display with 75hz. During activation, showFPS showd around 30 fps.

60hz for me.

Still an issue for me, 1440p144hz on RX 580. Confirmed the issue has been persistent since Plasma 5, with the snapping workaround no longer viable in 6. 

I do not believe this is a performance bug, when it worked in 5.x it was quite smooth and did not seem to particularly hit system resources. Every other kind of transition Kwin uses (virtual desktop slide) are smooth and buttery while.

Doubling down on the old workaround and how it can probably help: 
After quick-tiling the first window in a 5.27.5 session, the Windowheap refresh rate would sync up for the whole rest of the session. If this wasn't done, the effect would seem to be locked at 60fps. 

Whatever routine or check was part of that quick tiling operation in 5.x, I'd be willing to bet it will work in 6.x if we call it explicitly.

I can also still reproduce this issue on 6.1.3 with a 165hz Monitor.

Some findings regarding the different "big" effects.

Overview:

Oops, accidentally submitted trying to tab.

Overview:
- Opening and closing clearly runs at 60fps (comparing it to my 60hz monitor right next to my 165hz one), while Show FPS shows minimal frame drops
- Switching workspaces in the overview at 60fps.
- Dragging a window moves and resizes the window at the correct framerate, releasing it makes the window "jump" back at 60fps.
- There is no stuttering. Were my display 60hz, I would consider this effect very smooth.

Grid View:
- Pretty much exactly the same as the overview including the thing with window dragging.

New Edit Mode:
- Opening and closing runs at 60fps (probably), but has more general stutters than the other effects. It seems like making my panel non-floating made it a little smoother, but it's inconsistent.
- Opening the panel settings where it opens the window and moves the desktop out of the way to make space runs at the correct framerate.
- Opening the "Add Widgets" sidebar also pops it into view at the correct framerate.

With Plasma 6.1.4, the Windowheap slowness/stuttering has improved markedly in X11 (likely due to the new triple buffering) and the effects seem to sync with the monitor as close as it can. 

I still encounter slowdowns in roughly 1 in 10 interactions with the Overview+Grid though. I open the effect every 5 minutes during work so I notice anything odd with it, and this stands out. The GPU load doesn't spike during these slowdowns but CPU load for kwin_x11 does. I notice other users in this thread reporting CPU spikes, perhaps a single routine or condition in the Kwin process isn't being offloaded to GPU properly? 

The "Show FPS" Kwin counter stays at 144hz so I don't believe it's accurate to this issue, it may just be reporting the monitor rate? To note, I have AMD "Tearfree" enabled in X11 config, but toggling it off doesn't seem to make a difference.

The slowdowns occur with both the new "Smart" window layout, as well as the older Natural layout, so the positioning algorithm likely isn't the cause, the window positions are already chosen when the slowdown hits. I'm close to having a nested kwin debugging environment set up, so I'm hoping I can read and catch what exactly causes the slowdown.

It does sound like Paul's report is what we're experiencing. There are seemingly two types of animation lag in Windowheap effects that are being discussed in this report:

- Session starts, animations stuck at 60fps/hz. Something during the session will correct this for the remainder of that session: quick-tile, custom tile, something fixes the effect and syncs it up. I haven't been able to replicate this fix since Plasma 6.0, and don't encounter it often. 

- Animations sometimes hitch and stutter, seemingly related to CPU usage. I encounter this much more following 6.1.

Animations in general being stuck at 60hz is something different — a broader issue than just the issue affecting WindowHeap-based effects. That needs its own bug report.

Thanks Nate, I opened bug #493208 for my issue.

(In reply to Nate Graham from comment #53)
> Animations in general being stuck at 60hz is something different — a broader
> issue than just the issue affecting WindowHeap-based effects. That needs its
> own bug report.

Right, this bug is specifically for Windowheap effects (Overview, Grid, Present Windows, etc). 
There may be need of a separate bug for the CPU spike behavior i'm newly experiencing in 6.1, because it seems distinct from whatever issue causes the 60fps "lock". 

Do we have examples of which non-Windowheap effects/components are affected? If I can confirm any of them, I'll open a report for those. For instance, I use Slide Back for overlapping windows and it's never suffered from any performance hitch.

(In reply to Blazer Silving from comment #55)
> (In reply to Nate Graham from comment #53)
> > Animations in general being stuck at 60hz is something different — a broader
> > issue than just the issue affecting WindowHeap-based effects. That needs its
> > own bug report.
> 
> Right, this bug is specifically for Windowheap effects (Overview, Grid,
> Present Windows, etc). 
> There may be need of a separate bug for the CPU spike behavior i'm newly
> experiencing in 6.1, because it seems distinct from whatever issue causes
> the 60fps "lock". 
> 
> Do we have examples of which non-Windowheap effects/components are affected?
> If I can confirm any of them, I'll open a report for those. For instance, I
> use Slide Back for overlapping windows and it's never suffered from any
> performance hitch.

As of 6.2, it seems only the Overview effect is affected for me. My hardware is the same as before (7900xtx, 5950x), now running on Fedora Kinoite 40. Notably, my Framework 13 seems unaffected, but that has a 60 hz screen so that tracks.

(In reply to Tim Robertson from comment #56)
> As of 6.2, it seems only the Overview effect is affected for me. My hardware
> is the same as before (7900xtx, 5950x), now running on Fedora Kinoite 40.
> Notably, my Framework 13 seems unaffected, but that has a 60 hz screen so
> that tracks.

My hardware is an Optimus (Intel UHD graphics and NVIDIA RTX 3060) laptop with a 144hz monitor, running on Arch with Plasma 6.2 Wayland and the Overview also experiences the stuttering, while all the other effects (afaik) run smoothly.

Another behavior that I have with the Overview effect is that when I activate the Overview with the touchpad, it is always smooth UNTIL I release my fingers and let the animation finish by itself, which becomes choppy again.

For everyone following this thread, there may be a fix in upstream qt6 found in BUG 485927. 

Thrilled if this is all it takes to fix this issue. So far, Overview+Grid are butter smooth for me with no interventions after patching and installing qt6-base.