Re: XPM via Lisp in the toolbar

[alkibiades@gmx.de]

Richard Stallman <rms@gnu.org> writes:

>     As long as the image is not _explicitly_ re-read from disk as in my
>     example and as long as the image descriptor is not garbage collected,
>     this should already be the case. Not even clearing the image cache (I
>     mean the built-in image cache) would cause a second conversion,
>     because the image descriptor contains all image data as a value of the
>     :data attribute.
>
> Are you sure that the same image is not likely to be read from disk
> many times in an Emacs session?  I don't know for certain, but I would
> have expected that to be common.

I don't know the C code behind that -- so please read the following
with that reservatio mentalis. But as far as I understand the issue,
it won't happen.

AFAICS it is prevented on two stages:

The Emacs Lisp Reference says about the image cache:

,----
|    Emacs stores images in an image cache when it displays them, so it
| can display them again more efficiently.  It removes an image from the
| cache when it hasn't been displayed for a specified period of time.
| 
|    When an image is looked up in the cache, its specification is
| compared with cached image specifications using `equal'.  This means
| that all images with equal specifications share the same image in the
| cache.
`----

The variable `image-cache-eviction-delay' controls how long an image
may remain in the image cache without being displayed. The default is
30 minutes.

Normally -- that is: without xpm.el -- the image descriptor for an
icon in the tool bar would look like this:

(image :file "/some/path/search.xpm" :type xpm ... )

So if the icon was not displayed for 30 minutes and Emacs has to
display it again, it would read "search.xpm" from the disk again. That
is how I understand it.

But with `xpm-create-image' hooked into `find-image' as a fall-back
for XPMs the image descriptor looks like this:

(image :data "P6 32 32 255 ... <binary data> ..." :type pbm ... )

So as far as Emacs is concerned there is no file attached to the image
anymore. The string after :data contains the whole information
necessary to display the image.

I don't know whether an image descriptor in `tool-bar-map' has any
chance to get garbage collected. As long as this does not happen,
there is no need to read the image from the disk again. To read the
image from the disk again, it would need another explicit call to
`find-image'. I wouldn't know where in the code this latter could take
place, BTW.

    Oliver
-- 
Oliver Scholz               27 Brumaire an 211 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org