Version: (using KDE 4.0.83) Installed from: Ubuntu Packages OS: Linux folderview is hogging the cpu while adding/moving/clicking/interacting/scrolling with any folderview .. be it a large folder or a small one results in X.. opening the system activity --> xorg cpu mounts up to 40% .. and drops to 4% when leaving the applet alone my VGA card is 512MB Geforce 8600 or something
Oh I am on kubuntu and used the kubuntu kde-member repository for downloading the Beta 2
I would also like to add that since it hogs the cpu, it becomes clumsy and non-responsive.. even clicking on an icon inside it or even removing it from the dashboard takes time. I hope that I am the only one with this bug :)
I can't reproduce this with Kubuntu. I have a Geforce4 MX 440.
welcome to the world of closed source drivers, A Bassio. And nope, you are not the only one, see http://www.nvnews.net/vbulletin/showthread.php?t=87865 and there is *NOTHING* we can do there.
p.s. be happy it's only slow for you. I've a 7xxx and have to deal with bug #157017 *grrr*
Oh I checked it now, mine is Nvidia 8500 GT But Sebastian, other applets do not cause this bug .. it is only the folderview applet. Does this still make it the driver's fault?
Also, it is not 100% CPU only a mere 35% or sometimes 40% ;)
Well, Bassio. The folderview does use a transparent background while most other plasmoids don't... Could you please try to switch to the Glassified desktop-theme (rich-click on the desktop and fetch the theme from the internet) since it uses a semi-transparent panel. So, if similar performance-issues rise up with the panel then, it's imho clear that the prob is within the driver. Anyway, I guess you are right and we/I should probably reopen it till it's clear cause that the performance-prob is limited to one plasmoid (aka transparent cases) only may either a useful detail for future reports or maybe even points to a real prob within the folderview (which I am not able to reproduce btw). So, hmmm... then let's reopen the report for now (till somebody else closes it cause nvidia and performance-problems are named *g* :) It may also an idea / useful to name the driver-version you are using. Thanks in advance and thanks for the feedback!
Hey Sebastian, the fact that xorg is the process which raises the CPU makes your assumption that the issue is a VGA one probably true. I installed Glassified and after a crash it worked more-or-less consistently. In fact it does not use much transparency except for the clock widget. The CPU on glassified is certainly higher than on the default black theme, but still, it did not exceed like 20% and wasn't that noticeable. However, shifting to interact with the widget showed noticeable buggy performance. Anyway, I am starting to get ****ed off NVIDIA's lack of concern for Linux users. The driver I use is: NVIDIA-Linux-x86-173.14.05-pkg1.run If there are any information I may provide to help with investigating this then please guide me. BTW, I have on board an integrated VGA chip on the motherboard, (which I believe, is a Gigapedia motherboard) but I don't know what is its name. Could this be the intel board you are talking about? Will it benefit if I try to switch to using this other VGA chipset to see how things are going? And how will my distro react if I make such a transfer, will it install new drivers automatically or what?
driver issues; wish we could fix them for you. sorry we can't =( i really wish we had an UPSTREAM resolution so we could track just how many of these kinds of reports come in.
Quit a lot reports and feedback from nvidia-users. The nvnews.net is filled with them but it seems not enough users did complain there yet or there is just no interest in fixing it :-/ and we, as consumers, can't do anything there there it seems. Well, I have at least the option to switch back to an old driver as long as it compiles with newer kernels... Re intel; well, the drivers they have are integrated into the kernel and therefore just work. But I am locked by myself on a AMD, so not an alternate for me yet :-/
I can confirm this (nvidia-glx-new driver). Of course we can't get the driver fixed, but there has to be a solution here. Since folderview may be used as a desktop containment in the future and since a lot of people have binary drivers, should folderview be changed to a non-transparent background (or at least have the option to do so)? I think this plasmoid will become very utilitarian in the future and hope that the developers would want to make sure that it's something everyone can use even if we need to do it in a "failsafe" no-transparency mode. Thanks