| Summary: | Stutter on right-most screen of multi-screen setup when opening WindowHeap-based effects | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Eric Edlund <ericedlund2017> |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bastimeyer123, bednarczyk.pawel, bmanbros, hestonchicken, hugh.garse, kde, kokoko3k, linx.system.adm, mabo, nate, postix, tjkrobertson, tromzy |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/a6b5efd43d886d73d7662bad5cff019970be349e | Version Fixed In: | 5.25.4 |
| Attachments: | animation stutter | ||
|
Description
Eric Edlund
2022-03-16 20:26:17 UTC
X11 or Wayland? What do you mean by "stutters"? Can you attach a screen recording? Wayland. Also, you need multiple windows open. It doesn't consistently happen the first time you toggle, try a few times. Interestingly, I couldn't even get it to toggle with the shortcut on XOrg. Video: https://drive.google.com/file/d/175dS_nY4kH8-wfBfYTTHgFDsPLH2ZU57/view?usp=sharing I was triggering in the video with gestures but shortcuts do the same thing. Cannot reproduce on Wayland with an external monitor, no matter where it is positioned relative to the laptop screen. I can do it without a second monitor in MR 2196 just by going slowly up and down on the touchpad. *** Bug 455474 has been marked as a duplicate of this bug. *** *** Bug 453993 has been marked as a duplicate of this bug. *** *** Bug 455422 has been marked as a duplicate of this bug. *** Should be fixed by https://invent.kde.org/plasma/kwin/-/commit/a6b5efd43d886d73d7662bad5cff019970be349e in Plasma 5.25.1, by Vlad Zahorodnii. *** Bug 455767 has been marked as a duplicate of this bug. *** Re-opening as we got a duplicate bug report from 5.25.1 so I guess it's not fully fixed yet for everyone. Yeah, this is definitely not fixed in 5.25.1. The destkop effects bugs were fixed, the choppy transition into and out of it is not. Same for the other Window Management destop effects redeveloped for 5.25, they all experience this transition issue, desktop effect is the choppiest though. X11 user. *** Bug 455585 has been marked as a duplicate of this bug. *** I found something interesting on nvidia + X11. We're losing all our CPU time in makeCurrent which in turn sits about in __sched_yield. i.e we're blocking waiting for the vblank. Our QtQuick windows aren't schedules to anything in particular, we just update them off a timer and hope it's all in sync. We could sync it to the relevant RenderLoop relatively easily and it might have a noticeable effect and fix some other issues (hopefully). Should be relatively easy to try and confirm if it makes a difference. Can you please finally fix this? I would usually be more polite on bugtrackers, but this issue and lack of focus on fixing it is just so ridiculously frustrating, so I feel the need to make more noise here, as I've been patiently waiting so far after I reported it in bug 453993 on May 18th. The merge request of the desktopgrid re-implementation should have never been merged this blindly/naively, let alone be released as 5.25. The effect and thus the entire Plasma desktop is unusable due to this. The utter broken state of the effect prevents me from updating my system on Arch since several weeks, since partial upgrades are unsupported. The stuttering occurs on both X11 and Wayland, but only if more than one monitor is enabled. Using AMDGPU. (In reply to David Edmundson from comment #13) > Our QtQuick windows aren't schedules to anything in particular, we just > update them off a timer and hope it's all in sync. > We could sync it to the relevant RenderLoop relatively easily and it might > have a noticeable effect and fix some other issues (hopefully). > > Should be relatively easy to try and confirm if it makes a difference. In my efforts make gestures/fullscreen effects work contextually, I've created a system to facilitate animations between them. It essentially sends out new frame updates based on an animation progress. This is in !2184 which is currently functional, just needs to be slit up and merged. In the MR, the stuttering is still there, but maybe relevant. (In reply to bastimeyer123 from comment #14) > The merge request of the desktopgrid re-implementation should have never > been merged this blindly/naively, let alone be released as 5.25. The effect > and thus the entire Plasma desktop is unusable due to this. The utter broken > state of the effect prevents me from updating my system on Arch since > several weeks, since partial upgrades are unsupported. Does the stuttering for you appear as it does in my video? https://drive.google.com/file/d/175dS_nY4kH8-wfBfYTTHgFDsPLH2ZU57/view?usp=sharing I ask because "unusable" has not been my experience with this issue. See the YT video I posted in bug 453993 https://youtu.be/A0ydBC6tvUQ The effect and the entire Plasma 5.25 desktop is unusable, because it makes me dizzy whenever I open/close the desktop grid. What you're showing in your video is not the grid, but the present-windows stuff. This bug is about the stutter when opening heap based effects like Desktop grid and Overview effect. In that video you're seeing three different issues. The window heap stutter, the relocating of windows on drag 'n' drop in desktop grid, and the inconcise arranging of windows done by window heap. I agree, that is dizzying and quite annoying. For those two other issues though, you should file two other bug reports. Yes, I am fully aware of this. Please see the history of the linked bugs. I've already opened 11 bugs in total after the merge of the new desktop grid. That video is just a combination of all of them, because I didn't feel like recording multiple videos. It's linked in most of the bug reports. This has been pointed out in other bug reports [that have been marked duplicate], but this bug manifests more clearly on high-refresh rate displays. It is extremely noticeable on my 144Hz display [AMD graphics, kernel 5.18, latest Mesa]. Created attachment 150760 [details]
animation stutter
*** Bug 455585 has been marked as a duplicate of this bug. *** *** Bug 455930 has been marked as a duplicate of this bug. *** *** Bug 455763 has been marked as a duplicate of this bug. *** I can reproduce this now with a multi-screen setup on Wayland. It only happens on the primary monitor though, and only on the right-most screen. Which screen is Primary doesn't seem to make a difference For me, it is not (only) a matter of having a second screen or not. Yes, having multiple screens make the things worse for me too, but it is just because my igp is more taxed that way. Indeed, on a single monitor setup, I noticed that on a machine not yet "upgraded" to kwin 5.25, i can use present windows effect with 20 windows on screen and everything is really smooth. my monitor is 75hz and everything moves fine. On the upgraded machine, instead, same hardware, single screen, if i open 15 windows and then activate present windows the animation stutters to something around 20/30fps. If I activate the effect mutliple times very fast, intel_gpu_top reports almost 100% gpu use. https://invent.kde.org/plasma/kwin/-/merge_requests/2743 was just merged and will appear in Plasma 5.25.4. It wasn't definitely expected to fix this issue, but I find that it does fix it for me with my weak Intel iGPU. Can other people test? The stutter is gone on master for me (wooo hooooooo) 10th gen intel i7 integrated graphics Awesome, let's call it fixed! I've applied 63bf8112006acb37504c5d0b0cc850a74d3eb1da to Plasma/5.25 and it seems to have indeed fixed the stuttering. Thanks! (In reply to Nate Graham from comment #29) > Awesome, let's call it fixed! > Version Fixed In 5.26 Milestone in MR says 5.25: So rather 5.25.4? It was just cherry-picked to the 5.25 branch today; I will update the "Version Fixed In" field. |