Hi,
some exported (ssh -Y) applications are unbelievably slow, as they seem to "upload bitmaps" (display is progressively drawn from top to bottom and network traffic is 11.2MB/s, saturated 100Mbit/s).
This happens only with qt4 apps (e.g. kate), no problem with qt3 apps or gtk apps.
The qt4 apps run on a F16 KDE desktop with effects enabled, and are displayed on an F13 KDE desktop with effects disabled.
The F16 machine was originally an F14 and in this case (F14 displaying on F13) the problem was not present.
Maybe qt4 has a different rendering method which involves a lot of bitmap shuffling (disaster when remote)?
An additional test, on the F16 machine: - "kate" is normally fast - "ssh -Y localhost kate" is slooooooooooooooooooow
What is happening here????
On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa mail@robertoragusa.it wrote:
Hi,
some exported (ssh -Y) applications are unbelievably slow, as they seem to "upload bitmaps" (display is progressively drawn from top to bottom and network traffic is 11.2MB/s, saturated 100Mbit/s).
This happens only with qt4 apps (e.g. kate), no problem with qt3 apps or gtk apps.
The qt4 apps run on a F16 KDE desktop with effects enabled, and are displayed on an F13 KDE desktop with effects disabled.
The F16 machine was originally an F14 and in this case (F14 displaying on F13) the problem was not present.
Maybe qt4 has a different rendering method which involves a lot of bitmap shuffling (disaster when remote)?
An additional test, on the F16 machine:
- "kate" is normally fast
- "ssh -Y localhost kate" is slooooooooooooooooooow
What is happening here????
Is `ssh -Y localhost kate -graphicssystem native` faster?
-T.C.
On 05/08/2012 09:40 PM, T.C. Hollingsworth wrote:
On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa mail@robertoragusa.it wrote:
An additional test, on the F16 machine:
- "kate" is normally fast
- "ssh -Y localhost kate" is slooooooooooooooooooow
What is happening here????
Is `ssh -Y localhost kate -graphicssystem native` faster?
Absolutely yes! The speed is normal again.
I also tried "-graphicssystem raster" which is sloooow, and "-graphicssystem opengl" which is bugged (pieces of the GUI are missing).
Why is the default so bad for ssh?
On Tue, May 8, 2012 at 1:10 PM, Roberto Ragusa mail@robertoragusa.it wrote:
On 05/08/2012 09:40 PM, T.C. Hollingsworth wrote:
On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa mail@robertoragusa.it wrote:
An additional test, on the F16 machine:
- "kate" is normally fast
- "ssh -Y localhost kate" is slooooooooooooooooooow
What is happening here????
Is `ssh -Y localhost kate -graphicssystem native` faster?
Absolutely yes! The speed is normal again.
I also tried "-graphicssystem raster" which is sloooow, and "-graphicssystem opengl" which is bugged (pieces of the GUI are missing).
Why is the default so bad for ssh?
The default is the "raster" graphics engine, which works somewhat like you described in your original e-mail: http://labs.qt.nokia.com/2009/12/18/qt-graphics-and-performance-the-raster-e...
The "native" graphics engine uses regular X11, which will probably always be best over SSH.
Qt also respects the QT_GRAPHICSSYSTEM environment variable to configure this, so you can add `export QT_GRAPHICSSYSTEM=native` to your ~/.profile or wherever to make it your "default".
-T.C.
On 08May2012 13:18, T.C. Hollingsworth tchollingsworth@gmail.com wrote: | >> Is `ssh -Y localhost kate -graphicssystem native` faster? | > | > Absolutely yes! The speed is normal again. | > I also tried "-graphicssystem raster" which is sloooow, | > and "-graphicssystem opengl" which is bugged (pieces of the GUI are | > missing). | > | > Why is the default so bad for ssh? | | The default is the "raster" graphics engine, which works somewhat like | you described in your original e-mail: | http://labs.qt.nokia.com/2009/12/18/qt-graphics-and-performance-the-raster-e... | | The "native" graphics engine uses regular X11, which will probably | always be best over SSH.
For X11 tunneling, yes it should be. X11 has significant support for putting bulky stuff on the server (your local X11 display) and sending tokens over the net to manipulate them.
Unless of course you want to use seamonkey as a mail reader over a remote connection. It used to work quite well, but in recent years has sprouted so much animations (not least that bloody "throbber" activity indicator) that my partner reserves it for desperation when away from the home server; it is close to unusable. (I use mutt:-)
Cheers,
On 05/08/2012 10:18 PM, T.C. Hollingsworth wrote:
The default is the "raster" graphics engine, which works somewhat like you described in your original e-mail: http://labs.qt.nokia.com/2009/12/18/qt-graphics-and-performance-the-raster-e...
The "native" graphics engine uses regular X11, which will probably always be best over SSH.
Qt also respects the QT_GRAPHICSSYSTEM environment variable to configure this, so you can add `export QT_GRAPHICSSYSTEM=native` to your ~/.profile or wherever to make it your "default".
Ok, so I have a work-around, but the default behavior is unacceptable, there should be some kind of fallback to native when on a remote display, maybe by automatically measuring the speed of bitmap transfers.
This _should_ be fixed upstream. Is there an open bug on this already?
On Wed, May 9, 2012 at 12:53 AM, Roberto Ragusa mail@robertoragusa.it wrote:
On 05/08/2012 10:18 PM, T.C. Hollingsworth wrote:
The default is the "raster" graphics engine, which works somewhat like you described in your original e-mail: http://labs.qt.nokia.com/2009/12/18/qt-graphics-and-performance-the-raster-e...
The "native" graphics engine uses regular X11, which will probably always be best over SSH.
Qt also respects the QT_GRAPHICSSYSTEM environment variable to configure this, so you can add `export QT_GRAPHICSSYSTEM=native` to your ~/.profile or wherever to make it your "default".
Ok, so I have a work-around, but the default behavior is unacceptable, there should be some kind of fallback to native when on a remote display, maybe by automatically measuring the speed of bitmap transfers.
This _should_ be fixed upstream. Is there an open bug on this already?
I doubt Qt can safely switch graphics systems midway through application execution. The only way it could do anything about it is if it could detect whether it's being run remotely at startup, which I don't think is possible either.
Fedora's Qt/KDE guys might be convinced to stick `[[ -n "${SSH_CONNECTION}" ]] && export QT_GRAPHICSSYSTEM=native` in /etc/profile.d, though. (Unless there's a nicer way to change the environment of only SSH logins.)
-T.C.
On 09May2012 01:45, T.C. Hollingsworth tchollingsworth@gmail.com wrote: | On Wed, May 9, 2012 at 12:53 AM, Roberto Ragusa mail@robertoragusa.it wrote: | > On 05/08/2012 10:18 PM, T.C. Hollingsworth wrote: | >> The "native" graphics engine uses regular X11, which will probably | >> always be best over SSH. | >> Qt also respects the QT_GRAPHICSSYSTEM environment variable to | >> configure this, so you can add `export QT_GRAPHICSSYSTEM=native` to | >> your ~/.profile or wherever to make it your "default". | > | > Ok, so I have a work-around, but the default behavior is unacceptable, | > there should be some kind of fallback to native when on a remote display, | > maybe by automatically measuring the speed of bitmap transfers. | | I doubt Qt can safely switch graphics systems midway through | application execution. The only way it could do anything about it is | if it could detect whether it's being run remotely at startup, which I | don't think is possible either.
It could inspect $DISPLAY. If it begins with ":" then it is local and otherwise, probably remote. One could tune default choice on that basis.
| Fedora's Qt/KDE guys might be convinced to stick `[[ -n | "${SSH_CONNECTION}" ]] && export QT_GRAPHICSSYSTEM=native` in | /etc/profile.d, though. (Unless there's a nicer way to change the | environment of only SSH logins.)
It isn't ssh you want to care about, it is remoteness. And of course QT_GRAPHICSSYSTEM should never be mangled if it is already initialised; that way lies "magic" behaviour. (Of course, this is RedHat we're talking about, who still believe that having $PS1 set is a meaningful indicator of stuff; had to mangle my nice clean login procedures, many years old, when I finally bothered tracking down that misdecision.)
Cheers,