Slow image display over network

Slow image display over network

[Lars Magne Ingebrigtsen]

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.

So that's the behaviour I don't understand.  The first time you display
an image (over a high-latency X connection), it's really slow.  The next
time you display the same picture, it's really fast.

Emacs caches pictures internally, but that doesn't really explain the
incredible slowness the first time the picture is displayed remotely.
Or does it?

To me it seems like there might be a lot of ping-pong network chatter
when Emacs is instantiating pictures the first time.

In fact, just calling this takes several seconds remotely:

(image-size (create-image "/tmp/sleeve.jpg") t)

But only the first time.  

Hm.  Actually, `put-image' after the first `image-size' is
instantaneous.  Which sort of confirms my suspicions -- it's not the
remote image display per se that is latency-sensitive, but something
Emacs does while instantiating it.

Does anybody know what's causing this?  Or where I should poke around?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[Leo]

On 2010-09-24 00:43 +0100, Lars Magne Ingebrigtsen wrote:
> So that's the behaviour I don't understand.  The first time you display
> an image (over a high-latency X connection), it's really slow.  The next
> time you display the same picture, it's really fast.

I think emacs uses tramp to read remote images. Tramp is synchronous and
the latency is noticeable although it uses cache.

Leo

Re: Slow image display over network

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 24 Sep 2010 02:20:05 +0100
> 
> On 2010-09-24 00:43 +0100, Lars Magne Ingebrigtsen wrote:
> > So that's the behaviour I don't understand.  The first time you display
> > an image (over a high-latency X connection), it's really slow.  The next
> > time you display the same picture, it's really fast.
> 
> I think emacs uses tramp to read remote images.

This image is not remote.  Only the X connection is remote in the
use-case described by Lars.  The image file is on the same machine as
where Emacs runs.

Re: Slow image display over network

[Leo]

On 2010-09-24 08:58 +0100, Eli Zaretskii wrote:
>> I think emacs uses tramp to read remote images.
>
> This image is not remote.  Only the X connection is remote in the
> use-case described by Lars.  The image file is on the same machine as
> where Emacs runs.

2) says over X. Sorry, it was too late last night.

Leo

Re: Slow image display over network

[Daniel Pittman]

Lars Magne Ingebrigtsen <larsi@gnus.org> 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.

...during which, I bet, the image is pushed into the X server over that thin
link, taking a 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.

...which works by telling the remote server "draw this image here", without
having to ship any bits of image content, only send the draw instruction and
details about which remote image object to source the data from.

> So that's the behaviour I don't understand.  The first time you display an
> image (over a high-latency X connection), it's really slow.  The next time
> you display the same picture, it's really fast.
>
> Emacs caches pictures internally, but that doesn't really explain the
> incredible slowness the first time the picture is displayed remotely.
> Or does it?

Well, I bet that it is actually the X side, and the Emacs implementation uses
that, but...

> To me it seems like there might be a lot of ping-pong network chatter
> when Emacs is instantiating pictures the first time.

... you should be able to verify that with code inspection, or by checking the
X related network traffic.

Aw, heck.  I saved you the time: PNG loading does create the X image and
pixmap during the load process, confirming my guesswork.  I didn't check the
other image loaders, but they would sensibly behave the same way, showing the
same result.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: Slow image display over network

[Jan Djärv]

2010-09-24 03:47, Daniel Pittman skrev:

>
> Aw, heck.  I saved you the time: PNG loading does create the X image and
> pixmap during the load process, confirming my guesswork.  I didn't check the
> other image loaders, but they would sensibly behave the same way, showing the
> same result.
>

For the X backend, all images are copied to a pixmap (i.e. to the server) and 
then the X server renders it.  This applies to all image types so there is no 
need to check specific image loaders.

	Jan D.

Re: Slow image display over network

[David Kastrup]

Daniel Pittman <daniel@rimspace.net> writes:

> Aw, heck.  I saved you the time: PNG loading does create the X image
> and pixmap during the load process, confirming my guesswork.

Huh?  I am rather sure that the pixmap at least is created only at
(re)display time (if it is not yet in the image cache).  Not sure about
the X image.  Could be, however, that for image files, the load is
delayed to redisplay time as well (hard to do with XEmacs variants older
than 1 year or so as the file loader gets borked to non-binary when
dired has been loaded for some reason).  So that would mean that
technically you are right.

Poses an interesting problem when the file, indeed, is loaded
non-locally, since this will occupy tramp while in the redisplay loop,
and it better not try producing any terminal output.

-- 
David Kastrup

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

