Version: (using Devel) OS: Linux Installed from: Compiled sources (Posting this as suggested by Beat Wolf at http://bugs.kde.org/show_bug.cgi?id=178254#c1) I'm running Kubuntu 8.10, with the KDE 4.2 beta 2 (4.1.85 Intrepid packages) available from the kubuntu.org ppa. The performance of kwin is such that I can *see* windows being drawn. If I minimize - for instance - System Settings and then restore it again, it first draws the borders, then I see certain fields as filled with white with the rest of the application space taking the colour of the application background grey (default for the Ozone window theme). After that, text and other things like drop-down menus start to appear, not necessarily from the bottom up. The entire drawing takes upward of a second. This is with all desktop effects disabled. krunner is another good example. Since the run box window (Alt+F2) resizes as it figures out suggestions, the space it's expanding into is allocated in white long before any content is drawn into it. As an experiment I enabled effects and set the animation speed to Extremely Slow, and did the same System Settings minimize/restore procedure, with the Minimize Animation and Fade effects enabled. When restoring, the window was drawn up to the point with the white fields, which then glided into view. Once in place and at the right size several seconds later (again, extremely slow setting), it proceeded to draw the text and the remaining interface details. As such, it gives the appearance the drawing isn't /slowed/ by the effects, but rather /delayed/. Compiz (and emerald or gtk-window-decorator) does not exhibit this behaviour; replacing kwin immediately speeds things up. Compiz wins out even with heavy effects enabled, versus kwin with no effects. DO NOTE: This is on two machines with intel video chipsets, that *also* exhibit bugs 178254 (http://bugs.kde.org/show_bug.cgi?id=178254) and 170462 (http://bugs.kde.org/show_bug.cgi?id=170462), in case that matters. kde-window-manager: Installed: 4:4.1.85-0ubuntu1~intrepid1~ppa1 xserver-xorg: Installed: 1:7.4~5ubuntu3 xserver-xorg-video-intel: Installed: 2:2.4.1-1ubuntu10.1 My /etc/X11/xorg.conf is clean, with no extra options defined. I realize this comes through as a very vague "kwin is slow, why is this" report, but while other people comment on recent kwin builds being substantially faster than earlier 4.1.x builds, I can't say I agree. Please let me know if you need me to provide more information.
KWin doesn't draw window contents, what you are experiencing is an X/configuration problem. Not marking as UPSTREAM yet though as I would like more information on why it doesn't occur in Compiz.
*** This bug has been confirmed by popular vote. ***
I'm using kde 4.2 rc1 and i have this problem too, with or without composite. I don't know if this is kwin's fault or not, i doubt it, Skype, for instance, doesn't show this problem. On some apps the problem seems worse (such as with Dolphin) than in others. My videocard is a Nvidia (yes i know... a very bad choice :\ ) Since Skype doesn't seem to show the problem could this issue be related to Oxygen as they suggest in this bug https://bugs.kde.org/show_bug.cgi?id=178131 ?
(In reply to comment #3) > Since Skype doesn't seem to show the problem could this issue be related to > Oxygen as they suggest in this bug https://bugs.kde.org/show_bug.cgi?id=178131 > ? No, that can't be related as Skype windows use the same window decoration. Nevertheless it could be the widget style. That could be easily tested by choosing a different style (e.g. plastique). Although I hardly believe it as there would be much more complaints ;-)
Skype and GTK apps on Suse 11.1 (64 bit edition) do not show any repainting problem. So: - kwin does not seem to be the problem since skype and GTK apps use kwin too and they are fast - Oxygen does not seem to be the problem either: with different themes the speed does not seem to improve - QT is used by skype and it is dynamically linked like other KDE apps so i doubt they have anything to do with it Could it be something related with the color schemes? It looks to be a problem related to something that Skype and GTK apps do not use and KDE does. Any suggestion or test i could do? Any way i could gather more informations out of my system?
I have this problem too. I have had it on suse 11.1 and kubuntu 9.04 alpha 3, but while on the first one the problem would just always be there, on the second one the problem shows up only when composite is deactivated.
After logging into the system and launching dolphin I no have this problem. The windows restoring works well, but after some time and after launching a few more applications this problem happens to me too. Restoring all windows drawn by parts, and this applies for GTK applications too. In case with Firefox it draws borders, then the application menus, tabs and the content at least. Worse of all is when Kwin draws the Amarok window :) I think, this problem is there already very long time, and I've not notice it before because I used the "Keep windows thumbnail: Always" option. But this option breaks minimization and after I switch to "Only for shown windows" I could see this bug. Arch Linux (x86_64) with latest updates on AMD 3500+ with GeForce 9500GT.
this is not about compositing. the clients internal drawing seems to lag/be blocked and this seems to be related to kwin being the window manager ("Keep windows thumbnail: Always" prevents any un/mapping so there's no show/hide on the X11 level) -> i suspect XSync relation (whatever it's supposed to _really_ do (i know the general idea, the timer worries me), things run better here if i undefine HAVE_XSYNC *before compiling* kwin (i don't think there's a runtime environment)
I have encountered the same problem, and I confirmed the following: - Compositing is not the problem. - Switching to another window manager (twm) while keeping everything else the same fixes it. - It seems to affect almost all redrawing, and intuitively the delay seems to be O(w * h), where w and h are width and height of area to be repainted.
I recompiled the kdebase-workspace package (from Kubuntu PPA, using apt-get source and debuild to build debian packages) after commenting out the following line in ConfigureChecks.cmake: macro_bool_to_01(X11_XSync_FOUND HAVE_XSYNC) # kwin This made things much faster.
related bugs: #183263, #241094 & #243094
An update was just pushed to the Kubuntu Beta PPA. Along with an update of pretty much every KDE package, the 'kde-window-manager' package was upgrade from version 4.4.90-0ubuntu1~lucid1~ppa7 to version 4.4.92-0ubuntu1~lucid1~ppa3. This new version seems quite smooth. Even smoother than my recompiled version of 4.4.90 with XSYNC disabled. Did this update fix it for anyone else?
I tried it right now and want to notice that the problem is still here. I still see repainting, not worse than previously. KDE 4.4.92 on Arch Linux (kde-unstable repository).
Created attachment 49177 [details] fix attempt can you please check whether the attached patch fixes it? (fixes clemens testcase in bug #243094 for sure)
Hello everyone! Thomas, I have recompiled kdebase-workspace 4.5.1 with your patch applied to it, and I can definitely say that it improves performance a lot on my hardware as well as having much lower temperatures (3-4 C down on average). Without the patch, the slidingpopups effect on both kickoff and yakuake is laggy (essentially you see 2-3 frames of the animation) and PowerMizer ramps up Clocks to maximum levels. If powermizer keeps clocks to lowest values and i execute dolphin the window is drawn after 0,5-1,5 seconds. With the patch applied, PowerMizer almost always is at the lowest clock and the fan is almost always silent. Furthermore, slidingpopups effect is smooth even on lowest clock and dolphin is drawn instantly or after 0,5 sec tops. Using nvidia 330m on a vaio f11, 256.35 nvidia proprietary driver, VSYNC on (nvidia-settings+kwin-settings), x.org-server 1.8.2, kde 4.5.1 on archlinux. I hope this is confirmed and commited. I am willing to test patches and help with this. Also if there is any way of objectively reporting my experience please tell me. Thanks for your work!
SVN commit 1175748 by luebking: fix pending XSYNC requests, bugs partially closed due to suggested relation by the reporters please re-open them if this does not fix it BUG: 178269 BUG: 183263 BUG: 241094 BUG: 243094 M +1 -0 events.cpp M +0 -1 geometry.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1175748
KDE 4.5.3 and this bug is not fixed for me. For example: when I hide amarok by clicking on its tray icon and then restore it back — it works good and smooth (I use fade effect). But when I do the same by clicking its taskbar button (fade effect is unavailable here (btw, why? it would be nice)) I still see redrawing, not worse that before. Without fade effect I see redrawing in any case.
patch is only in trunk -> 4.6 not by policy, but nobody seems to really know anything about the XSYNC code... :-\
*** Bug 230609 has been marked as a duplicate of this bug. ***
Applying the patches found in http://websvn.kde.org/?view=rev&revision=1175748 against 4.5.3 I can happily say that the improvement is noticeable. Switching between desktop no longer takes half a second to show contents of windows as neither does minimizing and restoring windows. Great patch indeed! Looking forward Kwin in 4.6 because it looks really promising! Keep up the great work guys!
Thomas Lübking; Can we backport the fix to the 4.5-branch to have it in >=4.5.4?
In Short: "if someone is willing to take me out of charge" =) Long version: I'm pretty confident that this just and actually fixes the bug and esp. has no harm, but the (sad) truth remains that _nobody_ seems to actually know about the "weak"(ly defined) parts of the XSYNC_REQUEST protocol* or the implementation in kwin. I didn't know what i was doing either - just made a state analysis & some assumptions, then tested the implications ("smells like a deadlock in the client") against clemens' testcase (never encountered the real bug) and it worked. But i just cannot say: "hah! this is a bug because 'xyz' is wrong" So: If it is and i get a qualified "ok"** to take the (pretty) weak risk of a regression in a minor update against the gain of the fix - sure, technically it can be backported. But - sorry - i'm kinda "satelite" and certainly not, nor actually want to be in the position to decide such (i don't know or care too much about KDE release/patch policies...) and unfortunately cannot guarantee for the patch either, because "i don't know what i was doing" :( => Causes trouble in 4.6 (beta): ok, blame me. Causes trouble in 4.5.4: i _want_ immunity first ;-) (if you want a pretty save workaround, just undefine HAVE_XSYNC - *shrug*) *as defined here: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552503 reading "After receiving one or more such message/ConfigureNotify pairs..." it doesn't seem kwin was doing anything wrong here.... now we just ensure "one" (request message) in contrast to "or more" =\ ** judging from a quick gg result: http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft the answer to your question is a simple "no", but this is actually only a draft personal note: while it's certainly important for big things like KDE, release schedules are imho <censored>###### ####### ########</censored> ;-P
FYI: it has been decided to NOT backport the patch because of the mentioned reasons. i can only suggest to update to 4.6 beta or to ask your distro to just backport it. sorry.
I still see redrawing in KDE 4.6.3. Some effects (like minimizing animation) help to hide this issue, but not fix it.
This bug is about extreme low client update frequency and also applies when compositing is NOT enabled at all. Even iff - the minimizing animation would not be related in any way since this has nothing to do with minimization etc. but the server is just constantly waiting for 500ms before the client can pass an update. This bug https://bugs.kde.org/show_bug.cgi?id=243094 has an attachment that made the issue of this report fully reproducable (and lead to the fix, thanks to Clemens) I do however not think that you're (currently) experiencing this bug. Given all your other bug report hooks you rather seem to suffer from low performance WITH compositing and likely due to low memory frequency - possibly due to powermizer (compositing invokes AT LEAST a complete read/write cycle, doubling the memory speed requirement - in the end, it's more like 3 times) and/or animated window activation what's dog slow on nvidia :-(
and as confirmation; for me the issue was fixed with 4.6 and KWin is fast again :)
These effects does not help in case when many windows is opened. Especially If I'll open Firefox and Netbeans and then try to minimize amarok to systray and restore it back. If I'll minimize all the windows and retry with Amarok — redrawing is shorter and almost invisible.
This has /nothing/ to do with this bug. This bug is NOT about compositing! It is NOT related to the amount of windows opened or on screen. If you're *really* experiencing slowdowns with many windows and WITHOUT COMPOSITING, there's either an overhead in the decoration or it's not KWin related at all. If it IS about composting, your system/GPU is likely at its memory bounds. You maybe do ex- or implicitly use ARGB windows (translucent style, custom colormap on the root) or maybe even just translucent windows (through a rule or the translucency plugin) It could also just be due to the blur effect. Please open a new bug or post to a matching one, specify your HW and setup (effects in use). Specify the term "redrawing" (in the client or when moving/resizing) Contact me by mail if you must, but please: Do not spam every bug that sounds like "kwin is slow" - that is not helpful at all. Thanks.