Bug 213103 - Window switching is slow
Summary: Window switching is slow
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.3.1
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-04 17:10 UTC by Christoph Bartoschek
Modified: 2011-12-22 10:22 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0


Attachments
Original behaviour (937.75 KB, video/x-msvideo)
2009-11-05 11:37 UTC, Christoph Bartoschek
Details
kde4 with kde2-decorations (947.01 KB, video/x-msvideo)
2009-11-05 11:42 UTC, Christoph Bartoschek
Details
Some kde4 apps in xfce (888.18 KB, video/x-msvideo)
2009-11-05 11:44 UTC, Christoph Bartoschek
Details
Some kde4 apps in xfce (888.18 KB, video/x-msvideo)
2009-11-05 11:45 UTC, Christoph Bartoschek
Details
Desktop effects settings (47.69 KB, image/png)
2009-11-05 16:10 UTC, Christoph Bartoschek
Details
Screenshot showing the desktop on a different client (256.00 KB, image/png)
2009-11-05 16:14 UTC, Christoph Bartoschek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Bartoschek 2009-11-04 17:10:39 UTC
Version:            (using KDE 4.3.1)
Installed from:    openSUSE RPMs

I have a server running opensuse 11.2 that exports its login to IGEL thin clients via XDMCP. The clients can connect to the server and start a session.

The problem is that the whole desktop is sluggish and barely usable. When I switch windows it takes nearly a second till everything is drawn properly. Opening plasma dialogs also is very slow.

I've replaced kwin in the kde4 session by metacity and the kde 4 applications started to behave nicely. Window switching was fast and responsive. Only actions that involved plasma were still slow.

Then I've stopped plasma in a kde4/kwin session:  kquitapp plasma-desktop
Window switching was still slow. Therefore I think the problem is only partly related to plasma.

The thin clients have a Trident Blade3d chipset.

The kde apps I tested are konsole, dolphin, konqueror and systemsettings.
Comment 1 Thomas Lübking 2009-11-04 17:30:29 UTC
the default window switching list and the box switch effect involve some plasma painting routines, try to disable the window list display (or use cover switch, present windows or flip switch - w/o displaying window titles!) to switch windows

(basically ensure the plasma theme doesn't show up anywhere)
Comment 2 Christoph Bartoschek 2009-11-04 17:48:14 UTC
I am switching the windows by clicking on them. For example I have two konsole windows partly overlapping. I click on the one in the background and after it is fully in front (which takes about a second) I click on the other one which is then in background.

As I said the slowdown is also there if I disable plasma completely by kquitapp plasma-desktop. The effect is that the background gets black and only the application windows remain.
Comment 3 Thomas Lübking 2009-11-04 19:27:53 UTC
Sorry, for your reference to plasma i assumed you'd refer to switching windows by alt+tab.

So:
- does toggling desktop FX change anything?
- do you have the "slide back" effect activated?
- does changin the decoration plugin (oxygen/ozone -> e.g. kde2) improve things
- iirc there has been a superflous repaint on window activation that triggered lag depending on the window border size, so please check if the situation improves if you disable window borders (rmb menu [alt+f3] -> Advanced -> Disable window borders)
- (esp. in case you use) what's your gpu/driver
Comment 4 Thomas Lübking 2009-11-04 19:31:17 UTC
(In reply to comment #0)
> I have a server running opensuse 11.2 that exports its login to IGEL thin
> clients via XDMCP. The clients can connect to the server and start a session.

(Ouch! Reading can help)
It's -probably- the decoration (uncached QGradient -> XPutImage()) so look for one that does not suffer from this overhead.
Comment 5 Christoph Bartoschek 2009-11-05 11:33:39 UTC
- As far as I know there are no desktop effects enabled. Where should I look to verify?

- Changing to the kde2 decoration is a little bit faster but not enough.

- Removing the borders also helps a little but the apps are still repainting slowly.
Comment 6 Christoph Bartoschek 2009-11-05 11:37:06 UTC
Created attachment 38107 [details]
Original behaviour

The video shows the original behaviour as I observe it. You see that the application paints slowly and then the decorations are painted.
Comment 7 Christoph Bartoschek 2009-11-05 11:42:12 UTC
Created attachment 38108 [details]
kde4 with kde2-decorations

Here is the result using the kde2 decorations.
Comment 8 Christoph Bartoschek 2009-11-05 11:44:45 UTC
Created attachment 38109 [details]
Some kde4 apps in xfce

Here you see how some kde4 apps behave in xfce. They feel much better. There is also firefox running. Slow as always.
Comment 9 Christoph Bartoschek 2009-11-05 11:45:51 UTC
Created attachment 38110 [details]
Some kde4 apps in xfce

Here you see how some kde4 apps behave in xfce. They feel much better. There is also firefox running. Slow as always.
Comment 10 Thomas Lübking 2009-11-05 14:26:07 UTC
Looks like a backbuffer issue.

I don't know much about xfce internals (there is compositing support) but /theoretically/ speed (in this regard) should improve if you activate the desktop effects (w/o having to load any plugins. try to use the Xrender backend)

The reason is that the window pixmaps are then "cached" on your X11 server (i.e. your thin client) and the X11 client (your server) doesn't have to be called to repaint them (sending the resulting pixmaps across the network again) when they get unobscured and although the window content itself didn't change.
Comment 11 Christoph Bartoschek 2009-11-05 16:10:23 UTC
Created attachment 38114 [details]
Desktop effects settings

I cannot enable the desktop effects because they are not available. See screenshot.

Here are the extensions of the X-Server (Thin Client):

    BIG-REQUESTS
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
Comment 12 Christoph Bartoschek 2009-11-05 16:14:32 UTC
Created attachment 38115 [details]
Screenshot showing the desktop on a different client

I've tested the setup on a different machine and the result is much worse. The client is from the same series but the display is different.

The screenshot shows completely broken decorations.
Plasma is strippled
The taskbar is unrecognizable.
Comment 13 Christoph Bartoschek 2009-11-05 16:15:27 UTC
I forgot to mention that XFCE has no problems on the second machine.
Comment 14 Thomas Lübking 2009-11-05 17:20:28 UTC
a) Sorry I missed an obvious question:
Does the slow repaint also hit you if you just drag a window across another or /only/ on activation change?

b) (In case of a)
I do not know why (even undecorated) KWin could break the backing store while XFce doesn't but apparently you've DAMAGE, you can enable COMPOSITE by adding

