Bug 253378 - KWin CPU usage spike on window move and ~50% load when have gkrellm open
Summary: KWin CPU usage spike on window move and ~50% load when have gkrellm open
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-06 12:49 UTC by Gregor Kališnik
Modified: 2014-01-08 14:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
emerge --info output (4.84 KB, text/plain)
2010-10-06 12:51 UTC, Gregor Kališnik
Details
cat /proc/cpuinfo output (3.46 KB, text/plain)
2010-10-06 12:52 UTC, Gregor Kališnik
Details
XOrg config (4.56 KB, text/plain)
2010-10-06 18:53 UTC, Gregor Kališnik
Details
Sysprof profiling (resize and move) (251.38 KB, text/plain)
2010-10-10 12:16 UTC, Gregor Kališnik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor Kališnik 2010-10-06 12:49:25 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

If I have compositing enabled, KWin uses about ~50% cpu when running gkrellm (repaints seems to be very expensive).

Also when moving a window, cpu load spikes (even to 90%). Disabled wobbly and translucency plugins.

I have Radeon HD 4850 with xf86-video-ati-6.13.2, mesa-7.9 xorg-server-1.8.2 gentoo-sources-2.6.35-r4.

Reproducible: Always

Steps to Reproduce:
Enable compositing.

Actual Results:  
high CPU load

Expected Results:  
low cpu load :)
Comment 1 Gregor Kališnik 2010-10-06 12:51:10 UTC
Created attachment 52265 [details]
emerge --info output

emerge --info output, if someone finds it useful.

Also, I haven't find any bug that would contain kwin high cpu usage and gkrellm and window moving.
Comment 2 Gregor Kališnik 2010-10-06 12:52:36 UTC
Created attachment 52266 [details]
cat /proc/cpuinfo output

Also adding couinfo.
Comment 3 Thomas Lübking 2010-10-06 18:40:48 UTC
repainting _is_ very expensive with GL compositing sice the X11 pixmaps must be translated into GL textures. If the GPU doesn't do this, your CPU has a hard time :-(

a) is moving expensive even w/o gkrellem running?
b) <advert>use conky!</advert> ;-)
c) try fglrx (eewww...) according to Martin the performance is better on your GPU series
d) try the xrender backend - it doesn't require gl_texture_from_pixmap, but not all implementations are too good in eg. scaling (and some effects are not possible at all since it has no 3D concept)
Comment 4 Gregor Kališnik 2010-10-06 18:52:19 UTC
a) I forgot to mention, when I closed gkrellm I was partially happy. And then tried moving my windows, and got those CPU spikes. Short: Yes, I was testing w/o gkrellm running

b) I have 3 gkrellms running :) (my machine, Gentoo router and local gentoo dev. server :D, I'll check if conky has something similar)

c) I'm also using KMS (loving it). And have a bad experience with fglrx (that "bastard" overwritten my inode table for my portage database with junk, so I had to recompile my whole system)

d) I'd use GL compositing, so I would get some work out of my GPU. Xrender does give me fading and some effects, but it's not a GL compositing :). (PS: And I don't mind not using compositing, I just reported this bug thinking it may put some more light on the subject).

Oh. I forgot to mention. I have a dual screen display. I'll post my xorg config (it may be wrongly configured?)
Comment 5 Gregor Kališnik 2010-10-06 18:53:08 UTC
Created attachment 52284 [details]
XOrg config

My dual screen config
Comment 6 Thomas Lübking 2010-10-06 19:34:44 UTC
do you use the blur effect?
Comment 7 Gregor Kališnik 2010-10-06 19:42:58 UTC
Blur effects has no effect (not even visually).

Blur plugin is disabled.
Comment 8 Gregor Kališnik 2010-10-06 22:16:50 UTC
Also note, I'm using Qt 4.6.3.
Comment 9 Gregor Kališnik 2010-10-08 23:08:23 UTC
Hi.

I've enabled VSync and cpu load dropped to cca. 20%. But it's still little high :) (but imo bearable).
Comment 10 Thomas Lübking 2010-10-09 00:15:07 UTC
lets assume you've got a std. TFT @ 60Hz what probably means that sth. had painted at approx. 75-150Hz before (60*50/20) and is now limited to 60-30Hz ... you can use the "show paint" plugin to figure out what, but it's likely gkrellm then.
I'd suggest to find a way to limit its framerate to 20-30 what should be far more than sufficient for a monitor (i use a 5.0 second interval - 0.2Hz - on my monitors, since i don't look there all the time anyway :)

