From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: Why is Emacs so slow when used remotely? Date: Thu, 28 Nov 2013 12:48:56 -0700 Message-ID: <20131128194856.GA5315@hysteria.proulx.com> References: <76f5ba95-cc68-4326-a962-f515c0fb70cd@y31g2000vbt.googlegroups.com> <6f87ce15-a952-4009-af80-bb8804cfce58@googlegroups.com> <20131115222457.GA1094@hysteria.proulx.com> <528E6967.80003@gmail.com> <75FAC675-A3ED-48DF-96BB-991DC459F059@Web.DE> <20131128023423.GA26318@hysteria.proulx.com> <050514FA-31EE-41CE-958B-473163847402@Web.DE> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385668162 5011 80.91.229.3 (28 Nov 2013 19:49:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Nov 2013 19:49:22 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 28 20:49:25 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vm7aU-0002jG-7S for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Nov 2013 20:49:22 +0100 Original-Received: from localhost ([::1]:43842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm7aT-000224-Ry for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Nov 2013 14:49:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm7aB-00021x-ND for help-gnu-emacs@gnu.org; Thu, 28 Nov 2013 14:49:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vm7a5-0007o7-NZ for help-gnu-emacs@gnu.org; Thu, 28 Nov 2013 14:49:03 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:59367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm7a5-0007o0-Bo for help-gnu-emacs@gnu.org; Thu, 28 Nov 2013 14:48:57 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 5BB742122A for ; Thu, 28 Nov 2013 12:48:56 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 3AC042DCD5; Thu, 28 Nov 2013 12:48:56 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <050514FA-31EE-41CE-958B-473163847402@Web.DE> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:94707 Archived-At: 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? >=20 > I had this bad experience with a commercial product=E2=80=A6 And I also= have > similar experience with system virtualisation products. As long as I > use US-ASCII they work=E2=80=A6 somehow. >=20 > 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.