Bug 69152

Summary:	Moving windows painfully slow when mouse cursor update rate high
Product:	[Plasma] kwin	Reporter:	Dik Takken <kde>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Dik Takken 2003-11-27 15:28:19 UTC

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.

Comment 1 Lubos Lunak 2003-11-27 15:40:16 UTC


*** This bug has been marked as a duplicate of 66915 ***

Comment 2 Casey Allen Shobe 2003-12-04 08:53:16 UTC

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.