Bug 202079

Summary:	kwin extremely slow when resizing some windows without compositing
Product:	[Plasma] kwin	Reporter:	Martin Koller <martin>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Martin Koller 2009-07-31 14:03:13 UTC

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.

Comment 1 Thomas Lübking 2009-07-31 15:05:05 UTC

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)

Comment 2 Martin Koller 2009-08-01 18:14:44 UTC

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 ...

Comment 3 Thomas Lübking 2009-08-01 18:27:13 UTC

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

Comment 4 Martin Koller 2009-11-06 07:10:18 UTC

I've now switched to a new Laptop using an Intel GPU. The problem is gone here, so I close this.