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 *** STEPS TO REPRODUCE 1. In a Wayland session, set monitor refresh rate to 144 hz 2. Activate Present Windows OBSERVED RESULT Animation is very choppy and looks like it's running at (rough estimate) 60 FPS. Hard to tell, though, and the FPS meter effect doesn't seem to work right for me. EXPECTED RESULT Present windows animation runs at 144 FPS as in 5.24. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kernel 5.18.5 (available in About System) KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION This also seems to affect the Desktop Grid and Window Overview animations. All other animations run smoothly as before. Sorry if this is a duplicate.
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.
(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