Bug 229164

please run xrestop, check the value for "total pixmaps", than add the value for kwin (it's probably pretty much up in the list while compositing)

also whatch your cpu load

you're either running out of VRAM (you need the pixmaps + textures on opengl), or the pixmap to texture conversion dains to much cpu (maybe due to constant updates of a plasmoid)

the effective transfer rate of the GPU could be to low (the bus is  only 64bit on probably DDR2) but that should hit the render backend as well.

another problem could be the split output (1440*900 + 1024*768 is slight less than 1920x1200 - is the performance comparable?)

Hi, here are the additional details:

1.xrestop doesn't show anything too scary*.

2.The CPU load without desktop activity is low (say 3% xorg, 2% kwin, and a few others). Moving a large window or playing a full-screen movie brings xorg to 40-45% and jerkiness. I guess the difference from 45% to 50% (as expected for a dual core) comes from xorg locking or kernel activity. Then kwin with 5-15%.

3.The graphical card memory: 256 MB DDR2 (I guess this is what you call VRAM) with 128 bit bus and 950 MHz. Other details here: http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units#Radeon_R600_series. I'll give it a try with Windows and report back.

4.1440*900 + 1024*768 is considerably better than 1920*1200.

*
res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
1800000    36   25    1  285  397    14751K     11K  14763K 20064 plasma-desktop
1600000    94    2    1   72  351    12932K     11K  12943K 20059 kwin
4e00000    26    4    1  173  220     5689K      6K   5696K 20414 Jim Carrey - Saturday Night Live (Dance boys).mpg - SMPlayer
3600000     6    4    1   28   70     4180K      2K   4183K 20132 ch05 : bash
4a00000     5    2    1  151  171     2466K      5K   2471K 20365 Default Session: file:///home/alex/xrestop.txt �~@~S Kate
3c00000     4    2    0   37   88     2161K      2K   2163K 20345 System Monitor
4800000     7    3    1   28   73     1787K      2K   1790K 20356 Desktop Effects �~@~S System Settings
3e00000     4    2    1   42   71     1368K      2K   1371K 20200 Leksah: An Integrated Development Environment for Haskell �~
3000000     5    2    0   13   44     1007K      1K   1008K 20129 Default Session: file:///home/alex/programare/Haskell/ch05/P

Hi, I have tested and both Windows Vista and Compiz work perfectly with 1920*1200 + 1440*900.

Two more pieces of information:
-the more visible windows there are on a desktop the jerkier the behaviour (this can be felt even without attaching another screen to increase the resolution, if for example I open 20 Dolphins).
-moving/resizing is slower as the window is bigger. gmrun is moved nicely in smoothly in almost any situation, a maximised windows is much slower to move.

Again, Compiz is not affected by any of these.

Hi,

Please point me to a method of measuring where the time is spent by KWin, finding which functions take most of the time. This impacts me so much that I'm willing to spend some time at least finding the problem, if fixing it is beyond my capabilities/time.

Thank you.

a) monitor repaints:
load the "show paint" plugin. watch whether there's constant, pot. unmotivated and worst: fullscreen flicker on you screen. (unload it later on, it's really not good for daily work ;-)

b) profiling:
you need to install & run a tool called "sysprof" (has a GUI)
it will tell you to load a kernel module (so you need root access as well)

then you run it a bit (press the play button), do some expensive stuff that bothers you, stop profiling, save the profile and attach it here.

Hi, I have run the tests:

With "show paint" is became obvious the biggest problem here is the "shadow" effect of KWin. Without shadow the destkop is generally usable, as I'll detail. Test conditions are a 1440*990 laptop screen + 1920*1080 monitor at the right.

1. Shadow effect (50% opacity,, 35 fuzziness, 35 size). It causes large amount of repaint. For example in Amarok 1.4 the currently played item changes colour a little constantly. This causes a large paint  in each direction around the playlist item ((around 65 pixel in each direction). The same hold true for the entire area of a video player windows, and for an entire widget that contains a blinking cursor. Shadow is the only effect I use.

2.More than 10 visible windows, with the shadow disabled a little jerkiness appears in moving windows.

3.More than 20 visible windows, with the shadow disabled full-screen video playback starts being jerky (playback on external monitor).

I'll attach a the profiles.

Created attachment 43610 [details]
10 visible windows, moving windows, no shadow

Created attachment 43611 [details]
10 visible windows, moving windows, with shadow

Created attachment 43612 [details]
~20 visible windows, moving windows, no shadow

Created attachment 43613 [details]
~20 visible windows, moving windows, with shadow

the shadow plugin is slow (and broken), try this:
<advert>
   http://kde-look.org/content/show.php/BeShadowed?content=121607
</advert> ;-)
then report again

With BeShadowed performance is better, but I believe there's a place for more performance with many windows visible (granted, tens of windows never happen at home, only at work).
Also, it doesn't compile directly on Debian, I'll put a note there.

Thank you,
Alex

The Shadow effect will be dropped in 4.7

Git commit 3b8984d630cc6dc655a171fa9c0f7e74e9ee3c61 by Martin Gr����lin.
Pushed by graesslin into branch 'graesslin/kwin-cleanup'.

Remove Shadow Effect.

The shadow effect is known to be broken since at least 4.5.
It is unfortunately in a state which makes it difficult to maintain
and the architecture has some serious drawbacks. Therefore it is the
best solution to replace the effect with a new and better
implementation. For more information about the new implementation
please see the discussion on KWin mailinglist:
http://lists.kde.org/?l=kwin&m=129607406517609&w=2

This also "fixes" all existing bug reports about the shadow effect.
Most of the bugs will really be fixed when the new shadow system is
implemented, if not it is a new bug and a new report should be created
for it.

Please excuse that we go this unnormal approach to mark bugs as
fixed with code removal.
BUG: 164084
BUG: 160948
BUG: 189241
BUG: 229164
BUG: 258663
BUG: 216709
BUG: 243890
FIXED-IN: 4.7.0

M  +0    -1    kwin/effects/CMakeLists.txt     
M  +0    -7    kwin/effects/configs_builtins.cpp     
D  +0    -31   kwin/effects/shadow/CMakeLists.txt     
D  +0    -786  kwin/effects/shadow/shadow.cpp     
D  +0    -166  kwin/effects/shadow/shadow.desktop     [TRAILING SPACE] [TRAILING SPACE]
D  +0    -102  kwin/effects/shadow/shadow.h     
D  +0    -128  kwin/effects/shadow/shadow_config.cpp     
D  +0    -91   kwin/effects/shadow/shadow_config.desktop     
D  +0    -57   kwin/effects/shadow/shadow_config.h     
D  +0    -258  kwin/effects/shadow/shadow_config.ui     
D  +0    -70   kwin/effects/shadow/shadow_helper.h     
M  +0    -4    kwin/kcmkwin/kwincompositing/main.cpp     
M  +9    -20   kwin/kcmkwin/kwincompositing/main.ui     

http://commits.kde.org/a5d5b61a/3b8984d630cc6dc655a171fa9c0f7e74e9ee3c61