Daniel Pittman <daniel@rimspace.net> writes:

> Aw, heck.  I saved you the time: PNG loading does create the X image and
> pixmap during the load process, confirming my guesswork.  I didn't check the
> other image loaders, but they would sensibly behave the same way, showing the
> same result.

Right.  Image load pushes the image over X, even though we're not
actually going to display it?

That means that the way Gnus displays images is as pessimal as
possible.  When reading a HTML message with images, Gnus calls
(image-size (create-image ...)) to find out the size, and then if it's
too big, it rescales the image down.  And this means that the huge image
has to be transferred first over the slow X connection, and then
rescaled, and then probably transferred again?

Is this really necessary?  :-)  Why can't image transfer to the X server
wait until the `put-image' call?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[David Kastrup]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Pittman <daniel@rimspace.net> writes:
>
>> Aw, heck.  I saved you the time: PNG loading does create the X image and
>> pixmap during the load process, confirming my guesswork.  I didn't check the
>> other image loaders, but they would sensibly behave the same way, showing the
>> same result.
>
> Right.  Image load pushes the image over X, even though we're not
> actually going to display it?

AFAIU, image load is initiated in the display engine.  So we are
actually going to display it.

> That means that the way Gnus displays images is as pessimal as
> possible.  When reading a HTML message with images, Gnus calls
> (image-size (create-image ...)) to find out the size, and then if it's
> too big, it rescales the image down.

create-image is not a problem.  image-size, however, calls lookup_image,
and that loads and initiates an image, including caching it etc.

Not sure whether that really does the Pixmap as well.

> And this means that the huge image has to be transferred first over
> the slow X connection, and then rescaled, and then probably
> transferred again?
>
> Is this really necessary?  :-) Why can't image transfer to the X
> server wait until the `put-image' call?

Initially, there was no need to load the image until it was actually
displayed.

No idea what the code does right now.

-- 
David Kastrup

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> create-image is not a problem.  image-size, however, calls lookup_image,
> and that loads and initiates an image, including caching it etc.

Hm.  I can understand the need to instantiate the image if we're asking
for the char size of the image, but not the pixel size.  Perhaps this is
something that can be fixed pretty easily?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> create-image is not a problem.  image-size, however, calls lookup_image,
>> and that loads and initiates an image, including caching it etc.
>
> Hm.  I can understand the need to instantiate the image if we're asking
> for the char size of the image, but not the pixel size.  Perhaps this is
> something that can be fixed pretty easily?

It is straightforward but some work.  You have to replace the call to
lookup_image in `image-size' with a new function that avoids loading the
image.  This function would, in turn, call new functions that are
similar to *_load (where * is xbm, xpm, pbm, png, jpeg, tiff, gif, and
imagemagick), that extract the size data without loading the image data
if not already loaded.

Re: Slow image display over network

[joakim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Pittman <daniel@rimspace.net> writes:
>
>> Aw, heck.  I saved you the time: PNG loading does create the X image and
>> pixmap during the load process, confirming my guesswork.  I didn't check the
>> other image loaders, but they would sensibly behave the same way, showing the
>> same result.
>
> Right.  Image load pushes the image over X, even though we're not
> actually going to display it?
>
> That means that the way Gnus displays images is as pessimal as
> possible.  When reading a HTML message with images, Gnus calls
> (image-size (create-image ...)) to find out the size, and then if it's
> too big, it rescales the image down.  And this means that the huge image
> has to be transferred first over the slow X connection, and then
> rescaled, and then probably transferred again?
>
> Is this really necessary?  :-)  Why can't image transfer to the X server
> wait until the `put-image' call?

If you look at the imagemagick loader, there is an attempt there at
image "pinging", figuring out stuff about images withouth actualy
loading them. The pinging there is done to avoid loading an entire image
stack when you only want one image index in the stack. Maybe this ping
code could be generalized and exposed to lisp. I've noticed the need
myself several times.

(I hope that was relevant to your question)

-- 
Joakim Verona

Re: Slow image display over network

[Leo]

On 2010-09-24 13:05 +0100, joakim@verona.se wrote:
> If you look at the imagemagick loader, there is an attempt there at
> image "pinging", figuring out stuff about images withouth actualy
> loading them. The pinging there is done to avoid loading an entire
> image stack when you only want one image index in the stack. Maybe
> this ping code could be generalized and exposed to lisp. I've noticed
> the need myself several times.

Is "pinging" about obtaining the metainfo of an image? I think that is
useful in general.

Leo

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

