[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDI+ take 3

From: Juan José García-Ripoll
Subject: Re: GDI+ take 3
Date: Tue, 21 Apr 2020 09:35:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Juan José García-Ripoll
>>  <address@hidden>
>> Date: Sun, 19 Apr 2020 22:08:06 +0200
>> The image that was supplied by Alan has a nominal delay time of 0.03
>> seconds between frames. Emacs 26.3 takes about 0.14 seconds on average
>> to load each frame of the gif file, using giflib. Emacs 28 as I built it
>> from git source right now, takes 0.3 seconds with giflib and a time that
>> grows from 0.01 up to 0.16 seconds (probably because frames have to be
>> read sequentially, there is no index).
> Can you show the Lisp you used to time this?  I'd like to see what
> times I get here.

It is attached. Note that it is an ugly hack. I am rewriting
image-animate-timeout because I have to get access to the internal variables.

> Also, do you have any suggestions how to fix this?  Perhaps we should first
> create the images and cache them, and only then start the animation?  Some
> other ideas?

That is one option. I am not sure about the logic on caching, and whether it
warrants that all frames would be kept in memory.

Other than that, one might have to reconsider the current mechanism how images
are built. In all platforms, when using giflib, images cleared various times
and built using PUT_PIXEL. I think this is behind the slowdown compared to

To make an informed decision, it would be appropriate to know what happens on
other platforms. In OSX it seems that loading of gifs is fast enough that, like
GDI+, no fix would be required. What about Xwindows / Cairo? Does it vary much?
I do not have machines to gather this information


Juan José García Ripoll

Attachment: image-test.el
Description: application/emacs-lisp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]