From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: emacs 23 display slow over cable modem Date: Sat, 06 Nov 2010 20:54:25 +1100 Organization: Unlimited download news at news.astraweb.com Message-ID: <87fwveu69a.fsf@puma.rapttech.com.au> References: <87oca4tzwk.fsf@puma.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291888102 18189 80.91.229.12 (9 Dec 2010 09:48:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 09:48: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 Dec 09 10:48:19 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQd6n-0004bd-Ra for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 10:48:18 +0100 Original-Received: from localhost ([127.0.0.1]:33582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQd6m-0004FE-Uw for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 04:48:17 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.astraweb.com!border2.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:eZcS3IYfcfUROjT35pip6oeIVnU= Original-Lines: 83 Original-NNTP-Posting-Host: a8db6446.news.astraweb.com Original-X-Trace: DXC=\ckV0ihV_ORD:=ciL5QPHRL?0kYOcDh@ZXb<8`kRh<; P]QE`fi=n]\^]G; 2>V^?kWSCAkl5c@Xgk^kBOAjKhYTLYSkaAeJQmmPR Original-Xref: usenet.stanford.edu gnu.emacs.help:182247 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:76932 Archived-At: despen@verizon.net writes: > Tim X writes: > >> Stefan Monnier writes: >> >>>> I know I can disable tooltip mode but I don't see how to disable all >>>> the hover stuff going on. I think it's too much for remote use. >>> >>> Indeed "all the hover stuff" is designed with the assumption of a fast >>> and low-latency access to the X server. >>> >>> I must say I do not know how to make them work acceptably on a slow >>> connection. A poor man's solution is to turn off those features, but as >>> you say it's not always easy to do it. >>> >>> Maybe we could provide a configuration variable that just forces Emacs >>> to ignore all mouse-movement events, as it used to in Emacs-20 (IIRC). >>> It would work by telling the server not to send it mouse-movement events >>> (except within the scope of a track-mouse, of course, so that >>> mouse-drags can provide feedback as is expected nowadays). >>> >>> >>> Stefan >> >> That could be a good idea. Although I rarely run emacs in native X mode >> remotely over a WAN these days, preferring tramp most of the time, it is >> a pity that this feature no longer appears to work well. >> >> For the OP, one solution is to use one of the X compression protocols. >> There are a couple of variants and most are fairly easy to setup. These >> greatly reduce the amount of X protocol traffic being sent and greatly >> improve the performance. Most Linux distros come with one or two >> variants as standard packages. > > I'm not the OP but I'm using ssh without -c. The ssh man page says: > > Compression is desirable on modem lines and other slow connections, > but will only slow down things on fast networks. > > Ssh goes over a VPN which does compression. > > I wouldn't mind having to add a dozen commands to my .emacs > but as far as I can tell, it can't be configured off. The compression I'm referring to has nothing to do with ssh or even VPN compression. The X protocol has a lot of duplicated data in its packets (it was not designed for WAN connections). A number of people realised that performance of X based applications would be greatly improved over slower connections if some of the duplicated/redundent data was removed. This resulted in a number of tools, such as dxpc and nxproxy that attempt to improve the performance of X based applications over WAN connections by removing some of the redundency/duplicated data sent as a normal part ofthe X protocol. This differential compression is occuring at the X protocol level and not at the ssh protocol level. In general, there is a trade off between speed and compression. There is a point at which the cost of compressing and decompressing data is more expensive (i,e, takes more time to perform) than just sending the data 'raw'. This can be especially true if the compression and decompression algorithms being used rely on complex analysis where the speed of the machines doing this work is a lot slower than the raw speed of the data line. However, the X compression being used by the above tools is not performming in-depth analysis and encoding/decodings - at least not in the same sense as many compression techniques that favor space over time. What they are really doing is stripping redundent data out of the protocol. There is not a large encoding/decoding overhead as you sometimes see with other forms of compression. Of course, this X protocol data is usually being forwarded over the ssh layer and so ssh compression may also have an impact. However, if your running a VPN, it may be possible to run a direct X connection and bypass ssh, though this would depend on your VPN and remote network firewalls etc. However, if you do go down this route, make sure you use the xauth and not the xhost path to get display permissions working. It is a bit more work, but a lot more secure. Tim -- tcross (at) rapttech dot com dot au