> If you look at the imagemagick loader, there is an attempt there at
> image "pinging", figuring out stuff about images withouth actualy
> loading them. The pinging there is done to avoid loading an entire image
> stack when you only want one image index in the stack. Maybe this ping
> code could be generalized and exposed to lisp. I've noticed the need
> myself several times.

Yes, that sounds very useful.  If you have the time, could you make this
info available to the Lisp layer, and I can do some testing?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[joakim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> joakim@verona.se writes:
>
>> If you look at the imagemagick loader, there is an attempt there at
>> image "pinging", figuring out stuff about images withouth actualy
>> loading them. The pinging there is done to avoid loading an entire image
>> stack when you only want one image index in the stack. Maybe this ping
>> code could be generalized and exposed to lisp. I've noticed the need
>> myself several times.
>
> Yes, that sounds very useful.  If you have the time, could you make this
> info available to the Lisp layer, and I can do some testing?

Meanwhile(I'm out of Emacs hack budget for a while), heres some other
code I had lying around:

(defun emsane-image-size (image-file)
  "Return the size of IMAGE-FILE as a cons."
  ;;TODO I snipped this from "dragbox.el" so it might be reusable
  (with-current-buffer (get-buffer-create "*imagemagic identify*")
    (erase-buffer)
    (call-process "identify" nil "*imagemagic identify*" nil "-verbose" image-file) ;; "-ping" sometimes segfaults for me
    (goto-char (point-min))
    (re-search-forward "Geometry: \\([0-9]+\\)x\\([0-9]+\\)")
    (cons (string-to-number (match-string 1))
          (string-to-number (match-string 2)))))


Aparently the "-ping" flag segfaulted for me when I wrote that
snippet(it doesnt seem to do that now). "-verbose" is similar but gives
much more info and is not as efficient as -ping.

The C code would look vaguely similar to this(for the imagemagick loader):

  MagickWand  *ping_wand;
  int siz_x; int siz_y;
  status = MagickPingImage(ping_wand, filename);
  numimages = MagickGetNumberImages(ping_wand);
  MagickGetImageResolution(ping_wand, &siz_x, &siz_y);

To do this properly I would suppose one needs to invent a lisp structure
compatible with the display spec that can hold image meta data, and have
several implementations of the interface, one for imagemagick, one for
when imagemagick isnt available, that could maybe use "file" etc
ad-overengineering-nauseam. (also call the meta function depending on
the image loader)
  
-- 
Joakim Verona

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

>     (call-process "identify" nil "*imagemagic identify*" nil "-verbose" image-file) ;; "-ping" sometimes segfaults for me

Hm.  That would make gnus-html more usable on a remote X, but adding
dependencies on yet another external program isn't all that attractive
to me...

> The C code would look vaguely similar to this(for the imagemagick loader):
>
>   MagickWand  *ping_wand;
>   int siz_x; int siz_y;
>   status = MagickPingImage(ping_wand, filename);
>   numimages = MagickGetNumberImages(ping_wand);
>   MagickGetImageResolution(ping_wand, &siz_x, &siz_y);
>
> To do this properly I would suppose one needs to invent a lisp structure
> compatible with the display spec that can hold image meta data, and have
> several implementations of the interface, one for imagemagick, one for
> when imagemagick isnt available, that could maybe use "file" etc
> ad-overengineering-nauseam. (also call the meta function depending on
> the image loader)

Yes, that would be the clean way to do it.  However, since :resize and
stuff only works on the imagemagick image thing anyway, would it make
sense to special-case image-size for imagemagick images?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 24 Sep 2010 13:23:02 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

> Daniel Pittman <daniel@rimspace.net> writes:
>> Aw, heck.  I saved you the time: PNG loading does create the X
>> image and pixmap during the load process, confirming my guesswork.
>> I didn't check the other image loaders, but they would sensibly
>> behave the same way, showing the same result.

> Right.  Image load pushes the image over X, even though we're not
> actually going to display it?

> That means that the way Gnus displays images is as pessimal as
> possible.  When reading a HTML message with images, Gnus calls
> (image-size (create-image ...)) to find out the size, and then if
> it's too big, it rescales the image down.  And this means that the
> huge image has to be transferred first over the slow X connection,
> and then rescaled, and then probably transferred again?

> Is this really necessary?  :-) Why can't image transfer to the X
> server wait until the `put-image' call?

Of course, creation of Pixmap from XImage can be deferred until the
actual display happens.  Actually, the Carbon port and its descendants
do that.  In those ports, CGImage (which conceptually corresponds to
Pixmap in X11) is created from struct _XImage (which corresponds to
XImage in X11) at prepare_image_for_display, not at lookup_image.  The
`pixmap' and `mask' members in struct image actually point to struct
_XImage data rather than CGImage there.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Slow image display over network

[Stephen J. Turnbull]

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.

Re: Slow image display over network

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> 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

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> 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.

So are you suggesting that this can be fixed?

> 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.

First it's transferred pixel-by-pixel, and then it's transferred as an
image? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[David Kastrup]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> So are you suggesting that this can be fixed?

You are in a twisty little maze of per-pixel procedure calls, all alike.
Intermingled is the display alpha channel correction.  Calculated fresh
for every pixel.

Of course it would make sense to batch all of this and do calls only for
whole pictures or rectangles.  That needs restructuring the code.

If that is done well, it would make sense to route the color management
on a Gtk target completely through Gdk: it does a good and
well-optimized job with it.  But you won't get much of an improvement if
you call Gdk again for every pixel.

>> 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.
>
> First it's transferred pixel-by-pixel, and then it's transferred as an
> image?

No.  First it is _created_ entirely on the client side using a call
chain ending in Xlib calls, pixel-by-pixel for the whole call chain.
Then the X Image (which is a client-side data structure) is transferred
into a Pixmap (which is a server-side data structure) as one piece.

So while Xlib is called over and over, the actual traffic to the X
server should be tolerably optimized.

All of this speaking just from memory of when I last looked at the Emacs
21 display engine.

-- 
David Kastrup

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> No.  First it is _created_ entirely on the client side using a call
> chain ending in Xlib calls, pixel-by-pixel for the whole call chain.
> Then the X Image (which is a client-side data structure) is transferred
> into a Pixmap (which is a server-side data structure) as one piece.
>
> So while Xlib is called over and over, the actual traffic to the X
> server should be tolerably optimized.

Ah, right; I understand.  Thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[Jan Djärv]

2010-09-24 13:59, David Kastrup skrev:

>
> Of course it would make sense to batch all of this and do calls only for
> whole pictures or rectangles.  That needs restructuring the code.
>
> If that is done well, it would make sense to route the color management
> on a Gtk target completely through Gdk: it does a good and
> well-optimized job with it.  But you won't get much of an improvement if
> you call Gdk again for every pixel.

As it stands now, Gdk image handling that uses xlib doesn't do more than one 
display.  Gdk image handling with xlib isn't very well maintained either.  We 
would have to convert to a Gdk-backend.

	Jan D.

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> 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?

You do understand that it's often common to ask questions about things
that you wonder about?  So, to answer your question: No, I didn't.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> 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've done some simple tests via ssh/X, and it seems that the XEmacs
image display is vaguely slower, but it's a bit difficult to time.
There's no huge difference, in any case.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Slow image display over network

[joakim]

I think most has been said in the other replies, but heres some random
other thoughts(sorry for top-posting):

- Try a compressed X implementation such as NX, and see how that
  compares. (My guess is that the initial image transfer will be a bit
  faster since NX can transfer pixmaps in compressed formats)

- One of the TODO:s for the ImageMagick branch is to try to optimize
  display of images with low color-depth. I think several of the image
  loaders just allocates full RGB pixmaps even though a binary pixmap
  would be sufficient for a BW image for example. This optimization
  wouldnt help actual RGB images though.

- It would be interesting to try out to optimize SVG support, for
  instance, by implementing it as vector drawing calls on the X display
  rather than, as now, drawing the SVG into a pixmap that then gets
  transmitted through the wire and cached in the X server. That seems
  like a lot of work though.
  

Have fun playing around in the image code!

/Joakim

Lars Magne Ingebrigtsen <larsi@gnus.org> 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.
>
> So that's the behaviour I don't understand.  The first time you display
> an image (over a high-latency X connection), it's really slow.  The next
> time you display the same picture, it's really fast.
>
> Emacs caches pictures internally, but that doesn't really explain the
> incredible slowness the first time the picture is displayed remotely.
> Or does it?
>
> To me it seems like there might be a lot of ping-pong network chatter
> when Emacs is instantiating pictures the first time.
>
> In fact, just calling this takes several seconds remotely:
>
> (image-size (create-image "/tmp/sleeve.jpg") t)
>
> But only the first time.  
>
> Hm.  Actually, `put-image' after the first `image-size' is
> instantaneous.  Which sort of confirms my suspicions -- it's not the
> remote image display per se that is latency-sensitive, but something
> Emacs does while instantiating it.
>
> Does anybody know what's causing this?  Or where I should poke around?

-- 
Joakim Verona