QT4 apps slooooow in ssh

[Roberto Ragusa]

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????

-- 
   Roberto Ragusa    mail at robertoragusa.it

[T.C. Hollingsworth]

On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa <mail(a)robertoragusa.it&gt; 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.

[Roberto Ragusa]

On 05/08/2012 09:40 PM, T.C. Hollingsworth wrote:
>  On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa
> <mail(a)robertoragusa.it&gt; 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?

-- 
   Roberto Ragusa    mail at robertoragusa.it

[T.C. Hollingsworth]

On Tue, May 8, 2012 at 1:10 PM, Roberto Ragusa <mail(a)robertoragusa.it&gt; wrote:
>  On 05/08/2012 09:40 PM, T.C. Hollingsworth wrote:
> > On Tue, May 8, 2012 at 8:47 AM, Roberto Ragusa <mail(a)robertoragusa.it&gt; 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-raste...

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.

[Cameron Simpson]

On 08May2012 13:18, T.C. Hollingsworth <tchollingsworth(a)gmail.com&gt; 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-raste...
| 
| 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,
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

"waste cycles drawing trendy 3D junk"   - Mac Eudora v3 config option

[Roberto Ragusa]

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-raste...
>  
>  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?

-- 
   Roberto Ragusa    mail at robertoragusa.it

[T.C. Hollingsworth]

On Wed, May 9, 2012 at 12:53 AM, Roberto Ragusa <mail(a)robertoragusa.it&gt; 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-raste...
> >
> > 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.

[Cameron Simpson]

On 09May2012 01:45, T.C. Hollingsworth <tchollingsworth(a)gmail.com&gt; wrote:
| On Wed, May 9, 2012 at 12:53 AM, Roberto Ragusa <mail(a)robertoragusa.it&gt; 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,
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

Uh, this is only temporary...unless it works.   - Red Green