emacs 23 display slow over cable modem
Strozzi, David J.
I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
work. I connect over VPN from home, where I have a cable modem. For a long
time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
terminal) has performed fine - after it starts (which may take some time),
typing, switching buffers, etc is pretty instant. But, doing the same thing
in 23.2 gives much slower response. Both work fine in -nw mode, but there
are some reasons (keyboard mappings, multi-windows, mouse) why I like the
full xwin app. From my office, both xwin's run very fast.
Any ideas on why? I just do text, no image stuff in emacs. I'd really like
to use emacs 23, remotely, the full xwin app, and have the speed be like
emacs 21.
Thanks,
David Strozzi
Daniel Pittman
> I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
> work. I connect over VPN from home, where I have a cable modem. For a long
> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
> terminal) has performed fine - after it starts (which may take some time),
> typing, switching buffers, etc is pretty instant. But, doing the same thing
> in 23.2 gives much slower response. Both work fine in -nw mode, but there
> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
> full xwin app. From my office, both xwin's run very fast.
>
> Any ideas on why?
At a guess, because Emacs 23 uses Xft for font rendering, which provides nice
anti-aliased display, while Emacs 21 uses only X core fonts.
Theoretically the X server caching and client libraries make Xft reasonably
efficient over long, thin pipes, but practically it is optimized on the
assumption that people basically don't do this any more.
If you can live without the better fonts you can still turn on the core font
backend after install[1] and just use that.
Regards,
Daniel
Footnotes:
[1] Read the manual, I don't actually know how, I fear. :)
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Eli Zaretskii
> Date: Sun, 24 Oct 2010 23:27:25 +1100
>
> If you can live without the better fonts you can still turn on the core font
> backend after install[1] and just use that.
>
> [1] Read the manual, I don't actually know how, I fear. :)
From the NEWS:
*** Which font backends to use can be specified by the X resource
"FontBackend". For instance, to use both X core fonts and Xft fonts:
Emacs.FontBackend: x,xft
If this resource is not set, Emacs tries to use all font backends
available on your graphic device.
*** New frame parameter `font-backend' specifies a list of
font-backends supported by the frame's graphic device. On X, they are
currently `x' and `xft'.
des...@verizon.net
See this thread and see if it applies to your case:
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/bd7e102326bec6b2
Stefan Monnier
>> work. I connect over VPN from home, where I have a cable modem. For a long
>> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
>> terminal) has performed fine - after it starts (which may take some time),
>> typing, switching buffers, etc is pretty instant. But, doing the same thing
>> in 23.2 gives much slower response. Both work fine in -nw mode, but there
>> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
>> full xwin app. From my office, both xwin's run very fast.
Sounds like a bug we'd like to know about. Please M-x report-emacs-bug.
Stefan
des...@verizon.net
I've already done a bug report based on the
"Why is Emacs so slow when used remotely?"
thread.
Was it received? Was it clear enough?
Unlike other projects, I don't remember getting email on bug
reports for emacs as they change status. Sort of leaves us
in the dark.
Stefan Monnier
> "Why is Emacs so slow when used remotely?"
> thread.
> Was it received? Was it clear enough?
Yes, we recevied it, as you can see at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7092.
I see, then it is probably somewhat specific to dired.
> Unlike other projects, I don't remember getting email on bug
> reports for emacs as they change status. Sort of leaves us
> in the dark.
We're not very good at using the bug-tracker, indeed (it's the right
place to submit reports, tho).
Stefan
des...@verizon.net
>> I've already done a bug report based on the
>> "Why is Emacs so slow when used remotely?"
>> thread.
>> Was it received? Was it clear enough?
>
> Yes, we recevied it, as you can see at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7092.
>
> I see, then it is probably somewhat specific to dired.
I think the OP complained about buffer list too.
I use Electric buffer list, it has tool tips and is easy
to get backed up if you mouse around it.
The mode line and window separators detect hover too and
seem to cause problems.
I just tried again, and I'm still seeing backed up tool tip windows
popping up as I type this in a local copy of Emacs.
>> Unlike other projects, I don't remember getting email on bug
>> reports for emacs as they change status. Sort of leaves us
>> in the dark.
>
> We're not very good at using the bug-tracker, indeed (it's the right
> place to submit reports, tho).
Thanks.
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.
Stefan Monnier
> 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
Tim X
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.
Tim
--
tcross (at) rapttech dot com dot au
des...@verizon.net
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.
Tim X
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.