Section "Extensions"
    Option         "Composite" "Enable"
EndSection

to /etc/X11/xorg.conf (but this requires a 24/32 bit display)

Regarding the 2nd screenshot, is that an 8 or 16 bit display? (i.e. 256 or 65536 colors - notice that the folder icon is broken as well)

<voodoo class="can cause trouble or just do nothing">
   force-disable SHM (i'd only know for nvidia how to do that) and 
   force-enable the backing store by adding
      Option        "BackingStore" "True"
   to the device or screen section
</voodoo>
Comment 15 Christoph Bartoschek 2009-11-05 18:00:06 UTC
I do not have direct access to the configuration of the Thin Clients. The configuration GUI does not offer such advanced options.

The display is a 16 bit display in the second case.

I would say that also dragging is slow.
Comment 16 g111 2011-04-09 14:19:16 UTC
As KDE4.6 became much snappier, it might be interesting if the issue still exists?
Comment 17 Thomas Lübking 2011-04-09 20:28:01 UTC
I guess this was caused by the broken(?) XSYNC protocol implementation and would then have gone with 4.6 - if he still uses KDE after that long time ;-)
Comment 18 Christoph Bartoschek 2011-04-09 20:38:46 UTC
I still use KDE on my notebook. However we abandoned KDE at work and use XFCE now.

However, I will test how 4.6 behaves on monday.
Comment 19 Christoph Bartoschek 2011-04-14 20:41:37 UTC
My impression is that 4.6 got even slower. I am going to make some videos to show the current state of the misery.
Comment 20 km 2011-08-27 11:43:31 UTC
I experience similar behaviour (on local session) and also slow and jerky resizing. Even on KDE 4.7.1. I also have an impression that KDE gets slower and slower with every major version... 
Graphic card - ati radeon 9200 pro, desktop effect turned off, win decoration - Oxygen, qt graphic system - raster.
Comment 21 Thomas Lübking 2011-08-27 12:24:12 UTC
(In reply to comment #20)
> I experience similar behaviour
No, you rather don't.
- local session ./. xdmcp
- activation ./. resizing

However the paintredirector is /still/ there.

Please don't hijack bugs. As for now:
-> Tried another decoration (NOT aurorae - or try hiding the decoration & "alt + rmb" to resize)?
-> Is resizing xterm slow as well?
-> Is it compositing related?
Comment 22 Martin Flöser 2011-12-22 10:22:53 UTC
As of 4.8 the PaintRedirector has been dropped for non-composited setups which should give the same decoration rendering performance as before 4.3.

For thinclient setups I recommend to not use Oxygen or Aurorae themes as window decorations and probably also not Oxygen as widget style.

In case there are still performance problems with 4.8, feel free to reopen and update the observations.