ср, 13 февр. 2019 г. в 20:03, Lars Ingebrigtsen <larsi@gnus.org>:
Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> I've got multi frame image at http://lgarc.narod.ru/giphy.mp4
>
> And run next code on it:
>
>   (let ((ctime (float-time)))
>     (setq img (create-image "~/tmp/giphy.mp4" 'imagemagick nil :scale 1.0))
>     (insert-image img)
>     (cl-dotimes (index 65)
>       (image-show-frame img index 'nocheck)
>       (sit-for 0.0))
>     (- (float-time) ctime))
>   ==> 18.788017988204956
>
> 18 seconds to show every frame

Wow, that's slow...

[...]

> Now I use method with bmp files.  I would like to use built in `:index' image
> property to animate images, however current animation speed is totally not
> acceptable.  Can this be fixed, or am I doing something wrong?

If I remember correctly, I was the one that added the :index support for
imagemagick images in Emacs.  It's quite likely that I was using
non-optimal ways to do the animation and that imagemagick has better and
faster ways of doing the computation.

Have a look at imagemagick_compute_animated_image in image.c and rewrite
to be faster.  :-)

The problem is that IM always decodes multi frame images to the last image uppon MagickReadImage.  In this example it takes ~0.2 seconds (as time on convert command shows), so just loading time without pixel operations, etc would take 0.2*65=13 seconds

Animation code always do MagickReadImage uppon loading image, even if there is cached wand.

Probable solution would be to use some other signature for the cache (md5sum on blob, or md5sum on file, or maybe just the filename!)

In this case we can just get the wand from the cache, without calling MagickReadImage on `:index' change

--
lg