Thanks for your report. I just tried on Intel and AMD graphics and was not able to reproduce the issue with Wobbly Windows or Zoom.

Can you give me a step-by-step rundown on how to reproduce it? Do I need to have a certain load on the CPU or GPU?

I have a single 4K monitor connected. Do you experience the issue only when both your 4K monitors are connected or also with only one connected?

(In reply to Roman Gilg from comment #1)
> Can you give me a step-by-step rundown on how to reproduce it? Do I need to
> have a certain load on the CPU or GPU?

No specific load needed, it was quite apparent pretty much immediately after reboot and restarting X/plasma after the update (certainly when I first tried to move a window or zoom, which are routine enough to be nearly immediately after starting X/plasma), but your lack of reproduction reminded me I run an aurorae-based windeco (black square, originally downloaded from kdelook some years ago, I guess it'd be kde store now), so I tried with breeze (after a quick rebuild to HEAD and kwin_x11 --replace, of course, ccache is cool =:^).

I /think/ breeze windeco helps a bit compared to aurorae/black-square, but it's still extremely easy to trigger a kwin lag-out when moving a window with breeze, if wobbly-windows is enabled.

I'm not sure whether it makes the problem worse (that is, kwin more laggy), but playing a video (qt5-based minitube, FWIW) when attempting the window move makes it more apparent, as the video will drop frames and sometimes freeze all or part of the video (texture artifact?) when kwin's lagged out on the wobbly-window move or >5 zooms/sec.

The lines from snap-helper freeze when kwin lags out too, but that doesn't seem to be a problem effect, it just makes the wobbly-window-induced lag-out more apparent when the snap-lines don't disappear when you quit moving the window.  Similarly, fall-apart doesn't appear to trigger lag (while concurrent zoom and window-close  for fall-apart would be rare, I did just try to test it, and the fall-apart did pause slightly during the repeat-zoom, but that's a rare enough combo I'm not entirely sure it wouldn't do that when things are working correctly).

> I have a single 4K monitor connected. Do you experience the issue only when
> both your 4K monitors are connected or also with only one connected?

It hadn't occurred to me to try with just one (it's a desktop system and the two 4Ks are normally permanently connected), but great idea...

Using xrandr to turn off one output for testing, then turn it back on and reposition it correctly.  (FWIW I confirmed that xrandr reports the smaller framebuffer when the one is off and kwin moves everything to the remaining output.)

The problem remains with just one 4k connected.  It's hard to tell for sure, but it's possible it's a bit less laggy.

Which prompts the question, what about smaller (say 1080p) resolutions, one or two outputs?  (Switching to arandr for this...  FWIW kscreen/krandr have been broken or have interacted badly with plasmashell often enough over the years that I stick to xrandr/arandr and don't even have the k* versions installed, tho of course libkscreen is a plasma-workspace dep so it has to be, but it hasn't seemed to break anything on its own.)

Tried 1080p on just one output (other one off) or both, and it didn't seem to markedly affect the problem; it's still easily triggered, regardless.

I tried setting just one output and doing the kwin_x11 --replace thing, too, just in case kwin still had some stale two-output state left, and that didn't change the results either -- the problem remains.

> I just tried on Intel and AMD graphics and was not able to reproduce the
> issue with Wobbly Windows or Zoom.

What generation AMD graphics?  Maybe it's generation dependent?  As posted I'm on Polaris 11/Arctic-Islands, so it's "a bit" dated now, but new enough to be comfortably within the amdgpu driver range (one of the reasons I upgraded to it, actually), not the older radeon driver.

So I don't know what those swap events are that were being setup in that commit series (actually, reading the commit log I thought they were intel-only, but maybe not...) and thus don't know if the following questions even make sense.  Does my polaris11 support them?  Maybe it claims to but they're buggy or "emulated" on the CPU for my card/driver combo?  Certainly, forcing to cpu might explain the slowdown, but one would expect that'd trigger CPU usage spikes on at least one core and I don't see that when kwin lags out, either. I looked.

Thanks for giving detailed information. :)

I was testing it with an RX 5700 XT (Navi) on Mesa master.

What you could do is running Hotspot to see if there are CPU cycles being burned somewhere unnecessarily:
https://github.com/KDAB/hotspot

A second tool you could try out is GPUVis to see when the frames actually hit the screen (and insert some debug statements for finer analysis):
https://github.com/mikesart/gpuvis
But for that you would need to recompile KWin with following wip-patch applied:
https://phabricator.kde.org/D23114

Hey Duncan,

I cleaned up the compositing path a bit more and fixed an oversight in regards to swap events not being received if the buffer age extension is not available.

Please check out if this solves the problem for you: https://phabricator.kde.org/D26216

FWIW, kwin master as of 054cfc1c8 seems to be /vastly/ improved, altho not /quite/ back to where it was.  I'd say 75-80% (aka 3/4 to 4/5) of the original regression performance loss has been regained.

