https://bugs.kde.org/show_bug.cgi?id=415313
Duncan <1i5t5.dun...@cox.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |REOPENED
Ever confirmed|0 |1
Resolution|WAITINGFORINFO |---
--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
