From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: excessively slow image animation Date: Thu, 14 Feb 2019 03:30:33 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e99a620581cfc4f4" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="52352"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 14 01:31:17 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu4vt-000DSD-Gm for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 01:31:17 +0100 Original-Received: from localhost ([127.0.0.1]:37272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu4vs-0005dy-Ef for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2019 19:31:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu4vg-0005dg-1g for emacs-devel@gnu.org; Wed, 13 Feb 2019 19:31:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gu4va-0001dr-MW for emacs-devel@gnu.org; Wed, 13 Feb 2019 19:31:04 -0500 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:38232) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gu4vW-00011A-S4 for emacs-devel@gnu.org; Wed, 13 Feb 2019 19:30:56 -0500 Original-Received: by mail-lj1-x22a.google.com with SMTP id j19so2873320ljg.5 for ; Wed, 13 Feb 2019 16:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t7q1558KfK8v4tPgQ6bvzr9H+hSVtqFOh5ATzyK3Q6A=; b=OfEpxbzskC3n1pE0alyqnqm5zKZ9eXnlyoy8yYsAFkyPCUxWBfP12DL/f5NPPWzKnO DZ+hffA8mgQyWJuDqlEUc0d4Ddhn93v30PjwfsIwajJpkiS1yoDgf8ANsvdBCs+qMIQv GR76VelTs2uCaQmHP8sS1pis3PCtg97vB32DVMXuNK4U2zZuCn3kJwobnnX8O7EaiLdu /8EZeNjEN3eQGOpQ1ibF+yvqXY4gth8wWk8yl9+HHjaEWqz0b91ueDdW7Mfhxi3HRMut GaJM2/Zw9s9X30YzXCSNPGAgwWBtUEMK65X/ymTfanQmMK1BcYxCnmE/6nDb0nYKBSFV B3KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t7q1558KfK8v4tPgQ6bvzr9H+hSVtqFOh5ATzyK3Q6A=; b=r52VjtczbdY/DgHxaAswA8CulKimAT+ZxQ3BiE+7RtyA5+JueITw5BgV+OtGDyxu1h TMrutOO0a9IttJRsYbI2f9zkkoBhDa+9XRYABT0vv6z1N5mxtRi4DvvvqiXfwPMscO7s PESKDSRl0HkpSF9cXeA/f2LLoT2IG+0Cz16s/quEzNlmM1YShzc1Z2QbLCZi8XFYhwtD q7diYljE1hjRH26u3ZgHwW+VUfMI/aiXWByIpy3Wwa/U88qlqSiK2WbGCkZFshQ/SnjG TxCVlMVXWHvsHJjPKkCTAPdz74Y/a6x2L+ZL81FCeslKBm95GWAbnT7rbCoZvD4PSsWP XCXQ== X-Gm-Message-State: AHQUAuZ8oS/ddaG0Yyk/4Jt9lUHQiArgpj26Je05KXwJq+HAxYJEaL+S o6JC+GcS4dhWlmqSGIuucM2IxmJtrkMspJAnPLp2Qx6e X-Google-Smtp-Source: AHgI3IbUsaQL7bWz0/JUujNFKlylHMIxtv8uIzpnU0TjmmxBxN02ahFgSx68k05L2QPgPwwov/8jL5JghBWyDidi9SE= X-Received: by 2002:a2e:380d:: with SMTP id f13-v6mr519016lja.17.1550104245408; Wed, 13 Feb 2019 16:30:45 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233300 Archived-At: --000000000000e99a620581cfc4f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 20:03, Lars = Ingebrigtsen : > Evgeny Zajcev 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)) > > =3D=3D> 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=3D13 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 --=20 lg --000000000000e99a620581cfc4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D1=81=D1=80, 13 =D1=84= =D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 20:03, Lars Ingebrigtsen <larsi@gnus.org>:
Evgeny Zajce= v <lg.zevlg@gmai= l.com> writes:

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

Wow, that's slow...

[...]

> Now I use method with bmp files.=C2=A0 I would like to use built in `:= index' image
> property to animate images, however current animation speed is totally= not
> acceptable.=C2=A0 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.=C2=A0 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.=C2=A0 :-)

The= problem is that IM always decodes multi frame images to the last image upp= on MagickReadImage.=C2=A0 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=3D13 seconds

A= nimation 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 m= aybe just the filename!)

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

--
lg
--000000000000e99a620581cfc4f4--