Version: (using KDE 4.0.0) Installed from: Ubuntu Packages OS: Linux KDE 4.0.1 When hovering the taskbar in composite mode the window preview that pops up generates huge amounts of repaints to the point of stopping the mouse cursor.
how did you track it down to repaints? by the kwin repaint checker plugin, QT_FLUSH_PAINT=1, or some other method?
I used the kwin repaint checker plug-in. I started suspecting something weird was hapenning when the mouse pointer became slugish.
*** Bug 157611 has been marked as a duplicate of this bug. ***
Before opening a new bug, I prefer to post here I've noticed than in this situation: - no composition actived - tooltips activated when hovering a taskbar entry, plasma starts eating 50% while X eats another 50%. I attach two screenshot showing the top output before and after
Created attachment 23573 [details] Before hovering CPU use is regular
Created attachment 23574 [details] While hovering Notice plasma and X processes. they are both eating 50% CPU each
Did you try disabling the tooltips for the taskbar? Even if they do not show the preview, but just the standard tooltip, they seem to use a lot of CPU.
on my system here they use no cpu after being shown (and even then the cpu usage is moderate). it would be interesting to find out what is triggering this for you. it could be that the window being hovered is producing a lot of updates (causing the tooltip to update too often) and we aren't filtering/compressing those particular updates. but this obviously isn't a general purpose problem, at least not in trunk/. is anyone who is experiencing this problem running trunk/? i guess you would be, Sven?
btw, if someone can reproduce, it would be interesting to see if it is ToolTip::setData that is causing unecessary CPU usage by setting all the widgets' data every single time and if only setting the widgets whose content changes would help; still, setData should not be called so often by the app.
I can reproduce this quite easily. If I click on a task to minimise/maximise and do not wait until the tooltip shows up, the window opens instantly. If I wait until the tooltip begins to show up, the window takes a few seconds to show up.
oh, and as long as the tooltip stays, plasma uses 30% and X 60% cpu. (branch) with compositing enabled but no preview, just plain tooltip.
I have a copy of trunk as well, I can givi it a try...
In response to comment #7: disabling the tooltip plasma is not eating CPU anymore, so (at leat in my installation) is directly related to the tooltip. Should I file another (more specific) bug?
i don't think so. i *honestly* don't think this problem exists in trunk anymore. the only way i can see this being a problem is if one of the following is true: * the tooltip is getting updated data too frequently * broken x.org drivers we already know there are various issues with the window thumbnails and the tooltips in general with kwin composite, but i honestly can't reproduce it without thumbnails and with kwin's compositing support turned off. i'm very inclined to believe at this point that the problems exist in kwin.
I am seeing this too with the debian packages. If I disable tool tips for task manager and hover on a task icon cpu usage stays normal.
Ok, I did a little test with another machine with different graphic card and these are the results: - trunk 4.0.1+: no CPU use while hovering - Kubuntu stock KDE 4.0.0: no CPU use while hovering So it seems something related with the Intel driver I have on the Kubuntu machine where I'm seeing the problem. With the radeon on the other one, as i said, no problem at all. Monday I'll see what happens with recent trunk and the i810 driver. Cade, what graphics card are you using?
It is an intel integrated video card too. 00:02.1 Display controller: Intel Corporation 82915G Integrated Graphics Controller (rev 04) ii xserver-xorg-video-intel 2:2.2.0.90-3 X.Org X server -- Intel i8xx, i9xx display d
This is not related to the intel driver, I am seeing this problem with: [ebuild R ] x11-drivers/xf86-video-ati-6.7.197 USE="dri -debug" 0 kB 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)
A month from the previous comment, I'm using kde 4.0.2 and am having this same problem, with both kwin "Taskbar Thumbnails" and regular tooltips.
Can anyone reproduce this bug with a KDE 4.1 beta, or trunk of KDE svn? I can't here, but I'd like to check if any of the original reporters can reproduce it before I close the bug.
the tooltip isn't even available in 4.1. we should wait on this one until we have plasma tooltips again in 4.2
Can anyone running trunk in composite mode reproduce this with the new tooltip implementation?
With current trunk, compositing disabled, I'm not experiencing anymore the behaviour I commented in #4 Tomorrow I'll try with composite on and let you know.
Ok, checked with current trunk SVN, composite switched on, on intel driver, no CPU at all (X at 1-2% and plasma isn't even present as top process). IMO this bug is fixed.