Since 5.5.95, I've noticed that moving the mouse cursor over the window tabs in the task manager in the panel leads to temporary performance spikes. The severity varies, sometimes it can be noticed that the cursor jumps for 1 to 1.5 seconds, sometimes it can barely be noticed. There are two panels in my Plasma setup, both have a default panel layout. The option to show the window tooltips have been deactivated for both task managers. The performance spikes are visible in the fps monitor, thus I'm sure they don't just affect the cursor, but the whole desktop (and therefore I think it's either a bug in kwin or the driver). One interesting observation is that the effect is barely noticeable (but still slightly present) with the EGL interface, but strongly present with the GLX interface, which I didn't expect. I switched back and forth a couple and found it to be reproducible. With 5.5.4 and below I cannot remember ever seeing an effect like this. Reproducible: Always
Created attachment 97697 [details] qdbus-qt5 org.kde.KWin /KWin org.kde.KWin.supportInformation
Created attachment 97698 [details] glxinfo
> the cursor jumps for 1 to 1.5 seconds The cursor should be done in hardware and painted directly into the scanout buffer. Does any other item in the panel cause this? Let's say I simply completely distrust QML. Please edit /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml and comment // toolTipItem: toolTipDelegate and // ToolTipDelegate { // id: toolTipDelegate // visible: false // } restart plasmashell and check again.
(In reply to Thomas Lübking from comment #3) > > the cursor jumps for 1 to 1.5 seconds > The cursor should be done in hardware and painted directly into the scanout > buffer. > > Does any other item in the panel cause this? Yeah, I noticed that especially items showing tooltips when hovering over them show this behavior, but it's not as easy to notice because the area of those widgets is small compared to the task manager. Items I found to cause lag: Menu (currently kickoff), Desktop Switcher, Task Manager and the panel settings symbol. However, not all of them do. The systray does not seem to be affected and neither is the clock. I also don't notice this right away, it gets worse over time and after a couple of hours there is a strong effect. Right after (re-)starting plasma, everything looks normal. So it looks more like it's a plasma bug. Theory: plasma temporarily consumes a huge amount of cpu time which leads to kwin or X starting to lag for a short time. > > Let's say I simply completely distrust QML. > Please edit > /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml > and comment > > // toolTipItem: toolTipDelegate > > and > > // ToolTipDelegate { > // id: toolTipDelegate > > // visible: false > // } > > restart plasmashell and check again. Nope, that didn't help. The task manager still behaves the same.
(In reply to Bernd Steinhauser from comment #4) > So it looks more like it's a plasma bug. Theory: plasma temporarily consumes > a huge amount of cpu time which leads to kwin or X starting to lag for a > short time. Could be, but doesn't explain the difference between GLX and EGL (unless you're not actually running EGL but failsafe to uncomposited or render - I don't think so, though) - how about xrender, btw? Next test would be to deactivate all effecs in "kcmshell5 kwineffects" - or go for the simpler way: cp ~/.config/kwinrc ~/.config/kwinrc.bak sed -i '/^\[Plugins\]/,/^\[/s/Enabled=.*/Enabled=false/g' ~/.config/kwinrc kwin_x11 --replace & If that makes things fast, it's time to figure the culprit effect ;-) (Bisect, ie. restore half of them, check; restore half of the rest or remove half of the just acticvated ...) Preferred candidates: slidingpopups kwin4_effect_morphingpopups kwin4_effect_fade blur contrast And please check w/o the showfps effect - it would pollute results.
(In reply to Thomas Lübking from comment #5) > (In reply to Bernd Steinhauser from comment #4) > > > So it looks more like it's a plasma bug. Theory: plasma temporarily consumes > > a huge amount of cpu time which leads to kwin or X starting to lag for a > > short time. > > Could be, but doesn't explain the difference between GLX and EGL (unless > you're not actually running EGL but failsafe to uncomposited or render - I > don't think so, though) - how about xrender, btw? xrender is the same. Might be slightly slower, but the lags are the same. Regarding the difference between GLX and EGL, that might be the implementation in mesa, don't know. > Next test would be to deactivate all effecs in "kcmshell5 kwineffects" - or > go for the simpler way: Or even simpler: Just switch of compositing: Compositing =========== Compositing is not active It's actually a bit embarrassing that I didn't try this before. Anyway, even with compositing switched off, I see the lags, so it's safe to say that it's unrelated to compositing. > Preferred candidates: > slidingpopups > kwin4_effect_morphingpopups > kwin4_effect_fade > blur > contrast Despite the above I tried specific effects and didn't find any of them to make a difference.
> Right after (re-)starting plasma, everything looks normal. "plasma" being the plasmashell process or the session? In the former case, this smells like a leak - check memory consumption?
I meant plasmashell. It's interesting to see how, the plasmashell cpu usage instantly peaks to 70-100% when moving the mouse. Given that's only the usage of one cpu (so total would be 400% on this quadcore system) that's not too bad, but it looks like the usage is increasing over time. Regarding memory consumption, at least after the start the memory consumption is reasonable (approx. 200M in column "M_RESIDENT" of htop). I will let it run for a couple of hours and see if things get worse. Another thing that I've noticed is that applications seem to have issues talking to kded since I upgraded to qt 5.6.0-rc. This already led to kmix and akregator not showing up in the systray and possibly other issues. Not sure how plasmashell works internally and if it needs kded here, but maybe it should be considered that the issues are related.
(In reply to Bernd Steinhauser from comment #8) > Another thing that I've noticed is that applications seem to have issues > talking to kded since I upgraded to qt 5.6.0-rc. kded, dbus in general or the systray? Ie., does "qdbus org.kde.kded" time out, complain about no such service or just list all modules (excluding the SNI)? > Not sure how plasmashell works internally QtQuick - apparently they found a way to make it an even slower resource hog in 5.6. I can't imagine what the taskbar is doing other than the hover animation, but failing dbus would rather lead to 25s (seconds!) timeouts that CPU spikes.
kded crashes and therefore is not running. See bug 360245. I've had it running a couple of times and then it complained about blocking dbus calls. btw, I haven't seen memory consumption of either kwin or plasmashell increasing over time. That said, it did increase, but only from around 200M to 280M, which shouldn't be problematic. Anyway, I guess it's safe to reassign this to plasmashell. From all I've seen so far, it seems very unlikely, that this is kwin's fault.
I don't see anything Task Manager-specific in this bug report.
Apparently the taskbar is simply a prominent exposer of "something that makes qtquick slow", ie. afaiu uses "wrong"/bad QML statements. *shrug*
I'm not sure, but it could be related: Yesterday, after letting the system run for 1 day without restarting anything desktop-related, I observed a stuttering performance when playing a video. For that, it did not matter if it was a video inside a browser (e.g. youtube) or a file played by a media player. Restarting plasmashell did not help, but restarting kwin did. (Suspending compositing did not help either.) Thus, whatever causes these performance issues, it could be that kwin is affected as well, i.e. if it has something to do with the dbus changes in Qt 5.6?
Hopefully not - there should be no blocking dbus calls in KWin. Are you sure the stutter did not exist from the beginning? (It sounds more like and could be misdetected triple buffering, ie. KWin believes your glSwapBuffer call blocks - while it does not - or vv. and performs an unfortunate calculation for the "delay" to the next swap)
Yes, I'm sure about that. I will see if I can reproduce it somehow. Is there a way to find out *what* kwin or plasmashell are doing when those issues occur? gdb?
QML users in KWin are - all window decorations except breeze (and likely oxygen, which you've been using) - most tabboxes (except for cover- and flipswitch) - this would be the major candidate? - the desktop switching OSD On profiling, there's http://doc.qt.io/qtcreator/creator-qml-performance-monitor.html but I'm neither sure whether it actually does runtime profiling and cache analysis seems restricted to the commercial version. Classical profilers (callgrind) didn't turn out to be any helpful regarding QML on my only attempt (you'll figure that it spends most of the time in resolving metaobject data from a slot invocation)
Well, there is definitely something wrong with kwin as well, but I have yet to find out the details. For example, sometimes it does not respond to a double-click on the window decoration, which should lead to a maximization (can try 3 times and I'm surely fast enough). After dragging the window a bit and trying again, it works instantly. But it's interesting that there seem to be quite a few triggers for the cursor lag and afaics it's always accompanied by a strong increase in plasmashells cpu usage. It's also interesting to see that it's always in two processes simultaneously: The first and second started process (thread?). One of the triggers I found for example: Fiddling around with firefox, sometimes bringing up a tooltip or context menu results in such stuttering. I have no idea why plasmashell would be involved there. Even loading a new website or just opening a new tab results in a strong increase in plasmashell's cpu usage accompanied by the cursor lag. Why? Maybe, just maybe I could understand if it would be related to an compositing effect, but it happens without compositing as well. This is all very, very strange.
Doubleclick sounds like related to bug #357450 but should be resolved in your KWin? About the cross process CPU load I could imagine that this is due to a swapping race in two GL contexts (your FF is gonna use HW acceleration, is it? Check "about:config") resulting in an unclamped (otherwise afaiu QtQuick only limits repaints by glSwapBuffer blocks) repaint cycle and insane FPS - loading the CPU as much as possible. You should have better chances to trigger this with an OpenGL client (glxgears or fancy GL hacks from xscreensaver) - but we're talking voodoo here :-(
(In reply to Thomas Lübking from comment #18) > Doubleclick sounds like related to bug #357450 but should be resolved in > your KWin? I've never had this before updating to 5.5.95. But now that you point me to it, I'll try reverting it and see if it still occurs. Otherwise I'll open a bug. Guess we shouldn't discuss this here. > About the cross process CPU load I could imagine that this is due to a > swapping race in two GL contexts (your FF is gonna use HW acceleration, is > it? Check "about:config") resulting in an unclamped (otherwise afaiu QtQuick > only limits repaints by glSwapBuffer blocks) repaint cycle and insane FPS - > loading the CPU as much as possible. > > You should have better chances to trigger this with an OpenGL client > (glxgears or fancy GL hacks from xscreensaver) - but we're talking voodoo > here :-( Yes, glxgears get's laggy as well when triggering this. And that actually gave me an idea. Since I can trigger this with firefox as well (and the effect was strong), I tried before and after I killed plasmashell. As soon as plasmashell wasn't running anymore, everything was smooth as it should be. Before glxgears got very laggy as soon as I did just about anything in firefox. hw accel was enabled, but I tried the above before and right after starting plasmashell the effect is barely noticeable, so I will have to wait for a bit to report on that.
hw accel for firefox does not make a significant difference. Tab changing in konsole, kate can also be used to trigger the stuttering. To me it seemed like it might have something to do with window management, so I tried different options for the switchers (including turning both main and alternative off), but it didn't change anything, at least immediately. So that's not it.
Now on 5.6.0, this does still happen. One thing I noticed recently: If I copy a file using dolphin, plasmashell becomes unresponsive. Like I can't use the task manager to switch screens, can't use the menu, right click on desktop does not work anymore. The cursor is constantly laggy, but the rest of the system works. The cpu usage of plasmashell is very high, but not only that, Xorg uses 100% of one cpu as well. After that finished, everything goes to normal again and the cpu usage is low. Obviously, this does not happen if I copy the same file outside of plasma, i.e. using cp in konsole. I suspect it's caused by the notification widget that shows an animation during the file copy.
> If I copy a file using dolphin, plasmashell becomes unresponsive. https://bugs.kde.org/show_bug.cgi?id=311799 https://bugs.kde.org/show_bug.cgi?id=347237 Smells related to the new feature to show progress in taskitems? (But I'm not sure why that would impact on hover other than DnD is / used to be (?) slow over animated content on nvidia)
(In reply to Thomas Lübking from comment #22) > Smells related to the new feature to show progress in taskitems? Is there a way to test that? Can I build plasma without it? Would a bisect help?
For testing purposes, I downgraded Plasma to 5.5.5. I do still see the same behavior. I'm pretty sure that I didn't see it previously when I ran 5.5.x, because a laggy behavior like this I would've noticed. As I upgraded to Plasma 5.6 together with Qt (to 5.6 as well), I guess this is a bug that was triggered by a change in Qt, since I'm now running Plasma 5.5 on top of Qt 5.6. I'm not sure if I'm going to test that, though, since downgrading Qt on a source-based distro is really really painful.
Hm, bug 362247 gave me an idea. Normally, I'm using the following driver options for either amdgpu or radeon. The driver that is used does not matter the behavior is the same: Option "TearFree" "On" Option "EnablePageFlip" "Off" Option "DRI" "3" Note, that TearFree does imply disabling EnablePageFlip, so I'm kind of duplicating here. The man page says about TearFree: »Enable tearing prevention using the hardware page flipping mechanism. This option currently doesn't have any effect for CRTCs using transforms other than rotation or reflection. It requires allocating two separate scanout buffers for each supported CRTC. Enabling this option currently disables Option "EnablePageFlip". The default is off.« So what I now tried is the following setup: Option "TearFree" "Off" Option "EnablePageFlip" "On" Option "DRI" "3" This does not remove the behavior, but change it. The laggy behavior can only be observed the panel on the left screen (which is the primary screen, if that matters) and not on the right screen. (Might not be perfectly smooth there either but if so it's really a minor effect.) The bouncing cursor start effect still causes lag on every screen, but other things like context menus, opening new tabs in firefox etc. perform normally now. It's mainly that one panel and the bouncing cursor where I observe the problem. (Even if a busy cursor is not selected in the settings.) Next I'll test with both TearFree and PageFlip disabled.
Should note: I don't have any rotated screens.
Just wanted to note that I still see this with 5.6.95 and it feels like it actually got worse. A lot of stuttering due to plasmashell's high CPU load.
Just to give you some numbers, I let this system run for approximately one day. During this time, plasmashell (in two threads) on average consumed 20% of one CPU. It was then on rank 1, right before Xorg with approx. 15%. The third process would go to kwin, but that was already only at 2%. I still have no idea what exactly plasmashell is doing. Help to find out would be appreciated, because I don't think that this would be normal, to me the numbers appear to be too high.
Seems like this was drive-by fixed with one of the recent versions.