Bug 229164 - Shadow effect slows down compositing
Summary: Shadow effect slows down compositing
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-02 20:31 UTC by Alex Dănilă
Modified: 2011-01-31 22:06 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
10 visible windows, moving windows, no shadow (79.65 KB, application/octet-stream)
2010-05-15 17:25 UTC, Alex Dănilă
Details
10 visible windows, moving windows, with shadow (81.09 KB, application/octet-stream)
2010-05-15 17:26 UTC, Alex Dănilă
Details
~20 visible windows, moving windows, no shadow (240.46 KB, application/octet-stream)
2010-05-15 17:27 UTC, Alex Dănilă
Details
~20 visible windows, moving windows, with shadow (109.96 KB, application/octet-stream)
2010-05-15 17:27 UTC, Alex Dănilă
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Dănilă 2010-03-02 20:31:07 UTC
Version:            (using KDE 4.3.4)
OS:                Linux
Installed from:    Debian testing/unstable Packages

When compositing is enabled, everything draws slower as the screen size gets bigger. With only the laptop screen or only the external screen (or other combinations that don't add the two surfaces) the drawing speed is either excellent (no lag noticeable) or very good.

Adding an 1024x768 external screen makes drawing slower, while 1920x1200 makes it already bad. Low drawing speed means that window moving/resizing is slow, kwin effects are jerky, playing a movie in a big/full-screen windows is jerkier as the window is bigger.

The slow-down is very noticeable with OpenGL compositing, and much less with XRender. Playing with the OpenGL compositing options doesn't improve things. Disabling compositing fixes the issue entirely.

Video card is a Radeon HD3470, and with the current driver the performance is sufficient to run for example Torcs with decent details and resolution. Please give a link to benchmarking methods if you need numbers.

This happens with both radeon and radeonhd drivers, and I am almost sure it happened with fglrx, but I cannot currently test.

xrandr info:
Screen 0: minimum 320 x 200, current 3360 x 1200, maximum 3360 x 1200
VGA-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200      60.0*+
   1600x1200      60.0
   1280x1024      60.0
   1280x960       60.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
LVDS connected 1440x900+1920+0 (normal left inverted right x axis y axis) 367mm x 230mm
   1440x900       59.9*+
   1280x854       59.9
   1280x800       59.8
   1280x720       59.9
   1152x768       59.8
   1024x768       59.9
   800x600        59.9
   640x480        59.4
HDMI-0 disconnected (normal left inverted right x axis y axis)
Comment 1 Thomas Lübking 2010-03-02 21:07:16 UTC
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?)
Comment 2 Alex Dănilă 2010-03-02 22:49:38 UTC
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
Comment 3 Alex Dănilă 2010-03-03 21:09:06 UTC
Hi, I have tested and both Windows Vista and Compiz work perfectly with 1920*1200 + 1440*900.
Comment 4 Alex Dănilă 2010-03-06 00:32:09 UTC
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.
Comment 5 Alex Dănilă 2010-05-12 23:47:57 UTC
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.
Comment 6 Thomas Lübking 2010-05-13 00:09:42 UTC
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.
Comment 7 Alex Dănilă 2010-05-15 17:24:17 UTC
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.
Comment 8 Alex Dănilă 2010-05-15 17:25:36 UTC
Created attachment 43610 [details]
10 visible windows, moving windows, no shadow
Comment 9 Alex Dănilă 2010-05-15 17:26:24 UTC
Created attachment 43611 [details]
10 visible windows, moving windows, with shadow
Comment 10 Alex Dănilă 2010-05-15 17:27:02 UTC
Created attachment 43612 [details]
~20 visible windows, moving windows, no shadow
Comment 11 Alex Dănilă 2010-05-15 17:27:39 UTC
Created attachment 43613 [details]
~20 visible windows, moving windows, with shadow
Comment 12 Thomas Lübking 2010-05-15 17:39:51 UTC
the shadow plugin is slow (and broken), try this:
<advert>
   http://kde-look.org/content/show.php/BeShadowed?content=121607
</advert> ;-)
then report again
Comment 13 Alex Dănilă 2010-05-15 20:55:25 UTC
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
Comment 14 Martin Flöser 2011-01-22 09:16:28 UTC
The Shadow effect will be dropped in 4.7
Comment 15 Martin Flöser 2011-01-31 22:06:20 UTC
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