Version: (using KDE 4.3.0) Installed from: Debian testing/unstable Packages I usually work with five desktops. The task manager is configured to show only the windows in the current desktop. If I change the desktop, then the task manager takes an appreciable time to update the list of windows in the current desktop. It can take up to four seconds to show the new situation. It happens with and without desktop effects. Changing the window with focus within the same desktop , or open a new bunch of windows is reflected instantaniously. The problem only appears as changing the desktop.
I second this. But I am not sure with the 4-5 seconds, it may be 2 seconds only. But if having 40 or more windows open on one desktop it takes some time for the task manager to finish drawing. IMHO the problem is that there is only one task manager that has to be redrawn on each desktop switch. It would be better to have one task manager for each desktop that keeps its state. In KDE4.4 there comes another problem: On changes of the windows (opening or closing a window) the entries in the task manager slide to their new position. This usually looks nice and also may be good for better orientation. But in case of an desktop switch this effect should be turned off. Otherwise the task manager does look very hectically/fluttering(?) on desktop switches.
Do you reproduce with kde 4.4.4 or 4.5 beta ?
Currently I cannot see a longer taking redrawing in KDE4.4.4 (debian/sid). The drawing of the panel is very fast, tested with XRender and without composite. But there is one flickering left. When switching the desktop all buttons seem to be condensed in the upper left corner of the task manager in only one button. This button is of half the size of the task manager. From there the buttons are placed to the right position (but without a moving animation). I did try to take a screencast. You cannot see the animation on it, but the single pictures show what I mean, I think.
Created attachment 47793 [details] part of the panel when switching the desktop
I can confirm that this does not happen anymore with kde 4.4.3 About the problem specifies in #3. I think that it may well be an animation that is too fast. In any case, it is a different problem. So I close this bug.