excessively slow image animation

excessively slow image animation

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

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

Then I simple converted the file to set of bmp files:

  $ time convert ~/tmp/giphy.mp4 ~/tmp/anim1/giphy%05d.bmp
  convert ~/tmp/giphy.mp4 ~/tmp/anim1/giphy%05d.bmp  0,18s user 0,10s
system 117% cpu 0,237 total
  $

And animated on these bmp files:

  (let ((ctime (float-time)))
    (setq img (create-image "~/tmp/anim1/giphy00000.bmp" 'imagemagick nil
:scale 1.0))
    (insert-image img)
    (cl-dotimes (index 65)
      (plist-put (cdr img) :file (format "~/tmp/anim1/giphy%05d.bmp" index))
      (force-window-update)
      (sit-for 0.0))
    (- (float-time) ctime))
  ==> 1.3518333435058594

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?

Thanks

--Versions--
EMACS: GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.18.9) of 2018-11-13
IM: Version: ImageMagick 6.8.9-9 Q16 x86_64 2018-09-28
http://www.imagemagick.org

-- 
lg

[-- Attachment #2: Type: text/html, Size: 2337 bytes --]

Re: excessively slow image animation

[Lars Ingebrigtsen]

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: excessively slow image animation

[Alan Third]

On Wed, Feb 13, 2019 at 06:03:51PM +0100, Lars Ingebrigtsen wrote:
> 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...

As an aside: for some reason if you run this a second time it doesn’t
use the already cached images from the first run, so it’s just as slow
as that first run. I may be misunderstanding how the cache is supposed
to work, but that doesn’t seem right to me.

-- 
Alan Third

Re: excessively slow image animation

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

чт, 14 февр. 2019 г. в 02:15, Alan Third <alan@idiocy.org>:

> On Wed, Feb 13, 2019 at 06:03:51PM +0100, Lars Ingebrigtsen wrote:
> > 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...
>
> As an aside: for some reason if you run this a second time it doesn’t
> use the already cached images from the first run, so it’s just as slow
> as that first run. I may be misunderstanding how the cache is supposed
> to work, but that doesn’t seem right to me.
>

Cache washes out really fast even if you set `image-cache-eviction-delay'
to huge value.
In my case, I want to animate 50 images simultaneously and it is not yet
possible without tweeks.

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1959 bytes --]

Re: excessively slow image animation

[Alan Third]

On Thu, Feb 14, 2019 at 02:29:45AM +0300, Evgeny Zajcev wrote:
> 
> Cache washes out really fast even if you set `image-cache-eviction-delay'
> to huge value.
> In my case, I want to animate 50 images simultaneously and it is not yet
> possible without tweeks.

The more images loaded the shorter a cache eviction time it uses, so I
can see that causing trouble with what you’re doing.

Out of interest, what are you doing that requires 50 animated images?
-- 
Alan Third

Re: excessively slow image animation

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

чт, 14 февр. 2019 г. в 21:22, Alan Third <alan@idiocy.org>:

> On Thu, Feb 14, 2019 at 02:29:45AM +0300, Evgeny Zajcev wrote:
> >
> > Cache washes out really fast even if you set `image-cache-eviction-delay'
> > to huge value.
> > In my case, I want to animate 50 images simultaneously and it is not yet
> > possible without tweeks.
>
> The more images loaded the shorter a cache eviction time it uses, so I
> can see that causing trouble with what you’re doing.
>

I can easily tolerate washing from the cache in case animation is fast
enough (as with bpm files), but I've got the problem even with single
small, but pretty lasting animation file.

Out of interest, what are you doing that requires 50 animated images?
>

Preview for saved animations in Emacs telegram client -
https://github.com/zevlg/telega.el

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

Re: excessively slow image animation

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

ср, 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

[-- Attachment #2: Type: text/html, Size: 2626 bytes --]

Re: excessively slow image animation

[Stefan Monnier]

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

BTW, since the ImageMagick support is being deprecated, maybe it's not
that important to fix this performance problem and instead look at
providing that feature with the other image libs.


        Stefan

Re: excessively slow image animation

[Daniel Pittman]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Feb 13, 2019 at 9:56 AM Evgeny Zajcev <lg.zevlg@gmail.com> wrote:

> I've got multi frame image at http://lgarc.narod.ru/giphy.mp4
> 18 seconds to show every frame
>

Time to fully extract the images from that (cold cache) on my laptop was ~
30 seconds.  It contains one key frame, the very first, and everything else
is a P frame, so to decode frame 20 you need to run forward applying 19
frames worth of data from the start.

If the components were being cached or generated independently – highly
likely, I suspect – then that time-cost would be paid the first time.  A
grand total of 18 seconds to do that processing doesn't actually sound
unreasonable to me, honestly, given that decoding all those frames in
individual processes takes ~ 5.35 seconds total on my machine.  It wouldn't
take much inefficiency on top of that to bring it up to that rate.

>

[-- Attachment #2: Type: text/html, Size: 1612 bytes --]

Re: excessively slow image animation

[Evgeny Zajcev]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

ср, 27 февр. 2019 г. в 00:19, Daniel Pittman <slippycheeze@google.com>:

> On Wed, Feb 13, 2019 at 9:56 AM Evgeny Zajcev <lg.zevlg@gmail.com> wrote:
>
>> I've got multi frame image at http://lgarc.narod.ru/giphy.mp4
>> 18 seconds to show every frame
>>
>
> Time to fully extract the images from that (cold cache) on my laptop was ~
> 30 seconds.  It contains one key frame, the very first, and everything else
> is a P frame, so to decode frame 20 you need to run forward applying 19
> frames worth of data from the start.
>
> If the components were being cached or generated independently – highly
> likely, I suspect – then that time-cost would be paid the first time.  A
> grand total of 18 seconds to do that processing doesn't actually sound
> unreasonable to me, honestly, given that decoding all those frames in
> individual processes takes ~ 5.35 seconds total on my machine.  It wouldn't
> take much inefficiency on top of that to bring it up to that rate.
>
>>
Decoding all the frames takes only 0.25 seconds (see timings for the
convert run).  The problem is that Emacs decodes EVERY frame any time you
change the image index for the animation, that is how you get 18secs ~= 65
* 0.25

On your machine timings might differ of course

-- 
lg

[-- Attachment #2: Type: text/html, Size: 2367 bytes --]