i thought about it - i'm not sure how well integrated compiz effects are for kde 4. i haven't used compiz in about 2 years (not like that really matters). i just don't want to install compiz because A. kde already has a compositing manager B. i don't care for half the features it comes with (i don't use the compositing for eye candy, i use it for functionality) and C. kwin already has what i'm looking for, its just cpu consuming with gkrellm

I've looked at this again and can confirm that kwin takes more CPU time (about 5% on my E6300 and nvidia GT 240) with the gkrellm feature "Krell and LED updates per second" turned up to 10 or more. I have mine at 1 update per second. If you right click on the hostname display in gkrellm monitor and then choose configuration, the option is there. It seems that gkrellm is updating a lot and kwin probably has to redraw the gkrellm window causing the CPU load.

gavlee wrote:I've looked at this again and can confirm that kwin takes more CPU time (about 5% on my E6300 and nvidia GT 240) with the gkrellm feature "Krell and LED updates per second" turned up to 10 or more. I have mine at 1 update per second. If you right click on the hostname display in gkrellm monitor and then choose configuration, the option is there. It seems that gkrellm is updating a lot and kwin probably has to redraw the gkrellm window causing the CPU load.

well thats the thing, it isn't all of kwin, its kwin's compositing effects. if i disable the compositing effects, the cpu usage drops to less than 1%

Constant changes will require KWin to update it's effects. Applications should not repaint their entirety when making minor changes, only the area that has changed. Please activate the "Show Paint" Desktop Effect to see if this is the case.

well, when i first enabled the show paint feature, it crashed my computer. when i restarted, show paint was still enabled. luckily it didn't crash it and i was able to see the results. much of gkrellm was flickering constantly, but not the entire window

The problem is therefore that Gkrellm is abusively repainting itself, causing KWin to generate a higher load in order to maintain compositing effects.

Please file a bug against Gkrellm, applications should only repaint what is explicitly needed.

bcooksley wrote:The problem is therefore that Gkrellm is abusively repainting itself, causing KWin to generate a higher load in order to maintain compositing effects.

Please file a bug against Gkrellm, applications should only repaint what is explicitly needed.

wouldn't this be more of a kwin bug than a gkrellm bug? gkrellm gets along with kwin without special effects, but both don't respond well when special effects are on. gkrellm is OLD and very stable, and it repaints only when it is refreshed. I really doubt gkrellm is the issue - especially when i heard compiz doesn't get the same issue.

This can be a worse issue because what if someone wants to play a windowed game? Isn't that going to negatively affect kwin and the game?

what i would like to see is an option in kwin to exclude certain programs from the desktop effects. it wouldn't surprise me if even conky gets the same issues.

Which Desktop Effects do you have enabled? The constant flickering indicates constant repainting.

magic lamp
shadow
sheet
slide
taskbar thumbnails
transluency
dialog parent
desktop grid
present windows

i've tried disabling every one of these and it doesn't seem to make a difference. its the compositing that causes the hindering. you can still do compositing with no special effects enabled.

You may wish to file a bug against KWin, however I do not think that the bug is caused by KWin....

why wouldn't it be kwin? everything points to it:

* gkrellm, kwin, and xorg uses <1% CPU combined with kwin compositing effects turned off.
* all 3 of them use up about 2% each when kwin compositing effects are turned on.
* gkrellm and xorg use <1% combined cpu with compiz (from what i've heard)

i don't see how this possibly could be related to anything but kwin's compositing.

if i felt gkrellm was a likely candidate i wouldn't have posted this question on the kde forums. i use gkrellm on a 900MHz celeron netbook and it uses about 1% of it's cpu (i use lxde on that though, kde is way too heavy)

i would post a bug report, but i'm using kde 4.4.5. the issue could be solved already and even if it isn't, i doubt anybody will pay attention to something this outdated. i'd like to update kde but i can't find any debian repos that will do it, not even the experimental will let me.

i'm aware of the other distros, but the reason i like debian is because it gives me complete control and i don't really need to uninstall anything i don't want. i used to use ubuntu but i was sick of it assuming what i wanted, it was relatively slow, and it has been getting hardware issues lately.

compiz is sort of the same way - its just a little more overkill than i care to work with. i have made things for compiz a couple years ago but most of the special effects really just slow me down - the very few effects i use in kwin are all i really need and they help speed things up, or make things easier for me.

i suppose i can just wait until debian releases 4.5, or 4.6. it just doesn't make sense to me why they'd wait when i remember kde's homepage saying something along the lines of "these are just bugfixes, there is no reason not to update to this" yet the debian dev team says "we want to make sure its stable first" even though their UNSTABLE repo doesn't even have 4.5. what i'd really like to see is a repo as large as debian's that stays up to date, but not so up to date that your computer won't start up anymore (like ubuntu's)

I don't think this is a bug in gkrellm or kwin to be honest, yes gkrellm updates large parts of its window frequently which is not very nice, without compositing enabled this is not an issue. With compositing enabled you start to notice it more, especially when gkrellm default update frequency is used or is turned up. As I say I have mine set to 1 update per second, it's enough for me, plus I find it distracting flickering 10 times a second. I think this is more of an interaction issue between the two programs.

I hate to go off-topic but regarding distros, Debian is nice, I run it on servers because it's easy to maintain and stable even if the packages are a bit dated, maybe that's the price you pay for stability. A Debian based distro was my first (Corel Linux with KDE), since then it's been Red Hat > Mandrake > Gentoo > Ubuntu and too many others to mention. I've stopped off at Gentoo for the last 8 years, I find it doesn't get in your way and you can tweak it however you like, it's all a matter of personal taste and requirements in my humble opinion. Find what's best for you, the choice is there.

honestly the gkrellm issue isn't too terrible. its just a problem that i thought there might've been a solution to but i don't really run anything too terribly cpu intensive (it kind of makes me wonder if overclocking is worth it, but as i see it, why not overclock if temperatures aren't increased).

the reason i'm using debian is because of how i can build it from the ground up without having to compile anything, and because the debian package managers are (imo) a lot more user friendly and reliable than what rpm has to offer. as a little bonus, debian also has the largest package collection. i've been using linux for over 3 years now and i've so far had very little luck with compiling things - mainly just c or c++ programs. i'm not sure if other distros get it any easier.

i'm not too interested in trying gentoo, i think its a great distro i just don't think its for me. imo i find arch linux completely pointless - i see no reason for using it over debian, gentoo, slackware, or fedora (and those 4, along with parted magic and mint, are really the only distros i find worth while)

I never overclock, I've had too many hardware issues in the past even without overclocking so I never bother, I'd rather have a stable box (do a test with gimps mprime) than mess around figuring out what's making the kernel oops.

The main reasons I use Gentoo is because half the time I wanted a package that was not in [insert distribution name here]'s package repository, thus I would have to compile it anyway. Gentoo makes this very easy being a source based distribution and it's easy to insert your ebuild script into the package manager, much easier than all the other distributions I've tried so far.

Anyway, this has gone a bit too off-topic.