Re: Slow image display over network

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> Lars Magne Ingebrigtsen writes:
>  > One thing I've wondered about for a while, but has become more
>  > relevant lately (what with the web feeds in Gnus and stuff) is why
>  > image display is so slow over remote connections.
>  > 
>  > Here's how to reproduce:
>  > 
>  > 1) ssh somewhere that's far away, so that there's plenty of latency
>  > 2) open an Emacs over X 3) (put-image "/tmp/pretty-big-picture.jpg"
>  > (point))
>  > 
>  > Depending on how big the picture is, and what the latency is, this
>  > might take very long time.
>  > 
>  > 4) switch to a different buffer
>  > 
>  > This will be instantaneous.
>  > 
>  > 5) switch back to the buffer where the picture is
>  > 
>  > This will not be instantaneous, but it will be very fast.
>
> You do understand that 4 and 5 are probably not interesting, because
> the *X server* creates a pixmap, and that will be available to Emacs
> for reuse via an int-sized resource ID?
>
> That said, it has been alleged in the past that XEmacs instantiates
> images more quickly than Emacs does.  You might try benchmarking Emacs
> against XEmacs; if Emacs performs comparably to XEmacs, while there
> still may very well be a bug, it's probably pretty hard to fix since
> two rather different implementations are showing the same performance
> issue.

I don't think that this is relevant for remote operation.  Emacs goes
through a complex call chain for every single pixel of an X image in
order to create it.  Quite nonsensical.  Once it is through, it goes to
the X server as one image if I am not mistaken, and gets moved into a
pixmap (the Emacs image cache).  So the worst that can happen is that it
is in a format not best for remote transfer.

I don't remember all too closely whether it is Xlib on the client side
or the X server which does the conversion to an onscreen Pixmap from an
XImage.  In any case, that cost should be negligible in remote
operations.

-- 
David Kastrup