I can run all my usual effects now, but still noticed a bit of slow-down until I tweaked configs a bit, adjusting the wobbly-windows config for normal windows and bumping animation speed (workspace behavior, general behavior, animation speed slider) for plasma (autohide panel showing speed, panel plasmoid hover popup morphing speed).

It's fast enough now if I was new to plasma I'd never suspect the regression and would just tweak things if the default seemed slow until they worked as I wanted, and it's only that I had it tuned to what I wanted before and it was still slightly too slow with that config that hints at the far greater regression before.

(In reply to Roman Gilg from comment #4)
> Please check out if this solves the problem for you:
> https://phabricator.kde.org/D26216

I take it that's not yet applied to master?  Do I still need to try it?  And/or would bisecting the commit at which I got most of the performance back still help?

(While fiddling with the config I noticed the FPS effect once again.  Too bad I didn't think to try enabling it when kwin was lagging out so badly.  It'd have been nice to get real numbers, tho of course I still could by pinning the bad commit and rebuilding...)

(My regular updates included a gcc-9.2.0 gentoo patch revision early in the update sequence, a mesa update from 19.3.0 to 19.3.1, and an llvm and clang update from 9.0.1-rc3 to 9.0.1 release, of interest given their usage with amdgpu for shader-compiling, etc.  While kwin's 00bf75d06 commit did indeed regress something, it's possible that it was only as severe as I was seeing due to a bug in one of the above packages and that updating that package, not a kwin commit since then-head d72e96802, gave me back most of what I saw lost in that regression.)

I've a couple more days off due to Christmas, and (if only for my own curiosity) may well do some more rebuild testing to pin down exactly what gave me that performance back, as well as testing D26216, but FWIW it's definitely workable now and as such I'd be OK with closing the bug, even if I didn't get 100% of the pre-regression performance back.

(In reply to Duncan from comment #5)
> FWIW, kwin master as of 054cfc1c8 seems to be /vastly/ improved, altho not
> /quite/ back to where it was.  I'd say 75-80% (aka 3/4 to 4/5) of the
> original regression performance loss has been regained.
> 
> I can run all my usual effects now, but still noticed a bit of slow-down
> until I tweaked configs a bit, adjusting the wobbly-windows config for
> normal windows and bumping animation speed (workspace behavior, general
> behavior, animation speed slider) for plasma (autohide panel showing speed,
> panel plasmoid hover popup morphing speed).
> 
> It's fast enough now if I was new to plasma I'd never suspect the regression
> and would just tweak things if the default seemed slow until they worked as
> I wanted, and it's only that I had it tuned to what I wanted before and it
> was still slightly too slow with that config that hints at the far greater
> regression before.
> 
> (In reply to Roman Gilg from comment #4)
> > Please check out if this solves the problem for you:
> > https://phabricator.kde.org/D26216
> 
> I take it that's not yet applied to master?  Do I still need to try it? 
> And/or would bisecting the commit at which I got most of the performance
> back still help?

Yea, not yet applied. Would be great if you could try it. I noticed some slow downs as well now after more testing with certain configurations and this patch should help with them. Can you apply it to the top of KWin master?

> (While fiddling with the config I noticed the FPS effect once again.  Too
> bad I didn't think to try enabling it when kwin was lagging out so badly. 
> It'd have been nice to get real numbers, tho of course I still could by
> pinning the bad commit and rebuilding...)

The numbers of the FPS effect are not that reliable. Actually currently I test often with:
https://www.testufo.com/animation-time-graph
https://www.vsynctester.com/
  
> (My regular updates included a gcc-9.2.0 gentoo patch revision early in the
> update sequence, a mesa update from 19.3.0 to 19.3.1, and an llvm and clang
> update from 9.0.1-rc3 to 9.0.1 release, of interest given their usage with
> amdgpu for shader-compiling, etc.  While kwin's 00bf75d06 commit did indeed
> regress something, it's possible that it was only as severe as I was seeing
> due to a bug in one of the above packages and that updating that package,
> not a kwin commit since then-head d72e96802, gave me back most of what I saw
> lost in that regression.)
> 
> I've a couple more days off due to Christmas, and (if only for my own
> curiosity) may well do some more rebuild testing to pin down exactly what
> gave me that performance back, as well as testing D26216, but FWIW it's
> definitely workable now and as such I'd be OK with closing the bug, even if
> I didn't get 100% of the pre-regression performance back.

It's good to hear that it feels better now. Thank you for the feedback. But check out the patch D26216 above if it improves the situation even more.

So I was out a few weeks due to death in the family. =:^(

Given the reverts in https://mail.kde.org/pipermail/kwin/2020-January/002999.html (including the bisected-to 00bf75d06) is this still relevant?

If no longer relevant, resolved/fixed or resolved/worksforme or ???  (Resolved/obsolete may be most appropriate, but it doesn't appear to be an option on kde's bugzy instance.)

(I just rebuilt/kwin-replaced and a quick test says the last ~20% of the regression is gone now, but it's too soon to say for sure.)