Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc OS: Linux Regression compared to the old kwin: When resizing a window, with opaque resize, the application gets too many resize events, and gets really behind the mouse position, it feels VERY slow. Let me detail how to reproduce: - take a window by a corner, e.g. bottomleft corner (the app doesn't matter, e.g. konsole or xemacs behave the same) - move the mouse away very fast You'll see the window be resized to N intermediary positions between the original position and the current mouse position. Once the mouse is at a given position, the window should be directly resized to that position, not to all the intermediary positions for which kwin got resize events. Without knowing the code, I feel that this is a lack of compression of those resize events: once the app is ready, only send the latest one, not all the intermediary ones.
I posted a message to kde-devel concerning this, but it didn't get a response --- the bug tracker is probably a better place. Anyway, this is an elaboration of the situation described in the original report. ----------------------------------------------- Opaque resize behavior in kde seems to be quite bad in 3.2. Windows that would resize perfectly smoothly (no lag between contents and frame) in 3.1.x now exhibit significant lag. Window movement also seems to be worse. In previous versions of KDE, I never noticed the "expose lag" between the time a window is moved and the time the underlying window is updated. Now, most apps exhibit at least some expose lag. Worst of all, there is this new "floating resize" problem. Resizing a complex window will sometimes result in the resize process being totally unresponsive to the mouse and the window border will "float" (move slowly at a regular speed) from the original size to a new size. I think the problem is with kwin III. The resize problem became apparent after the kwin III merge (I ran KDE CVS on both side of the merge point, and noticed the change immediately --- before the merge 3.2 was even better than 3.1.x). The window move and floating resize problem only became apparent after I upgraded to Linux kernel 2.6-test9. In xfce, KDE apps resize as they normally do, and in xfce and Window Maker, I can't detect any expose lag at all when moving KDE windows around. I'm running Orth's KDE CVS Debian packages dated Nov. 5 on Debian unstable. The machine is a 2.0 GHz Pentium 4 with XFree 4.3 and NVIDIA's binary drivers.
It should be better now.
*** Bug 69152 has been marked as a duplicate of this bug. ***
I think that there is an option missing... I can select either to show window contents while resizing (constant redraws), or not at all. I would really like to be able to select a third option to show window contents while resizing, but limiting the redraws to once per 250 or 500 milliseconds to reduce CPU load (and make it usable on my old SPARCstation 20).