Version: (using KDE 4.0.80) Installed from: Debian testing/unstable Packages If i resize a window it take about 2sec to redraw. All other effects seem to work very fast. I have a Core2 Duo E6600 with 2GB of RAM and and ATI HD3870 512MB of RAM. Latest fglrx driver provided by debian testing/unstable (8-5) and latest kde 4.0.82+svn release provided by debian experimental. Thank you all for the great work you are doing. Andrea.
Which application were you resizing exactly? Does it occur when resizing Dolphin?
Well i believe it is a kwin problem because it happens on every window. I tryed for example dolphin,konsole, firefox, system panel administration ans so on. It seems to me that the issue is generated by window refresh. As i said it takes a lot of time before resizing the window and refresh it.
i have this problem using KDE 4.0.83 and latest nvidia 173.14.09 (running opensuse 11 with a gefore fx 5200). maximise and resize is super slow and jerky (maximise takes 3 secs). this used to be an issue for me in KDE3.5.x in compiz fusion, but i would change the resize behaviour to 'outline' instead of the dynamic resizing which would fix the issue. occurs when resizing all windows. i have tried turning off translucency, shadow and wobbly windows but no improvement.
I also have this problem with my eeepc 700 with an integrated intel 915 and kde 4.0.98 on debian. All other operations are very fast, but resizing any application is very slow. I tried both stable, git and batchbuffer branch of the intel driver and they are all slow. I do not have this problem with my other laptop that have a radeon 9000.
I can confirm. I use debian sid/experimental, kde 4.1
I confirm the exact same issue with the fglrx driver. The bug is still present inside KDE 4.1 and has always been since when I was using KDE 4.0. I am currently using the latest possible fglrx drivers (8.512) against 2.6.25.11 on an openSUSE 11.0 machine using the KDE 4.1 packages from Factory. The same behaviour was experienced when using the previous fglrx drivers on openSUSE 11.0 as well as openSUSE 10.3 I would also like to note that if I switch between two applications via ALT+TAB using the cover switch, the animation is very smooth. However if instead, I minimize an application, and click on the taskbar to show it back again, then the maximize operation has a delay and the machine is unresponsive. When using the FPS plugin to measure the performance of the machine, the above operation as well as resizing, kill the FPS to 0 for about a second while the operation is in progress. Since the resize operation is in realtime, various resizes could be queued up so that it takes more than a couple of seconds.
This is most probably just a problem with X/drivers and there's not much that KWin can do.
I'd like to add the following: I'm still using KDE3.5.10 on an openSuse 11.0, IBM Thinkpad T43 Laptop with ATI GPU and fglrx driver. kwin from KDE3 works smoothly when resizing windows. For testing I started kwin from KDE4 (kwin --replace) instead of kwin from KDE3 - anything else is still running KDE3 apps. Now, 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. Turning off desktop effects completely does not help either. 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(KDE3) or gvim but does not with konqueror or kolourpaint(KDE3) Move, minimize, maximize, restore is fast as usual.
I don't know, but here I don't have any effects, and yet feel that the resize (while the edge is being dragged by me while holding the mouse button), is slow and unusable. It happens with all apps I tried to resize, and the edge moves in increments, but I cannot move them smoothly.
The same still happens with 4.2 trunk (using the fglrx driver). Compositing in general is really really usable now, but resizing windows is more than slow. The same happens when maximimzin windows from the taksbar. About half a second nothing happens, and then the window gets drawn. I guess this is the same problem. Luckily without compositing there are no performance problems.
Can someone that is experiencing this please try it in Compiz, making sure they are using an immediate resize mode and not an outline or similar.
I would, but the freaking compiz doesn't start. Didn't have the time yet to find out what's exactly wrong. A lot of people seems to have the same problem, but no proposed solution worked so far... /usr/bin/compiz.real (core) - Fatal: No GLXFBConfig for default depth, this isn't going to work. /usr/bin/compiz.real (core) - Error: Failed to manage screen: 0 /usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0 Could anyone else please test this? One interesting thing: A friend of mine doesn't have these problems with the fglrx driver. For him everything works just fine. Don't no which graphics card he has exactly though.
Because of a broken plasma I'm using Xfce right now and it has the same window resizing problem.
Driver bug then.
This problem still persists with FGLRX and possibly other drivers. Any known work arounds?
(In reply to comment #15) > Any known work arounds? yes disable the option "show window content while resizing"
@Lucas comment #14: driver bug when the same operation works smoothly with kwin/KDE3 and only kwin/KDE4 has a problem ?
(In reply to comment #17) > @Lucas comment #14: driver bug when the same operation works smoothly with > kwin/KDE3 and only kwin/KDE4 has a problem ? yes, because in KDE 3 there was no OpenGL compositing. If the driver is slow doing texture from pixmap it's not KWin's fault. You still have the option to either disable compositing or disable the option I mentioned in comment #16 which both result in no ore less texture from pixmaps during resizing.
On Friday 31 July 2009, Martin Gräßlin wrote: > --- Comment #18 from Martin Gräßlin <ubuntu martin-graesslin com> 2009-07-31 12:53:00 --- > (In reply to comment #17) > > @Lucas comment #14: driver bug when the same operation works smoothly with > > kwin/KDE3 and only kwin/KDE4 has a problem ? > yes, because in KDE 3 there was no OpenGL compositing. If the driver is slow > doing texture from pixmap it's not KWin's fault. You still have the option to > either disable compositing or disable the option I mentioned in comment #16 > which both result in no ore less texture from pixmaps during resizing. You are missing the point that I do not use compositing! And I still see the problem of slow resizing. See my comment #8 (Note that I'm now running all apps from KDE4.3 RC3 and still see the problem)
(In reply to comment #19) You are experiencing a different bug then as the title of this one clearly states that desktop effects are enabled.
OK, created a new one: bug 202079