Version: (using KDE KDE 3.1.93) Installed from: Compiled From Sources OS: Linux When the mousepointer refresh rate is high, dragging one window around the screen with another complex window begind it is painfully slow. When you keep dragging for a while, and the window in the background can't keep up the redrawing, it will keep redrawing itself after you stopped moving the mouse. It seems that this is what's going on: When the time between two mousepointer position updates gets smaller than the time needed to redraw a window, the window-refresh commands seem to be queued, and the queue gets longer and longer. When you stop moving the mouse, the window can still be busy for some minutes, redrawing itself hundreds of times. I configured KDE to show the window contents while dragging. I have configured the mouse at a sample rate of 300 and a resolution of 200. When I reduce both the sample rate and the resolution to 100, the problem is gone.
*** This bug has been marked as a duplicate of 66915 ***
I don't think this is actually a duplicate. The other bug is a problem with redrawing the active window contents when resizing a window. This is a problem with redrawing *other* window contents when *moving* a window. This exact problem exists also in Windows, you can easily drive the CPU usage to 100% simply by moving a window around quickly (and waiting for the background windows to redraw themselves even though the foreground window is never redrawn). The problem is that the background window contents are not tracked, and so a redraw is required whenever a previously hidden area is uncovered. It would be very nice if this could be corrected, but I'm not sure if it's a problem with X11 or QT rather than KDE. The same problem exhibits itself when an application hangs. When the application is asked to redraw the window contents, it of course cannot, and so you see only white area in any area within the application that another window is dragged over.