reg. moving windows:
- is that cpu load linked to compositing as well or is moving expensive in general?
- is it "normal" moving or "i judder around a window until my wrist hurts" ;-)
Comment 11 Gregor Kališnik 2010-10-09 01:37:00 UTC
Put gkrellms to 1 Hz :) (can't do any less) .

About moving...

Wobbly enabled:
Press (cursor turns into "mover"), jumps to 20-30%.
If I slowly move around (or fast) is about the same load.

Wobbly disabled:
Press: no change
Move (slowly or fast): jumps to 50-60% (quite interesting)

When "idling", it's about 5-10%.

When looking with "show paint", I found out, when starting to move (or actual moving) the window, whole desktop starts to flicker (everything gets repainted). That doesn't happen with wobbly disabled. Also, when moving without wobbly, only the window and 10-20px border is repainted (region selection may be expensive?).
Comment 12 Gregor Kališnik 2010-10-09 01:38:04 UTC
10-20px is just an aprox, which may be very inaccurate :) .
Comment 13 Thomas Lübking 2010-10-09 01:57:36 UTC
(In reply to comment #11)
> Put gkrellms to 1 Hz :) (can't do any less) .
So that one is "fixed" now (ie. lowering gkrellm repaints reduced the "idle" cpu load?)

> About moving...
> Press (cursor turns into "mover"), jumps to 20-30%.
> Move (slowly or fast): jumps to 50-60% (quite interesting)

indeed, wobble moving is far more expensive than slow moving here. however, moving w/o compositing is even more expensive (on X11, since the server has to do more repaints)

> When looking with "show paint", I found out, when starting to move
Yes, wobble moving is a fullscreen effect, the complete repaint is normal.

> Also, when moving without wobbly, only the window and 10-20px border is 
> repainted
the shadow exposure...?!

> (region selection may be expensive?).
in a way, but not that much and not for only one rect.

Do you display the window geometry on move/resize?
Comment 14 Gregor Kališnik 2010-10-09 10:23:02 UTC
I forgot to mention, Idle cpu load is now 1-10%.

By wobbly I ment "Wobbly plugin" :) (sorry for inaccurate naming).

When moving or resizing I don't show anything.
Comment 15 Martin Flöser 2010-10-09 10:43:35 UTC
Just a short remark: starting with 4.6 wobbly windows will not trigger 
constant full repaints any more, but only repaint changed areas.
Comment 16 Gregor Kališnik 2010-10-09 10:49:05 UTC
Great.

Here (http://prene.si/8ZPUa) is a screenshot of artifacts with logout effect (which also is seen with looking glass effect). It may not be connected to this bug at all, but attaching it anyway :).
Comment 17 Thomas Lübking 2010-10-09 19:07:04 UTC
no idea then what could cause the high cpu load on plain composited moving (except for the dual monitor setup, what's with only one screen?)

you could use sysprof (system profiler ;-) to get an idea about what's expensive here...
Comment 18 Gregor Kališnik 2010-10-09 19:24:17 UTC
If turning off the second display (disabling it in system settings), I get the same results.

About profiling, I have to reboot the machine. I'll go play with this app and post results later.
Comment 19 Gregor Kališnik 2010-10-10 12:16:55 UTC
Created attachment 52386 [details]
Sysprof profiling (resize and move)

Here is the profiling. Did a resize and moving.

If it is cluttered, tell me so I will close all apps and do only specific tasks.
Comment 20 Maxim Treskin 2010-11-23 16:17:42 UTC
Vote for this bug
Comment 21 Eugene M. Zheganin 2010-11-24 07:35:06 UTC
For me on 4.5.1 disabling Blur helps a lot. Kwin stops eating CPU and all is really fast.
Comment 22 Martin Flöser 2014-01-08 13:54:26 UTC
It's a long time since the last update to this bug: are the problems still present? We have included quite some optimizations :-)
Comment 23 Maxim Treskin 2014-01-08 13:59:09 UTC
Problem is gone, I've switched to Mac OS X
Comment 24 Martin Flöser 2014-01-08 14:01:25 UTC
(In reply to comment #23)
> Problem is gone, I've switched to Mac OS X
anyone else who can properly comment on whether the problem is solved?
Comment 25 Gregor Kališnik 2014-01-08 14:17:59 UTC
Extremely old bug report :) .

I've since switched to kubuntu and now to Ubuntu.

But if I remember things corectly, the issue was fixed with new versions, but I cannot say when. Also, I'm unable to confirm if it was fixed or not. I would close this as fixed or invalid.
Comment 26 Martin Flöser 2014-01-08 14:27:42 UTC
thanks for the feedback, setting to worksforme, which seems to be best fitted as our users stopped being our users :-(