Re: image scaling

[David Kastrup <dak@gnu.org>]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.

It's been some time since I looked at it, and it was pretty inscrutable.
I doubt it has improved much.

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

Oh, I was not trying to assign blame to a particular piece of code.  It
is just what happens in totality is pretty ugly, almost to the point of
being absurd.  It may well be that each part, in isolation, does things
as good as can be expected, given the designed APIs and pathways.

> 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),

For example.

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

It has been some time since I last looked at the code and finally gave
up in disgust (twisty maze of passages...).  So I can't be much more
specific.  The gist is that Emacs is orders of magnitude slower than
programs which basically just tie libraries together without serious
data manipulation of their own.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum