Version: (using KDE 4.2.98) OS: Linux Installed from: SuSE RPMs I'm using openSuse 11.1, IBM Thinkpad T43 Laptop with ATI GPU and fglrx driver. Desktop effects are DISABLED. kwin from KDE3 works smoothly when resizing windows. The same applications which were resizing smoothly with kwin/KDE3 are suddenly resizing very slowly with kwin/KDE4. So it is definitely _not_ an issue with Xorg or the driver. However, I see that the problem occurs only with applications which define a hint for the wm to resize in steps and not in pixels (hope my wording is clear). E.g.: the slow resize happens with konsole or gvim but does not with konqueror or kolourpaint(KDE3) Interesting is also the fact that during my resize tests the CPU usage did not increase much (~12%). So for me it seems not to be a problem of the executing of code but more a problem of some timeout/delay before resizing is done. Move, minimize, maximize, restore is fast as usual.
souds related to bug #183263 - though this was only about GTK apps (and i cannot reproduce it with e.g. konsole, which -unlike e.g. xterm- on the other hand apparently resizes by px here)
I discovered something interesting: When I have already turned off all window effects/compositing when I log in, then the speed on resizing as described is OK. The problem described originally was seen when I have the effects turned on during KDE login but then later I turned them off. It seems that turning off does not really turn off all things ...
at least konsole checks for available copmpositing on startup and create an ARGB context - or not. so (if konsole was your testcase) check whether shutting down /all/ konsole windows (they run in one instance, "ps -A | grep konsole" to be sure) turn off compositing, open a konsole -> check resize behaviour -> enable compositing -> check resize behaviour again
I've now switched to a new Laptop using an Intel GPU. The problem is gone here, so I close this.