Re: emacs 23 display slow over cable modem

[Tim X]

despen@verizon.net writes:

> Tim X <timx@nospam.dev.null> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> 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