Version: (using KDE 4.3.0) OS: Linux Installed from: Debian testing/unstable Packages Hello, I am not sure if I should mark this as a bug or a wish. But IMHO this makes KDE4 very less usable, so I make this a bug report... I am using an nvidia card with the latest nvidia driver NVIDIA-Linux-x86-185.18.31-pkg0.run. If I have many windows open on one virtual desktop (reproduced with 20 konsole windows) and switch from an empty desktop to this one, the window decorations take very long to (re)draw. The last action is drawing the active window again (the stripes in oxygene or the blue border in plastik), that already has been drawn before as inactive window. The complete drawing takes about 1,5 seconds. It looks if there are many flickerings in the decoration drawing. So I think that there are many refreshing calls internally that could be optimized. It does not make a difference changing the decoration from oxygene to plastik or keramik. To compare the speed with another window manager I started "openbox --replace". With this window manager the windows are drawn _much_ faster. Maybe 0,2 seconds or something like this. (All times are estimated.) It would be great if the decorations could be made faster. Thanks, Gert
What does it happens if you use kwin with another decoration like "plastik" ?
I first thought that keramik was a little bit faster, but I am very unsure with this. At least I think it does not make a difference.
Ok, I've moved the bug to kwin.
did you try w/ and/or w/o compositing? how's cpu load before, during and after repainting? if high: in X11 or in kwin? just in case you've installed it anyway: tried with the bespin deco? (it's the only one i know of that does not inherit kcommondecoration, but this is unlikely the cause - more a shot in the dark)
And I have another shot in the dark: can you try with other applications than Konsole. Konsole is one of the only ARGB windows. So can you try for example with kwrite.
I can reproduce the behaviour on another sidux PC. This PC is a bit slower than my other and the refreshing of 20 konsole windows takes about estimated 6 seconds. cat /proc/cpuinfo ... cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2200+ stepping : 1 cpu MHz : 1800.124 cache size : 256 KB ... A) The bug addresses a desktop with composite turned off. With composite turned on the desktop switch is fast and you do not see any refresh problems. B) Before switching the desktop the CPU is idling. While switching the desktop I as running "top" in the active console and you see something like this (2 examples): 4216 root 20 0 266m 123m 2960 R 72.7 16.4 1:33.64 Xorg 4538 gert 20 0 133m 28m 9928 S 21.6 3.8 0:40.60 kwin 4628 gert 20 0 137m 22m 7140 R 2.0 2.9 0:10.55 konsole 4216 root 20 0 254m 108m 2960 R 96.4 14.4 1:59.78 Xorg 4628 gert 20 0 137m 22m 7164 R 1.7 2.9 0:11.31 konsole 7490 gert 20 0 282m 50m 25m S 1.7 6.7 0:05.44 plasma-desktop After everything is redrawn the CPU is idle again. I get to the other two questions in the next comment...
With 20 kwrite instead of konsole windows the refreshing is much faster (about 1 second instead of 6), but I think this is still too slow. So the ARGB thing might be an important fact but not the only one? Regarding bespin: It seems there are no debian/sid or debian/experimental bespin packages. So I have to search for it and install it manually. I will try.
Well, I cannot find a bespin debian package nor the tarball. Also the project seems to be kind of outdated? I you would like me to test it anyway, can you provide me a link to a tarball download? (Or maybe cvs or svn repos?)
regarding konsole's ARGB state iirc it only sets this color mode if compositing is enabled when you launch it (also check whether the konsoles run in different processes the way you launched them) quick test to confirm the ARGB mode "Settings" -> "Edit current profile" -> "Appearance" tab: set some background transparency (10%-20%) if you can look through the terminal part though the window opacity is 100% (and while compositing is enabled) the ARGB mode is set.
Created attachment 36356 [details] Testcase spawning (ARGB) windows Here's a simple test to check whether the ARGB mode is the culprit. lauch "argbwindows [ARGB [n]]" where "n" is the numbers of windows to be spawned (default: 20) The ARGB parameter is case SENSITIVE Compile instructions on top of the sources, requires Qt4.5 It will spawn some windows and in case ARGB is set you can look through a red background (black otherwise)
@Thomas, comment #9: You are right. If I first open the 20 konsole windows and than turn off composite, the drawing of the windows takes about 6-7 seconds. If I first turn off composite and open the konsole windows after this, the drawing is as fast as with the kwrite windows. Testing with "openbox --replace" on this machine: Switching to a desktop with 20 argb-konsole windows on it, does take many seconds, too. (maybe 6 or more seconds). Switching to the desktop with the kwrite windows is still a bit faster than with kwin. (maybe <0.5 seconds vs ~1 second). Regarding comment #10: Is it somehow interesting to try this test tool? (Should I try it?)
(In reply to comment #11) > Regarding comment #10: Is it somehow interesting to try this test tool? > (Should I try it?) Yes please. It will help us to understand whether this is a bug in konsole (or X11 or somewhere else upstream)
bespin: I have tried this now and could not find a difference in drawing speed compared to oxygene. argbwindows: I will try this next.
I now have argbwindows running. I am not sure what I should test. What I did: * Turned off composite * run "argbwindows" (without parameter ARGB) on an empty desktop => switching to the desktop is approximately as fast as with the 20 kwrite windows (about 1.5 seconds) * run "argbwindows ARGB" on an empty desktop => switching to the desktop is approximately as fast as with the 20 kwrite windows (about 1.5 seconds) So the ARGB parameter does not make a difference. But without composite I certainly cannot look through the background. Should I open the windows with composite turned on and turn it off after opening them?
You can only look through as long as composite is active, but the windows get and keep their ARGB colormode independent from the current composition mode. If you suspend or turn of compositing, launch the test w/ the ARGB parameter and then resume/activate compositing you should be able to look through them. (Hint: w/o compositing ARGB windows appear more like bordeaux while RGB windows are more "pig" colored) So it does not seem to be the ARGB mode itself. However, the test windows are considerably small - and maybe you just run out of video RAM. Can you set the widget->resize(320,240) call to e.g. widget->resize(1204,768), recompile and test again? (and/or spawn more windows - "argbwindows ARGB 50")
Ok, right. An ARGB-window opened when composite turned off, indeed becomes transparent with turning composite on. I did set the window size to 800x600 and opened 40 windows on one desktop. When I switched to this desktop the first time, this was quite fast (>1 second). Then I switched to an empty desktop and back to the 40-windows desktop several times. With every new switch the drawing time became longer. After ~10 switches I had to wait ~15 seconds. Maybe this is related to some plasma crashes (the plasma-desktop did sometimes restart without showing the crash handler)? Or did it only look like restarts but it were redraws? I will try this tomorrow again with a freshly started xorg.
you can get plasma out of the way for testing "kquitapp plasma-desktop" and later restart it "plasma-desktop" But it also acquires some memory - so the problem may be delayed. Nevertheless this could be some memleak. Can you watch RAM with top (press "shift+m" to sort by memory) and Pixmap allocation (VRAM) with "xrestop" during your desktop journey?
Created attachment 36402 [details] xrestop and top output on test with 40 ARGB windows Because the output is a bit longer I submit it as attachment. I did a test with 40 ARGB windows. The problem of desktops getting slower on each desktop switch did not show up in this test. Maybe because I had some windows less opened (no konqueror, xterm instead konsole, no icedove). Plasma desktop did crash again multiple times (traceback included). See bug 199325. I will repeat the test with 60 windows next.
Created attachment 36403 [details] xrestop and top output on test with 60 ARGB windows With 60 windows I could not reproduce the probleme, too. Drawing times are worse, but did not become longer each time. Two things are interesting: a) Starting a konsole window instead of an closed ARGB window did make drawing times much longer. b) After starting openbox and switching back to kwin, drawing times were very fast first and then become longer again. Conclusion: I do not know. It feels like the problem is not in KDE, but instead in xorg/nvidia/kernel? btw: All tests were done with composite turned off via Alt+Shift+F12 except where described.
Do you allow me one question? Is it possible to configure konsole to never open as ARGB window even if composite is enabled? This could save me some important video memory. (As long as transparency is set to 0, konsole should not use the ARGB mode IMHO)
(In reply to comment #20) > Is it possible to configure konsole to never open as ARGB window even if > composite is enabled? This could save me some important video memory. (As long > as transparency is set to 0, konsole should not use the ARGB mode IMHO) yes that's possible. Just start Konsole with --notransparency
I have recorded three short videos with a camcorder. The quality is not very good because of conflicting screen refresh frequencies, but you can see how the problem looks like. 1) kwin with composite on => fast 2) kwin with composite off => slow 3) openbox with composite off => fast There are 19 xterm windows on one desktop and 1 xterm on a second one and I switch between these two desktops. Using KDE4.3.4 in sidux, NVIDIA-Linux-x86-190.42-pkg0.run, kernel 2.6.32-0.slh.8-sidux-686, nVidia NV44A [GeForce 6200]. Because the desktop is not running very long and there are only 20 windows the decoration redraw time in case 2) is only about one second. With more windows it can become multiple seconds. The videos are about 9MB alltogether. May I attach them here?
The bugzilla upload limit probably doesn't allow it. Would you like to upload in a FTP server or something similar? thanks :-)
I have never user videobin before and I am not sure how long the keep the videos, but I do not have any private web-space available. Here you can find the videos: http://videobin.org/+o9/sr.html
i've just seen a "similar" issue (old nvidia card, no compositing) while under kde/kwin thigs went really slow (apparetly esp. after running gimp or allocating a lot of video ram) while everything was fine with openbox. i did two things: 1) in /etc/X11/xorg.conf, Device section set Option "BackingStore" "True" as it's currently disabled by default 2) moved /usr/lib/libkwinnvidiahack.so.* out of the way (dynamically loaded, just sets an environment var that prevents the driver from yielding - i suspect this behaviour anyway) after an X restart things behaved nicely - maybe you give it a try
I hopefully have tried 1) and 2), each alone and both together, but I cannot see a difference here in any case (nvidia NV44A [GeForce 6200]). But thank you for the suggestions. I am really looking forward to something that helps. Currently I am hoping for Qt4.6 with KDE4.4 and that it will show up in debian/sid soon after release.
what's the state of this with more recent versions of KDE?
I don't want to test this with self compiled KDE versions as these seem to run clearly slower than the packages that come with my distribution (maybe because of debugging-options?) As I am using debian/sid (aptosid) I am still using KDE 4.4.x. Here the drawing of the window decorations is still that slow if compositing is disabled. I hope that KDE 4.6 will come into debian/sid soon after the Squeeze release. I will check out this new version when it is available.
what'S the output of nvidia-settins -q InitialPixmapPlacement -q PixmapCache
I did not have this tool installed. Is it important for a correct setup of the nvidia driver or is it just optional for manual tweaks? After installing it reports: $ nvidia-settings -q InitialPixmapPlacement -q PixmapCache Attribute 'InitialPixmapPlacement' (oink:0.0): 1. The valid values for 'InitialPixmapPlacement' are in the range 0 - 4 (inclusive). 'InitialPixmapPlacement' can use the following target types: X Screen. Attribute 'PixmapCache' (oink:0.0): 1. 'PixmapCache' is a boolean attribute; valid values are: 1 (on/true) and 0 (off/false). 'PixmapCache' can use the following target types: X Screen. btw: atm I am building KDE/trunk (from yesterday) to test if something had changed regarding the windeco speed. Because of the old hardware and all the changes in the repository (to git) I did not manage to finish this yesterday.
(In reply to comment #30) > I did not have this tool installed. Is it important for a correct setup of the > nvidia driver or is it just optional for manual tweaks? optional, but veeeery useful. > Attribute 'InitialPixmapPlacement' (oink:0.0): 1. ok, do $ nvidia-settings -a InitialPixmapPlacement=2 -a $ nvidia-settings -a PixmapCache=0 $ nvidia-settings -a PixmapCache=1 (the tool can do this in one call, but you want to use three!) then check drawing performance. also what's $ nvidia-settings -q GlyphCache
So I tested the different InitialPixmapPlacement values (1, 2 and 4) and I do not see any differences. Maybe 2 is slightly faster, but that could be imagination. It does not really help. Glyphcache is set like this: $ nvidia-settings -q GlyphCache Attribute 'GlyphCache' (oink:0.0): 1. The valid values for 'GlyphCache' are in the range 0 - 1 (inclusive). 'GlyphCache' can use the following target types: X Screen. I also tested KDE4/trunk now (together with Qt 4.7.1 checkout). As I wrote, my self compiled KDE installations run much slower than the binary debian packages... As I see, the speed of window deco drawing is still bad with composite deactivated. It is even worse, but this will because of the debug compilation or something, I think. I think, I will buy me a new PC in 2 months or so with intel onboard graphics of the sandy bridge CPUs. I hope this will run more smooth than the nvidia graphics. But ok, if composite is enabled, everything is snappy. The only problem is, that I cannot use OpenGL (but need to use XRender, that is slower) because I am running into the black window problem. (A friend of mine has the same problem with nvidia, but with compiz window manager, not KDE.) Does turning off the PixmapCache save much video RAM? Maybe this would help against the black window problem? At least I do not see a difference with or without PixmapCache in case of using composite.
the pixmap cache is (afaics - nvidia is css) not used unless InitialPixmapPlacement is 2 (what is -with a fresh cache, thus the 0/1- significantly faster than thn "1" mode here, but should not take memory from GL (the avaiable memory is probably still statically split) and that shouldn't lead to black textures either (this usually means the window size crossed the maximum texture size, "glxinfo -l | grep -i max", however: deactivate all/most effects, notably stuff like "blur" or "sharpen") The whole thing has only impact on xrender & ARGB pixmaps (alphablended 2D painting, icons, etc - also inside applications) so you should check this. For a (very cheap) benchmark, see the attachment of bug #234463
This problem seems to go away randomly for a brief moment, later on, windows are taking too long to redraw. Even happens while only one window is open. I also noticed that moving windows take from about 250ms up to 1000ms to actually be dragged (only when the bug is in effect). After that period, it's dragged fine. I'm also seeing excessive use of memory, probably due to the nvidia blobs. I don't know if this is related.
As of 4.8.0 the PaintRedirector which caused slow rendering with compositing disabled has been dropped for non-composited setups. Because of that I consider this bug as fixed. Please be aware that the Qt graphicssystem has an influence on performance. Depending on which decoration is used switching to native or raster might improve the situation.