qt4 applications over X forward run slower than with Ubuntu 10.04 LTS

[Stefan Pielmeier]

use case:
- shared desktop where users log on via ssh with X forwarding and local area network with 1GBit/s
- machine is a Ubuntu server installation, originally 64bit Ubuntu 10.04, upgraded to 12.04
- the multiarch libraries for 32 bit are installed (see package list attached)

expected behaviour:
- the remote started qt apps that use X forwarding shall run at least the same speed with Ubuntu 12.04 and 10.04.

observed behavior:
- after upgrade from 10.04 64bit to 12.04 64bit, all remotely X forwarded qt applications (like kdbg) are significantly slower than on 10.04 (factor 3-9);
- another (multiarch) 64 bit Ubuntu machine that was a new 12.04 install show similar bad performance with qt applications over X forward.
- therefore it can be expected that the upgrade itselv isn't the problem, but more something in Ubuntu 12.04 that is slowing down qt apps that are run over X forward.

hardware: i7, 8GB RAM, SSD harddisks

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libqtcore4 4:4.8.1-0ubuntu4.3
ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
Uname: Linux 3.2.0-32-generic x86_64
ApportVersion: 2.0.1-0ubuntu14
Architecture: amd64
Date: Mon Nov 12 15:23:33 2012
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 LANGUAGE=en_US:en
SourcePackage: qt4-x11
UpgradeStatus: No upgrade log present (probably fresh install)

[Harald Sitter (apachelogger)]

Using oxygen as widget style?

[Stefan Pielmeier (stefan-symlinux)]

Hi Harald,

how can I find out about which qt widget style is used in oxygen?

Best regards,
Stefan.

[Stefan Pielmeier (stefan-symlinux)]

ah sorry: i mean: which widget style is used in kdbg? is there a qt debug switch to see the style currently in use?

[Stefan Pielmeier (stefan-symlinux)]

I have just installed an 12.10 64bit installation.

Same picture, running kdbg via ssh x forward is significantly slower than with a 10.04 32 or 64 bit installation. I tested agains a (new) 32 bit installation of 10.04 on a Pentium 4 old PC, which still performs significantly better than 12.04 and 12.10

I came across 2 things here:

1- it might be pure network performance plus the fact that simple X applications like ddd probably (i don't know) use less network ressources than QT applications do (more effects)?.

2- Is there any debugging you can propose, or maybe X benchmark / QT benchmark, that could help to find out where the time gets lost

3- visually, the slow performance shows in some kind of 'rolling down' effect of the application when starting it up (kdbg is our choice for this test). when using 10.04 the window just pops up. With 12.04 and 12.10 you first see the top line, then the rest of the window is rolling down, just slow enough that our eye can see it rolling. Still, using the sliders and menues gives that feeling of a slow machine.

4- we didn't change Network or hardware between 10.04 and 12.04 upgrade on the 64 bit machine in question. We even tried with a directly connected remote X client via ssh, physically only one net cable between them, no other network connections established. There must be a problem somewhere ...

5- other people have seen similar, but maybe never experienced enough trouble: https://answers.launchpad.net/ubuntu/+source/xorg/+question/213691

[Stefan Pielmeier (stefan-symlinux)]

... to report a bug

[Harald Sitter (apachelogger)]

Install qt4-qtconfig, run qtconfig:
In the very first dropdown for 'GUI Style' select oxygen if that option is available. If the preview looks stylewise like the qtconfig window itself you are using oxygen. To make perfectly sure you can select oxygen, close the qtconfig window and start it again if it looks like before you've been using oxygen.

[Stefan Pielmeier (stefan-symlinux)]

We have performed the actions you proposed:
1) running qtconfig shows that we do not have oxygen as an option
2) choosing GTK+ as an option did not show any performance improvement

[Michel Albert (esz-michel)]

We updated to 12.04 yesterday and experience the exact same degradation.

Is there any additional information available yet? Changing the QT4 style did not change anything.

[Michel Albert (esz-michel)]

Additionally, we experience another problem running KDE applications.

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. (see https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/959151)

Is it possible that this bug is related?

[Michel Albert (esz-michel)]

I found the following issue reported in the kdevelop tracker (see https://bugs.kde.org/show_bug.cgi?id=293587)

Adding the argument "--graphicssystem native" resolves the issue for me and the person who submitted the issue to kdevelop. You may get lucky as well!

[Frank Lazzarini (flazzarini)]

I can confirm this it really speeds up things again!

Further more there is an environment variable that you can set to override the graphicssytem's default setting (see https://bugs.kde.org/show_bug.cgi?id=248672#c2), although it states that you should use it at own risk, so it might break stuff.

export QT_GRAPHICSSYSTEM="native"

[Michel Albert (esz-michel)]

Some additional info:

I found the following package: "kde-config-qt-graphicssystem"
and tried to configure the setting using it by running "kcmshell4 qt-graphicssystem"

It only provides three options. None of which are "native". It did *not* work! On the other hand, setting the env. variable as suggested by Frank did the job.

[Stefan Pielmeier (stefan-symlinux)]

Adding export QT_GRAPHICSSYSTEM="native" has solved the problem for me on my Ubuntu 12.04 machine.

The Ubuntu team might consider allowing this option to be chosen for all shells that are remotely called via ssh.

[Stefan Pielmeier (stefan-symlinux)]

I allowed myself to set the bug in state "NEW" again, as we now have much more evidence here so somebody from the "experts" might have interest reviewing the bug again ;-).

I hope this is ok ...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.