Re: image scaling

[Chong Yidong]

David Kastrup <address@hidden> writes:

>>>> but it's simple enough to understand and work on; and I don't know of
>>>> any performance problem in the way Emacs handles image pixmaps.
>>>
>>> You must be kidding.  We have an image cache exactly because Emacs can't
>>> handle images close to reasonably efficiently.
>>
>> Don't other programs use caches for images?
>
> XEmacs, for example, does not have the equivalent, and works fine
> (actually quite faster than Emacs) when using preview-latex.
>
> The point is that when the image data is loaded into memory, Emacs still
> can't display it fast.  It converts it with a painfully slow conversion
> chain called for every pixel into a pixmap and caches that.  Considering
> that the binary data is pretty much identical a pixmap to start with
> (maybe modulo a gamma correction lookup table), this is somewhat
> ridiculous.  The code paths are so muddled, however, that it is not easy
> to rip this out.
>
> Have you actually looked at the code?

I'm fairly familiar with the code.

If Emacs can't quickly display images that are already loaded into
memory, it's not clear to me that the problem lies in the image.c code
rather than redisplay.  Could you elucidate?  When you say the image
is already "loaded into memory", do you mean that the image is
supplied using a Lisp string representing binary data (i.e., passing a
DATA-P argument to create-image), or are you simply referring to time
Emacs takes to run the png_load function (i.e., from calling the
libpng functions parsing the file until Emacs finishes populating and
caching the pixmaps)?