Bug 256654

Could you try profiling this issue with sysprof so we can see where time is spent when moving a window?

Also, if you have trilinear filtering enabled, does it still happen if you disable it?

Not sure if i made it right (enabled CONFIG_PROFILING in the kernel, recompiled kwin/mesa/libdrm with -g and -fno-omit-frame-pointer), then launched sysprof and  moved a konqueror window non-stop across the screen during 20 seconds.

Created attachment 53371 [details]
sysprof output using kwin 4.5.3 while moving a window

Created attachment 53372 [details]
sysprof output using kwin 4.5.3 with r1189360 reversed

Almost forgot, i haven't using trilinear filtering, just the one named "nearest".

Things are slow for me also using 2.6.37, r300g from a recent git mesa 7.11-devel and git xf-86-ati on my laptop's X2300. For example there seems to be a lag while starting moving a window and a smaller one while moving the window around. Another example, in the menu regarding widgets and activities at the top right corner, selections are updated slowly. I can clearly see the highlighting of each selection, if I move from the top selection to the bottom.

Unfortunately I can't test if 4.5.2 is ok for me, since I am using 4.6-rc2.

Actually, I tested with 4.5.2 and it performs much better than 4.5.3 (and higher versions).

My system: Arch Linux (kernel 2.6.35 32-bit) on CoreDuo with Radeon X1600 (using open-source drivers)

I'm running KDE 4.5.4 (except for kde-base-workspace which is 4.5.2). I also tested with 4.5.1 and its even better but plasma was not functioning properly, probably due to the kde-base-workspace version being too old compared to the rest of the KDE packages.

Removing shadows make things snappier while moving. But the menu still is very slow...

Created attachment 55891 [details]
Possible fix

Does this patch fix the problem?

Please note that it only applies to trunk and the 4.6 branch.

(In reply to comment #9)
> Created an attachment (id=55891) [details]
> Possible fix
> 
> Does this patch fix the problem?
> 
> Please note that it only applies to trunk and the 4.6 branch.
Nope, applied the patch to kwin-4.5.95 (4.6 rc2) and the window movements are still very slow with desktop effects enabled. Reverting the commit indicated in my first comment still fixes the issue for my r300g.

same problem with r300g.

test:
kdebase-workspace 4.5.2, 4.5.5, trunk (with/without Fredrik patch)

System:
debian unstable, kernel 2.6.37, mesa 7.10 and llvm support
ati x300, xorg 7.6 and git xf86-video-ati

I upgraded my kernel to 2.6.38 for pageflipping with updated x driver, and compiled latest mesa tree for optimizations:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=1f0348c4a2ba4f8ca812a2daccf3b01c3f984ef1

and 
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ac6306e9ca904ae9674bf2a15222efe4cb861bf5

but unfortunately moving a window is still slow.

SVN commit 1215519 by fredrik:

Don't specify the texture target explicitly with r300g.

This is reported to cause a performance regression.

FIXED-IN: 4.6.0
BUG: 256654


 M  +6 -0      scene_opengl.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1215519

This commit should have the same effect as reverting the commit that caused the regression, but only for r300g.

I'm still not sure why that commit caused a performance problem with r300g, because in theory it should actually improve performance with all gallium drivers.

Git commit 9028fcca0ab707715f372fc25c42e643764857b2 by Martin Gr����lin. on behalf of Fredrik H��glund
Pushed by graesslin into branch 'graesslin/kwin-coding-style'.

Don't specify the texture target explicitly with r300g.

This is reported to cause a performance regression.

FIXED-IN: 4.6.0
BUG: 256654

svn path=/branches/KDE/4.6/kdebase/workspace/; revision=1215519

M  +1    -0    kwin/scene_opengl.cpp     
M  +15   -10   kwin/scene_opengl_glx.cpp     

http://commits.kde.org/a5d5b61a/9028fcca0ab707715f372fc25c42e643764857b2