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: Wed, 27 Feb 2019 00:50:10 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003f608b0582d30b7b" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="15054"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Daniel Pittman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 22:50:40 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 1gykcZ-0003o9-Jh for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2019 22:50:40 +0100 Original-Received: from localhost ([127.0.0.1]:33697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gykcY-0005B8-LX for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2019 16:50:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gykcP-0005B1-1V for emacs-devel@gnu.org; Tue, 26 Feb 2019 16:50:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gykcN-0008F1-MQ for emacs-devel@gnu.org; Tue, 26 Feb 2019 16:50:28 -0500 Original-Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:36949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gykcM-0008C6-Uh for emacs-devel@gnu.org; Tue, 26 Feb 2019 16:50:27 -0500 Original-Received: by mail-lj1-x22d.google.com with SMTP id a17so12136902ljd.4 for ; Tue, 26 Feb 2019 13:50:23 -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=7aKL4d98sD808TMzr+nnLGfQoTdj06oPHVu05g/WNKE=; b=H721Xw0cqpSQGboKcTydg7Fq2uMGGk+N3jFBwSAEM2hvGRB3iWA4/yLPjPMuxQ6xux FDSi3owbUlR2b2EZ8G8+a1TvOPJza1e9O9QElXKnQjr2oX6hG0aIL5Ob55/YDQJqeIZX B0tmWdA9fKNS3QP3d/trNALK2yWYELlqNRarwuh1wXF6CqKLWWk+dFUj8qa9hBoIVGvt FDcA0Vp0XIR6D0HGrERNHFyIOYM+Z6l088sJ+7924PKwdkdsb/rG+YPTwDMwWcTc/8MO Ehb2xGdO3/pV51mRaOmkDMP/ef3UtP1oMBAd+GicBumr+l6xoJJtzvg2EqoS5stlalYE hCcg== 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=7aKL4d98sD808TMzr+nnLGfQoTdj06oPHVu05g/WNKE=; b=dbqg/d8R3kdlGJ+OB9BIuqZi6RM6z9sd8wg7lc+YsUlUhXbmAjTgRt7EFzWPlvWQIh KZa6MC2xrLAS9a0mBRx8up6JjfYE122xaFU0g2u6DgQ4z8Nk25ZfhhgLAvIWJEfdIbSe lWoJv8zgDCVXPh2wepJ2Tj6esfeHg7qJhNPd4x9K0l/OnNQXYKCyxyABXyitwq9XFcEl Ge6wJFo4YM1ZI+DfPNSWG2c3Yh7+qVgdo32FdC2SM5xx+3S9Is9luxaQKeXVshdxOBjE AGtYOFUYHbTpU15W8DlF7lOdRwxz6KNHQerqOqzud8TrTFF5lC7gmKwdh42Obj8X9UuD gR0A== X-Gm-Message-State: AHQUAuZPalxgEcLwtzfqqVibcOuUMLk+rDJVJ01QQ5SI/FipdiEOCHby nJ6IK0GX/3TKtsDR4hwBJ0yoNIDGA2Qe0UmTRY4= X-Google-Smtp-Source: AHgI3IbtEGcAFCNQGVhNKVZCmDkM+tzHPh51JPtInSEGby1rr8uEVBdTyPrtcyc0tEClAXn5koiY1t/GyweICYZWhEg= X-Received: by 2002:a2e:312:: with SMTP id 18mr15558372ljd.114.1551217821964; Tue, 26 Feb 2019 13:50:21 -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::22d 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:233641 Archived-At: --0000000000003f608b0582d30b7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=81=D1=80, 27 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 00:19, Danie= l Pittman : > On Wed, Feb 13, 2019 at 9:56 AM Evgeny Zajcev 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 el= se > 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 =E2=80=93 = highly > likely, I suspect =E2=80=93 then that time-cost would be paid the first t= ime. 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 ~=3D 6= 5 * 0.25 On your machine timings might differ of course --=20 lg --0000000000003f608b0582d30b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D1=81=D1=80, 27 =D1=84=D0=B5=D0=B2=D1=80= . 2019 =D0=B3. =D0=B2 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=C2=A0http= ://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.=C2=A0 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 = =E2=80=93 highly likely, I suspect =E2=80=93 then that time-cost would be p= aid the first time.=C2=A0 A grand total of 18 seconds to do that processing= doesn't actually sound unreasonable to me, honestly, given that decodi= ng all those frames in individual processes takes ~ 5.35 seconds total on m= y machine.=C2=A0 It wouldn't take much inefficiency on top of that to b= ring it up to that rate.

Decoding all the frames takes only 0= .25 seconds (see timings for the convert run).=C2=A0 The problem is that Em= acs decodes EVERY frame any time you change the image index for the animati= on, that is how you get 18secs ~=3D 65 * 0.25

= On your machine timings might differ of course

--
<= div dir=3D"ltr" class=3D"gmail_signature">lg
--0000000000003f608b0582d30b7b--