Re: Why is Emacs so slow when used remotely?

[Bob Proulx]

Peter Dyballa wrote:
> schrieb Bob Proulx:
> > > Doesn't it have problems with characters outside the limited
> > >  US-ASCII range?
> >
> > Perhaps you are thinking of something other than VNC?
> 
> I had this bad experience with a commercial product… And I also have
> similar experience with system virtualisation products. As long as I
> use US-ASCII they work… somehow.
> 
> OK, I'll try free products!

When I wrote the above I thought about asking for clarification.
Because the entire concept caused me to take pause.  My brain made a
funny face and went huh?  Let me say some words here about VNC and it
will probably be just noise.  But I think there is probably
environment differences when used between us.

In a Unix like system we are mostly talking about X for graphics.  It
is a bit mapped display.  Objects are rendered using a software
rendering engine.  Characters are displayed using a selected font.
Depending upon the font rendering will be bit-mapped or scaled or
perhaps something different.  This is all somewhat a fuzzy
description.  Don't look too closely at the details.  Just the higher
level view of things.

VNC creates a virtual display very much the same as X.  But where X
has an actual display VNC doesn't need any physical display.  VNC is a
virtual display.  We then use a client to connect between the virtual
display and a physical display.  On my monitor I will see X as the
host display and then, say, a smaller rectangle will be the VNC
display.  (Might be full screen.  Might be larger than full screen
with scrolling needed.)  A graphics display within a graphics
display.  Layers and layers.  (Used to be we would say layers like an
onion.  But ever since the movie Shrek we now might say layers like an
ogre.)

When using VNC everything is graphical.  I have a layered graphical
desktop within a graphical desktop.  The host desktop will be running
a window manager and the "inner" VNC desktop will be running a window
manager.  (I usually make them different window managers so that they
look much different.  It helps my brain know which is which.  Because
it is easy to confuse local windows with remote windows.)

In the remote VNC desktop I can start up any manor of graphical
client.  There are lots of uses.  My main use for it is to start up a
web browser on the remote computer sitting in a private network behind
restrictive firewalls.  The browser there can then access resources
available only on the inner side of the firewall.  The graphical
display of it will be available to me outside the firewall using VNC
to transport the display from there to here[1].  When I want to see a
graphical display of exactly what I would see if I were sitting on
that remote network then I always use VNC for it.

When X is used to throw the display across the network it does so
using the X protocol.  That isn't a very efficient protocol.  It says
things like color #RGB numbers, X Y coordinates, color #RGB numbers, X
Y coordinates.  It is a quite low level and brute force protocol.
Lots of X protocol accelerators exist to try to compress the data
stream such as stacking up a run of the same color and so forth but
there is only so much that they can do.  The VNC server and client
exchange data using a different protocol.  I looked just now to
remember the name of it and see that it is RFB the remote framebuffer
protocol.  It was designed by the same folks who did VNC and I think
for VNC use.  It also has variations of stream compressors.  VNC is
definitely faster over the WAN than native X.  But while VNC is faster
it still isn't perfectly fast.  I know one comment in this thread was
that emacs in graphical mode was snappy fast that way.  I am sure it
is faster than X.  But I still don't find that to be the most
efficient way for me because it isn't fast enough. :-) It all depends
upon the latency between the client and server that you are using and
perhaps I am unfortunate to have a higher latency connection than most
at around 80ms.  If you can get down in the 10ms or less range then
you probably think it is very fast indeed.  If someone is committed to
using a graphical emacs then I would definitely try it in a VNC
session to see if that was better.

So when you say that it has problems with characters outside of the
US-ASCII range my immediate thought was everything is graphical and
what does the character range have to do with it?  It is all just
pixels at that point.  Must be talking about something else.  But
maybe not.  Probably not the character range but it might have
something to do with the font which is related.

Because with VNC I have seen some strange graphical artifacts over the
years.  Usually when working with mixes of the various servers and
clients such as RealVNC and TightVNC.  RealVNC is the original.
TightVNC is a fork of the code with additional optimizations for
performance.  I used to always use TightVNC because it was faster than
RealVNC.  But recently I have had to switch back to RealVNC because
TightVNC has been giving me strange graphical artifacts.  Things like
black boxes and pull down menus that are blank and things like text
boxes with unreadable small white boxes instead of text.  And so I
switched back to RealVNC.  Bugs for sure.  But I am just a VNC user
and I am not going to find and fix them.

I think it is possible that you are seeing some type of artifact in
the same way.  It might even be related to the fonts too.  Because it
might be related to the font rendering engine.  Don't know.  It can
give wierd results that defy easy description.  And then there are the
commercial products you mentioned (such as NoMachine NX) and other
products.  I will just say that conceptually they are similar and
either work or don't (mostly they work fine just as VNC works fine) in
similar ways.

And there is my noise to add to the conversation.  Hopefully it wasn't
too noisy.

Bob

[1] It is actually more complicated than that.  If I were only wanting
to run a web browser such as Firefox or Chromium then I usually tunnel
a proxy connection through over ssh instead.  Then set up the http
proxy configuration on the browser to use the tunnel to the private
side of the network.  The result is a much faster browsing experience
since my browser is then on the native desktop.  The local graphics is
fast and the result just acts like the slow WAN network that it is.

But instead the problem is usually needing to run a specific version
of MS-IE accessing a private resources that requires ActiveX in
exactly MS-IE 6 and does not function with any other web browser.
Sigh.  Of course MS-IE 6 runs on Windows.  Therefore after setting up
VNC on the private side of the firewall network then I would rdesktop
over to a Windows terminal server on that side of the LAN.  That
creates a third layered graphical display!  Windows, VNC, my X
display.  Each has its own window manager.  (Layers like an ogre.)  In
the MS Windows remote desktop display I would run IE and do the
required tasks.  Not a pretty situation.  Rather amazing that it all
works.