ume-launcher and glx - unusable when fast user-switching

[Rod Hull]

If you use "Switch User" to open up a new session on a different VT, glx is only active on the first-started VT, meaning that the second user doesn't have access to direct rendering. This is fine usually, and only affects 3D-heavy applications and Visual Effects etc.

However, ume-launcher looks like it has features that even with Visual Effects disabled depend heavily on hardware rendering. I assume it's the icon title highlight and grow/shrink on mouseover and the launch feedback (icon spin and overlay "loading" message).

This means that when the second user is switched in, trying to do anything in ume-launcher is EXTREMELY slow to the point in that its unusable effectively - Xorg spikes to 100% CPU whilst it tries to do the rendering without using glx direct rendering.

Is it possible to selectively disable the glx graphical elements of ume-launcher, in other words to still use the layout of the launcher but just disable the launch feedback and mouseover graphical eye-candy, so that when direct rendering isn't available the performance of the launcher app (and the rest of the UI) is still high?

At the moment, due to the CPU load without direct rendering it's impossible to use Netbook Remix's arguably most core component for more than one user simultaneously.

[Neil J. Patel (njpatel)]

The launcher is written using Clutter, which is a GL canvas. I'm not sure what difference reducing the animations would make, the performance would still be horribly slow (like processing clicks etc) as the entire launcher is using software rendering.

Also, I'm not sure how to detect that we're on software rendering. If this is possible, I don't mind making some builds to see if disabling the animations helps.

[Rod Hull (iwantmyjelly)]

To find out the status of software versus hardware rendering, I usually do a:

glxinfo |grep direct

If "direct rendering: No" then you're using software rendering...however I hadn't realised the entire app uses a GL canvas, so as you say, it'll probably still be slow even with the animations disabled.

The best outcome would be if direct rendering could be used in more than one VT at a time on Intel 945GSE - then this point would be totally moot...

[Neil J. Patel (njpatel)]

Right, the Intel drivers do not currently support accelerated GL on more than one VT. The drivers automatically fallback to software gl rendering, but this is not very good on Linux. For this reason, we have had to inhibit the fast-user-switching functionality on the UNR images when in "netbook-mode".

[Bill Filler (bfiller)]

This can't be completely be fixed as Intel drivers do not currently support accelerated GL on more than one VT. Until that happens, we don't have a solution to fix this issue. However, bug 320796 will be looked to address the software only rendering issue.