From unknown Mon Jun 23 16:45:18 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#47895 <47895@debbugs.gnu.org> To: bug#47895 <47895@debbugs.gnu.org> Subject: Status: 28.0.50; Emacs should only animate images that are visible Reply-To: bug#47895 <47895@debbugs.gnu.org> Date: Mon, 23 Jun 2025 23:45:18 +0000 retitle 47895 28.0.50; Emacs should only animate images that are visible reassign 47895 emacs submitter 47895 Lars Ingebrigtsen severity 47895 normal tag 47895 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 14:19:39 2021 Received: (at submit) by debbugs.gnu.org; 19 Apr 2021 18:19:39 +0000 Received: from localhost ([127.0.0.1]:52007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYUl-0007rE-Gc for submit@debbugs.gnu.org; Mon, 19 Apr 2021 14:19:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:52778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYUj-0007r5-El for submit@debbugs.gnu.org; Mon, 19 Apr 2021 14:19:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYYUj-0004ie-96 for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 14:19:37 -0400 Received: from quimby.gnus.org ([2a01:4f9:2b:f0f::2]:34266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYYUf-0001mf-9A for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 14:19:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7u9m0mi8ZNZ1yqgUDKITKJXaCAcm+gIQrg53Liqkd6I=; b=NIoz3VPCiCdqbRjQ0lYw5l/Pg3 b00TusmIk7qOMVjZxtKeM9Z9poo+vf99e/vIObYwSYrDS5GM+3Wvx5sYfiqlrAZ1htyq8dlZ+vSaJ 9YQCny3r3S5KatnHQD75KdtO2k0BPXX6SIpxoBU7+ki/cNoeTp78DfdGAP2t5w/kBfhU=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYYUS-0003Ow-Em for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 20:19:29 +0200 From: Lars Ingebrigtsen To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Emacs should only animate images that are visible X-Now-Playing: Anthony Shake Shakir's _Frictionalism 1994-2009_: "Happy To Be Here" Date: Mon, 19 Apr 2021 20:19:19 +0200 Message-ID: <87r1j6m920.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Emacs is generally slow about calculating animated images, and that should be fixed (there's a separate bug report for that), but there's one thing Emacs could be doing: Not animating images that are off screen. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Emacs is generally slow about calculating animated images, and that should be fixed (there's a separate bug report for that), but there's one thing Emacs could be doing: Not animating images that are off screen. I think most web browsers do this -- to avoid using too much CPU, which is the same problem we have in Emacs: Opening a web page with many large animated GIFs usually makes Emacs very slow. In GNU Emacs 28.0.50 (build 78, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-04-11 built on xo Repository revision: 751e801f90339480ea43fc2237fc45c8eb39bd6f Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12010000 System Description: Debian GNU/Linux bullseye/sid -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 14:28:42 2021 Received: (at 47895) by debbugs.gnu.org; 19 Apr 2021 18:28:42 +0000 Received: from localhost ([127.0.0.1]:52046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYdS-00086S-V5 for submit@debbugs.gnu.org; Mon, 19 Apr 2021 14:28:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYdO-00086C-IL for 47895@debbugs.gnu.org; Mon, 19 Apr 2021 14:28:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46805) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYYdJ-0005Jv-Bp; Mon, 19 Apr 2021 14:28:29 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2615 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lYYdH-00074w-KQ; Mon, 19 Apr 2021 14:28:28 -0400 Date: Mon, 19 Apr 2021 21:28:09 +0300 Message-Id: <8335vmrux2.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87r1j6m920.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 19 Apr 2021 20:19:19 +0200) Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Lars Ingebrigtsen > Date: Mon, 19 Apr 2021 20:19:19 +0200 > > Emacs is generally slow about calculating animated images, and that > should be fixed (there's a separate bug report for that), but there's > one thing Emacs could be doing: > > Not animating images that are off screen. > > I think most web browsers do this -- to avoid using too much CPU, which > is the same problem we have in Emacs: Opening a web page with many large > animated GIFs usually makes Emacs very slow. I'd be interested to see a backtrace for such animation of an image that is not on display. In general, since animation is triggered (I think) when the image is being prepared for redisplay, what you describe shouldn't be happening. If it dies indeed happen, I have a couple of guesses how that could be triggered, but it would be nice to see evidence. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 16:50:10 2021 Received: (at 47895) by debbugs.gnu.org; 19 Apr 2021 20:50:10 +0000 Received: from localhost ([127.0.0.1]:52229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYaqQ-0005JO-Eo for submit@debbugs.gnu.org; Mon, 19 Apr 2021 16:50:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:45784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYaqO-0005J5-FQ for 47895@debbugs.gnu.org; Mon, 19 Apr 2021 16:50:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nD9e2bxmUTKT1CXKspG582ZV1HU+hPF2Uo8gJDk8cuI=; b=VzaV8k0evLmtlxi3a0JpKZCyVA 6mBeWbipYgJqS9g9XeU7SqQE/o+7EZnGb9ITW0GWcG7GvirRsEwswzXtyOe3fI2V33WtI2186LV8E n5bK8/oQJqLRPZETgQsDNxfnhMPiSwsP17g2AGA2hXT8Ujpg2dxi9yPf6a4SzHD6HQwQ=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYaqD-0004uj-Pr; Mon, 19 Apr 2021 22:50:01 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEWTMMGRKsTVnOnt zfaZKcr+/f52GqD///+ObDFaAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UECxAEMPZPV4gAAAF5SURB VDjLbZRBcsIwDEWddqbriPF0DSTpvgkcwEHsOzE+ABvuf4TKkS0pgBbg6I30g/SNcw28RncAJw9t N017AKTjZ4zg7iW/OyeKMZPv4S81tZNf8ymd6AjDkn5c6XVNJQ4AgUCt8DWfltyWPkvBRUAK9PjR VDAo+OWMU+l47DK4WbDLmR78UEQ2YAkY8ncMBmTtm0f0VZ1AU8EJCZwVSMWJKsLc4/wMFgKoA9ZW kfIYfNgAfl20JQakPryAMvQRQQiLhzKr2KsGgzpdIS0DrAukgaCp8CglNDIrDjzYulvVIBXfFXDb VijZjD3rI85n00s0UEj/CnAunjOtGOAg6k4lclzEDep26WWAP1K8A+s63lbIAp801tlm+4Tr9q3Y mtVX5nfwAqlXZ0Zirsc0yQUpI/F6odTtjTWDjgrcuuKwk3wUM/Dyh6eC7JLVMNUm7IWW7ZNrAi9p rH5r3ePOBPDYjfuaz4DiDjbW1s59PRg96Fz+P5qWTv9m48NQfjGOUwAAACV0RVh0ZGF0ZTpjcmVh dGUAMjAyMS0wNC0xMVQxNjowNDo0OCswMDowMFi2i04AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEt MDQtMTFUMTY6MDQ6NDgrMDA6MDAp6zPyAAAAAElFTkSuQmCC X-Now-Playing: Anthony Shake Shakir's _Frictionalism 1994-2009_: "Fact Of The Matter" Date: Mon, 19 Apr 2021 22:49:55 +0200 In-Reply-To: <8335vmrux2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 Apr 2021 21:28:09 +0300") Message-ID: <87mttum230.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > I'd be interested to see a backtrace for such animation of an image > that is not on display. In general, since animation is triggered (I > think) when the image is being prepared for redisplay, wha [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I'd be interested to see a backtrace for such animation of an image > that is not on display. In general, since animation is triggered (I > think) when the image is being prepared for redisplay, what you > describe shouldn't be happening. If it dies indeed happen, I have a > couple of guesses how that could be triggered, but it would be nice to > see evidence. I unfortunately don't have the time to debug right now, but it's easy enough to reproduce: (progn (eww "https://lars.ingebrigtsen.no/wp-content/uploads/2018/03/candid.gif") (bury-buffer)) This will leave you with an Emacs that uses at least 99% CPU, even if the eww buffer isn't even displayed. (At least on this Debian/bullseye system, starting from -Q.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 22:25:05 2021 Received: (at 47895) by debbugs.gnu.org; 20 Apr 2021 02:25:05 +0000 Received: from localhost ([127.0.0.1]:52470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYg4X-0000oS-II for submit@debbugs.gnu.org; Mon, 19 Apr 2021 22:25:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYg4V-0000nw-KW for 47895@debbugs.gnu.org; Mon, 19 Apr 2021 22:25:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54469) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYg4Q-0004No-B4; Mon, 19 Apr 2021 22:24:58 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3824 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lYg4P-00049f-Pw; Mon, 19 Apr 2021 22:24:58 -0400 Date: Tue, 20 Apr 2021 05:24:43 +0300 Message-Id: <83zgxtr8us.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87mttum230.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 19 Apr 2021 22:49:55 +0200) Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Lars Ingebrigtsen > Cc: 47895@debbugs.gnu.org > Date: Mon, 19 Apr 2021 22:49:55 +0200 > > Eli Zaretskii writes: > > > I'd be interested to see a backtrace for such animation of an image > > that is not on display. In general, since animation is triggered (I > > think) when the image is being prepared for redisplay, what you > > describe shouldn't be happening. If it dies indeed happen, I have a > > couple of guesses how that could be triggered, but it would be nice to > > see evidence. > > I unfortunately don't have the time to debug right now, but it's easy > enough to reproduce: > > (progn > (eww "https://lars.ingebrigtsen.no/wp-content/uploads/2018/03/candid.gif") > (bury-buffer)) > > This will leave you with an Emacs that uses at least 99% CPU, even if > the eww buffer isn't even displayed. (At least on this Debian/bullseye > system, starting from -Q.) Thanks, I will take a look when I have time. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 20 09:51:34 2021 Received: (at 47895) by debbugs.gnu.org; 20 Apr 2021 13:51:34 +0000 Received: from localhost ([127.0.0.1]:53396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYqmr-0001lC-Q7 for submit@debbugs.gnu.org; Tue, 20 Apr 2021 09:51:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYqmq-0001ky-4Z for 47895@debbugs.gnu.org; Tue, 20 Apr 2021 09:51:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35285) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYqmj-0007R4-FF; Tue, 20 Apr 2021 09:51:26 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1948 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lYqmc-0004P4-0U; Tue, 20 Apr 2021 09:51:23 -0400 Date: Tue, 20 Apr 2021 16:51:02 +0300 Message-Id: <83r1j5qd2x.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87mttum230.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 19 Apr 2021 22:49:55 +0200) Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Lars Ingebrigtsen > Cc: 47895@debbugs.gnu.org > Date: Mon, 19 Apr 2021 22:49:55 +0200 > > (progn > (eww "https://lars.ingebrigtsen.no/wp-content/uploads/2018/03/candid.gif") > (bury-buffer)) The timer set up by image.el keeps "displaying" the animated GIF. In this simple case, we could use (get-buffer-window (plist-get (cdr image) :animate-buffer) 'visible) in image-animate-timeout to see if the buffer is displayed in any window. The harder questions are: . if the buffer is not displayed, what to do with the timer? continue running it? if so, how to interpret the LIMIT arg? . what if the window _is_ displayed, but the image is not visible? I think we'd need to record the image's buffer position in its plist, so that we could use pos-visible-in-window-p to find out whether the image is visible From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 25 14:48:59 2021 Received: (at 47895) by debbugs.gnu.org; 25 Apr 2021 18:48:59 +0000 Received: from localhost ([127.0.0.1]:43767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lajoQ-0004KD-Vx for submit@debbugs.gnu.org; Sun, 25 Apr 2021 14:48:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lajoP-0004K0-3F for 47895@debbugs.gnu.org; Sun, 25 Apr 2021 14:48:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2z0tA5r2xaCPnBGn37gaQWVz1uBLoqCqNXeW95JEfp4=; b=qMNDYs89i5Qn/+7jywnUnSpRun Eg/QBMSxzH2uQN3chcR4l69ya57hTX5Hd5quoUnQr5XGslWeAu1LXoNWkVg6xFs7FrfDjrEpl2NfY d14geGyrdxIJ7bWEeFmlYKe1ZhwvZyitDdb59KsVndDDmVOj+YD/Nhq/dsqTxuEt+2R4=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lajoF-00016e-K1; Sun, 25 Apr 2021 20:48:50 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX5+Prb1duro5+U bVBTOi////93TpsyAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UEGRE6G+DkQJYAAAGXSURBVDjLfZTh gYMgDIUT6AAJdgChHQCEAc7C/jNdAOlJz7v8QM3nywsIAgDBddhlvczjitdA/VVJ+epCyAgIbKWA XFskAgveGEVahYfZNJjDZIf/QjFaAvcbxOhiUPFEcACJFIt7N3m0m0pJMQvcBsF2h6nk1FTxLcEG pE6Jpcg41kH7Oi6xCBCSShiCLxnMs0ipKinlPS1XHcS7yCCVSqbD5SaCmpBCWdIV9CmoVcVaJDdN TtmOvnbVX+4iaetQgNe1m1xtWlt2gKBTqdkRAfkA+JOuFQMfYAdzFpTXocCA6pwveSiQcFJIrT4P y7NiAAesZ7A2gB4+FTsf+4rpeQVWYJ7NX1xXS1fw+OiXhkJdKKo5LxPYertBwP1cyHFTwEIzkKXq ACyzOQnksYNqzj23Sds13813kfaJvGiJGw8AHlu7+dlfngGnzCbzBTCR2X4A+cRIxFN0QLAaBcgr WGOconHAZbd7s8iH9GAdkgZ9BWS1Z3CTVf4Cez8DOQ/7osLiI2862NsARo6W/CYck2wXeLz/GN+7 NXyuvfdRQwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNC0yNVQxNzo1ODoyNyswMDowMFnHcGoA AAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDQtMjVUMTc6NTg6MjcrMDA6MDAomsjWAAAAAElFTkSu QmCC X-Now-Playing: Susumu Yokota's _Cloud Hidden_: "Direct Transmission" Date: Sun, 25 Apr 2021 20:48:47 +0200 In-Reply-To: <83r1j5qd2x.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Apr 2021 16:51:02 +0300") Message-ID: <87v98ajj3k.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > The timer set up by image.el keeps "displaying" the animated GIF. Yup. But if the image isn't displayed, why does this take any time? That is, the image.el code increases the :index in the image spec, and then calls force-window-update, and it's presumably this that [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > The timer set up by image.el keeps "displaying" the animated GIF. Yup. But if the image isn't displayed, why does this take any time? That is, the image.el code increases the :index in the image spec, and then calls force-window-update, and it's presumably this that takes time? Even if the image isn't displayed? I find that part rather unexpected. Hm... No, even without the force-update, Emacs uses 100% CPU. I've done some more testing, and even if image-animate-timeout just does: (plist-put (cdr image) :animate-tardiness (+ (* (plist-get (cdr image) :animate-tardiness) 0.9) (float-time (time-since target-time)))) and then re-runs itself, it'll use 100% CPU. This seems to indicate that any alteration of the image plist leads to Emacs re-computing the image -- even if it isn't displayed? Both of these things seem unexpected: 1) Altering a plist item that's not relevant for the display of the image shouldn't lead to an image recomputation, and 2) if the image isn't displayed, it shouldn't be recomputed anyway. I guess 1) is because the redisplay code can't find the image in the image cache -- because it has no concept of "this is an image-relevant plist item" -- it just computes a hash of all the properties. > In this simple case, we could use > > (get-buffer-window (plist-get (cdr image) :animate-buffer) 'visible) > > in image-animate-timeout to see if the buffer is displayed in any > window. The harder questions are: > > . if the buffer is not displayed, what to do with the timer? > continue running it? if so, how to interpret the LIMIT arg? I'd keep interpreting that the same -- that is, count down, even if the image isn't displayed. > . what if the window _is_ displayed, but the image is not visible? > I think we'd need to record the image's buffer position in its > plist, so that we could use pos-visible-in-window-p to find out > whether the image is visible Or just compute the position on each iteration -- the image may change its position if more text is inserted, for instance. But I'm still wondering about why this doesn't just work "automatically" -- if we could handle this in the redisplay code, that would be more natural. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 25 15:01:57 2021 Received: (at 47895) by debbugs.gnu.org; 25 Apr 2021 19:01:58 +0000 Received: from localhost ([127.0.0.1]:43827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lak0z-00061n-9d for submit@debbugs.gnu.org; Sun, 25 Apr 2021 15:01:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lak0x-0005x9-Ij for 47895@debbugs.gnu.org; Sun, 25 Apr 2021 15:01:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41577) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lak0s-0008A1-AJ; Sun, 25 Apr 2021 15:01:50 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4834 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lak0q-0008At-6g; Sun, 25 Apr 2021 15:01:49 -0400 Date: Sun, 25 Apr 2021 22:01:28 +0300 Message-Id: <834kfukx2v.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87v98ajj3k.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 25 Apr 2021 20:48:47 +0200) Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 47895@debbugs.gnu.org > Date: Sun, 25 Apr 2021 20:48:47 +0200 > > Hm... No, even without the force-update, Emacs uses 100% CPU. Beware: changing that might make the timer run more frequently, so you might see CPU usage soar even though Emacs does almost nothing. > (plist-put (cdr image) :animate-tardiness > (+ (* (plist-get (cdr image) :animate-tardiness) 0.9) > (float-time (time-since target-time)))) > > and then re-runs itself, it'll use 100% CPU. This seems to indicate > that any alteration of the image plist leads to Emacs re-computing the > image -- even if it isn't displayed? Both of these things seem > unexpected: 1) Altering a plist item that's not relevant for the display of > the image shouldn't lead to an image recomputation, and 2) if the image > isn't displayed, it shouldn't be recomputed anyway. We access a different frame of the GIF image, so that would mean regenerating the pixmap for the image, no? > > In this simple case, we could use > > > > (get-buffer-window (plist-get (cdr image) :animate-buffer) 'visible) > > > > in image-animate-timeout to see if the buffer is displayed in any > > window. The harder questions are: > > > > . if the buffer is not displayed, what to do with the timer? > > continue running it? if so, how to interpret the LIMIT arg? > > I'd keep interpreting that the same -- that is, count down, even if the > image isn't displayed. But then if and when the image becomes visible, it won't show the animation, because it already reached the LIMIT. Right? > > . what if the window _is_ displayed, but the image is not visible? > > I think we'd need to record the image's buffer position in its > > plist, so that we could use pos-visible-in-window-p to find out > > whether the image is visible > > Or just compute the position on each iteration -- the image may change > its position if more text is inserted, for instance. Sure, but even if the position doesn't change we currently cannot tell if the image is visible. We have pos-visible-in-window-p, but that needs a buffer position -- which is why I suggest to record that position in the image. > But I'm still wondering about why this doesn't just work > "automatically" -- if we could handle this in the redisplay code, that > would be more natural. Animation doesn't work in redisplay, it works in this code I pointed to. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 25 15:08:07 2021 Received: (at 47895) by debbugs.gnu.org; 25 Apr 2021 19:08:07 +0000 Received: from localhost ([127.0.0.1]:43848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lak6w-0006zV-UL for submit@debbugs.gnu.org; Sun, 25 Apr 2021 15:08:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lak6u-0006z2-Tk for 47895@debbugs.gnu.org; Sun, 25 Apr 2021 15:08:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NTiMXSxu6l4TVtRpkOsZtckw0mPOBH69kSn9eqyS6zQ=; b=UpxxMTPTK0qQiiCTH+prLd28zK OzBmWkymGRz/z/uDqdus/wGENgJsa/N0aqfAjd8dP5ZLS0mvaO3VrEs8TtVSJLzAdreiSBkH776Nn l2vUVohi7du7CbOY6HZIARnWMq/EGuSnhwjesu4OuQXRm8wXJOuJUeYiLv1pI8Jn1pVU=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lak6f-0001HN-Ev; Sun, 25 Apr 2021 21:07:59 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> <834kfukx2v.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEU1NimsbSbEmhh+ hYb////81lOLAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UEGRMAB9LIFs4AAAGwSURBVDjLbVRRlsQg CIN6AbAXEE7QLve/2wbUvuns+uGoMQRCHSIlcnch+hmHGVF3FnYsAJAqgE6HOTZ+DHYseh4S55QM VeMCpAsJuY68OzAjKkINTLjesct7llzDJlGIKADVwd26e2VyIFSJsObBkAk4blJepYw/M/M9kAoO BqIm+gK6Idc+skSMHWwCUgdYVs4LEKSSxbNrGbOjkRzORusm1Y0dyssTpA4Gpv4BlGxS7HjSQqgS n8GteJshC+BMYimka51egx/GUmixAaHo5XMOPe973qiOtV6Zi7IqyjPdcu32KsAAJBsm9LIBDZ55 VtmC3jmXL6w8ATGFlw3oT+Wq7VqAnrNNZ2gBGSqwHhSpGtIiijM1spSW54Fq4t6Vr+JmVOKI8nH6 EXFtANT7IdAtdH3YBcraxxlXK5nlyuNfAwCd8rE9YfMngWsB8cS8Ekzgsy3r0QA6X/1SigQ+pTcD xTMF/R3LFv0HkJl7e/d+MvLprP22htJ7NFx3rCcJS0J2XL408GkE9W7Gf8TrwwTxi1JfE16uylfG Ws9Vqs5vkTwE73qfc2rg70H17dYv17c8bOqLIYAAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDQt MjVUMTk6MDA6MDcrMDA6MDCDhJcRAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA0LTI1VDE5OjAw OjA3KzAwOjAw8tkvrQAAAABJRU5ErkJggg== X-Now-Playing: Octo Octa's _Resonant Body_: "Ecstatic Beat" Date: Sun, 25 Apr 2021 21:07:48 +0200 In-Reply-To: <834kfukx2v.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Apr 2021 22:01:28 +0300") Message-ID: <87bla2ji7v.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> Hm... No, even without the force-update, Emacs uses 100% CPU. > > Beware: changing that might make the timer run more frequently, so you > might see CPU usage soar even though Emacs does almost not [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Hm... No, even without the force-update, Emacs uses 100% CPU. > > Beware: changing that might make the timer run more frequently, so you > might see CPU usage soar even though Emacs does almost nothing. It's still updating at the same rate (25 times a second for the image in question). > We access a different frame of the GIF image, so that would mean > regenerating the pixmap for the image, no? It does, but why does that happen before redisplay has decided to display the image? >> I'd keep interpreting that the same -- that is, count down, even if the >> image isn't displayed. > > But then if and when the image becomes visible, it won't show the > animation, because it already reached the LIMIT. Right? Yes. I think that's fine -- you've asked for X repetitions, and you get X repetitions, whether it's shown or not. >> Or just compute the position on each iteration -- the image may change >> its position if more text is inserted, for instance. > > Sure, but even if the position doesn't change we currently cannot tell > if the image is visible. We have pos-visible-in-window-p, but that > needs a buffer position -- which is why I suggest to record that > position in the image. Sure. Could make it a marker, I guess. >> But I'm still wondering about why this doesn't just work >> "automatically" -- if we could handle this in the redisplay code, that >> would be more natural. > > Animation doesn't work in redisplay, it works in this code I pointed > to. The code just alters some elements in the image plist. It's unexpected that this should lead to Emacs doing a lot of work -- unless it's actually displaying the image. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 11:51:19 2021 Received: (at 47895) by debbugs.gnu.org; 27 Apr 2021 15:51:19 +0000 Received: from localhost ([127.0.0.1]:50639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbPzb-0006Nw-E3 for submit@debbugs.gnu.org; Tue, 27 Apr 2021 11:51:19 -0400 Received: from outbound.soverin.net ([116.202.65.218]:48303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbPzW-0006Ne-Kj for 47895@debbugs.gnu.org; Tue, 27 Apr 2021 11:51:18 -0400 Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 5A763601B7; Tue, 27 Apr 2021 15:51:08 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1619538667; bh=gLtG4r1BN8gmXEQYTt/4D15izwlkbKDyrLciTi0RqWQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=E5EVIA3ot6s7D4OyTpH7SlEBoSCRG1pmgoBu/0HNix3c2O7UQNJuvu4/zIrxi1BLC QDP09GSVV5ixc9EnNCGen6IhWm9lzHx3QVqPOGRW9ILXOmsJzdCIKWZ5rUWPD/tRpX KgLtOz6sO3PLFE5QSDjbdz9jX145fFlq5cbTdfLny3e/Dpki7mhLGKfjwYd+wYaab5 J355AFpDRxbL9v3pCYGT4yC/sQATmV5iCC2GPTLda/8Hw1AJwamEKSDot0ypFXtDNd w6T9UmJ2eHVALpVfSA5TQDnq6yE7xXAnsqTFY5Iumz2UHXTnUOK5TbZqL+dYKQd/Qz pDmF4nu7T2F5Q== Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94) (envelope-from ) id 1lbPzM-0002fG-VJ; Tue, 27 Apr 2021 16:51:04 +0100 Date: Tue, 27 Apr 2021 16:51:04 +0100 From: Alan Third To: Lars Ingebrigtsen , Eli Zaretskii , 47895@debbugs.gnu.org Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible Message-ID: Mail-Followup-To: Alan Third , Lars Ingebrigtsen , Eli Zaretskii , 47895@debbugs.gnu.org References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> <834kfukx2v.fsf@gnu.org> <87bla2ji7v.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47895 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) (I don't think this sent originally, apologies if it shows up twice.) On Sun, Apr 25, 2021 at 09:07:48PM +0200, Lars Ingebrigtsen wrote: > > The code just alters some elements in the image plist. It's unexpected > that this should lead to Emacs doing a lot of work -- unless it's > actually displaying the image. Since the image is being loaded whether it's displayed or not it may be worth checking if it's also being flushed from the cache every time through the animation. If so the high CPU usage is presumably due to Emacs having to reload the frame every time. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 19:24:07 2021 Received: (at 47895) by debbugs.gnu.org; 27 Apr 2021 23:24:07 +0000 Received: from localhost ([127.0.0.1]:51265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbX3n-0002u0-2W for submit@debbugs.gnu.org; Tue, 27 Apr 2021 19:24:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbX3k-0002tU-MK for 47895@debbugs.gnu.org; Tue, 27 Apr 2021 19:24:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OdZA0rx6fhkmNm456/soTZbPNQuZzQY6vWPuVhvoHnc=; b=ac9DlmcApxHQJi7o7kGcFPDCEl hVrn7jaGg3Va0mTXQizOqPqtlEgvz/KmgrzHogR59dIqLi7XXSKaS9dKKIzV2/UYnKPZ+r8nW82UD LmZ4DO1WmCMopUNYHgp+nmkgiF7TYaOLGyrWYs0yY34YAFf4yVZu0+wbErTRUfqTP6dU=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbX3c-0004dX-2v; Wed, 28 Apr 2021 01:23:58 +0200 From: Lars Ingebrigtsen To: Alan Third Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> <834kfukx2v.fsf@gnu.org> <87bla2ji7v.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUNDA0fHx0vLy5L S0ohIB5AQD9APz3///9zk+3GAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UEGxcRGk8XOVAAAADMSURB VDjLzdJRDoMgDAbgVs2eaXYBKR5AqQdQzA6w+19mqJlOCw9LzLI/MZh+UhAFuDQmXqjLtuwlABet 3C1P9Q5u8hF82UnZ86PdAbdW690/pbIZcDIk6yhSJ6EQeeagT8LN87y6PhLkpajBBBzAoAZwhEAJ QAkGiDQEz4Az0LmTt2lgbxbAM4RlIQ3IzRgHmu0IDddJgOVrxNfQ/x1BJuYwfGTMwVpJneIK25z3 Luj8+L69ASpIQq77LyMizkmngZmDOPt9x+sST+oF+ewRqQv+VL8AAAAldEVYdGRhdGU6Y3JlYXRl ADIwMjEtMDQtMjdUMjM6MTc6MjYrMDA6MDCFGjn/AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA0 LTI3VDIzOjE3OjI2KzAwOjAw9EeBQwAAAABJRU5ErkJggg== X-Now-Playing: Lori Carson's _Where It Goes_: "Down Here" Date: Wed, 28 Apr 2021 01:23:55 +0200 In-Reply-To: (Alan Third's message of "Tue, 27 Apr 2021 16:51:04 +0100") Message-ID: <87r1ivz4z8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Alan Third writes: > Since the image is being loaded whether it's displayed or not it may > be worth checking if it's also being flushed from the cache every time > through the animation. If so the high CPU usage is pre [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47895 Cc: Eli Zaretskii , 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Third writes: > Since the image is being loaded whether it's displayed or not it may > be worth checking if it's also being flushed from the cache every time > through the animation. If so the high CPU usage is presumably due to > Emacs having to reload the frame every time. Yup; should also be checked. (I introduced a separate cache for this in the ImageMagick case many years ago, but the non-ImageMagick one doesn't have an animation cache, if I remember correctly.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 05:35:55 2021 Received: (at 47895) by debbugs.gnu.org; 2 May 2021 09:35:56 +0000 Received: from localhost ([127.0.0.1]:41838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld8W3-000721-Mr for submit@debbugs.gnu.org; Sun, 02 May 2021 05:35:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld8W1-00071u-Ui for 47895@debbugs.gnu.org; Sun, 02 May 2021 05:35:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58489) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ld8Vw-0004z1-MH; Sun, 02 May 2021 05:35:48 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3194 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ld8Vv-0007nV-TT; Sun, 02 May 2021 05:35:48 -0400 Date: Sun, 02 May 2021 12:35:28 +0300 Message-Id: <83zgxd7a1r.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87bla2ji7v.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 25 Apr 2021 21:07:48 +0200) Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> <834kfukx2v.fsf@gnu.org> <87bla2ji7v.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 47895@debbugs.gnu.org > Date: Sun, 25 Apr 2021 21:07:48 +0200 > > > We access a different frame of the GIF image, so that would mean > > regenerating the pixmap for the image, no? > > It does, but why does that happen before redisplay has decided to > display the image? Because image-animate-timeout calls image-metadata (via image-multi-frame-p), which calls lookup_image, which regenerates the pixmap. > >> I'd keep interpreting that the same -- that is, count down, even if the > >> image isn't displayed. > > > > But then if and when the image becomes visible, it won't show the > > animation, because it already reached the LIMIT. Right? > > Yes. I think that's fine -- you've asked for X repetitions, and you get > X repetitions, whether it's shown or not. But no repetitions were actually displayed yet, so won't this be confusing? Shouldn't we start counting only when the image is actually visible? > > Animation doesn't work in redisplay, it works in this code I pointed > > to. > > The code just alters some elements in the image plist. It's unexpected > that this should lead to Emacs doing a lot of work -- unless it's > actually displaying the image. It's computing the image, see above. From debbugs-submit-bounces@debbugs.gnu.org Mon May 03 05:53:05 2021 Received: (at 47895) by debbugs.gnu.org; 3 May 2021 09:53:05 +0000 Received: from localhost ([127.0.0.1]:46246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldVGD-000447-Ky for submit@debbugs.gnu.org; Mon, 03 May 2021 05:53:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldVGA-00043f-8S for 47895@debbugs.gnu.org; Mon, 03 May 2021 05:53:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TdlP1thL6OuKoVcv+H6gPN4pCrxBkJ7jNxh3MNL0bL4=; b=WJYDfjptwqZhB1ISbVPgndSmNO V7G4+aj3GqKeFdhXHJ8bxA4DlTGH0Y8oXcpspnFQ2mCqUvJFw2NKfkKScUwST/NhGTekGdHW8g9gx zkC7/je1rqCeM2n7vN9Z4q0Cnm8YM3tQph5XzLZ/2ftIrR9F0P3xPdCtP5bX2yqZkXlc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldVG1-0003XU-34; Mon, 03 May 2021 11:52:55 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#47895: 28.0.50; Emacs should only animate images that are visible References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> <87v98ajj3k.fsf@gnus.org> <834kfukx2v.fsf@gnu.org> <87bla2ji7v.fsf@gnus.org> <83zgxd7a1r.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWqVytOIgrOokbH p6j///8RjwGeAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UFAwkROsoMwSIAAAF7SURBVDjLfZOLrcMw CEWBLADuAsQTpMr+uz2+jlupz0qjxsdcvgb4Z7H9SLU+Ziz7JyL2AXOe4osREqB/0UR7AthJO93A jihLAVNGl/ITDmQtDikCDdFSElYskFEo5LYME32ATsAWQhgbINwdbFIekhvhN3AD0srpG5SbT+BZ aKVOYw/XNqG9u9ECp22YZ3RXLvck6IW0tNsKIItsFh6Uy4CXn8qCDYyJIIQZ4UigXv1omZfaAQfQ zMCz5+t4ywIny33c/lx8vzaAjMdx3a/jevP16kbSavy+2MdFhXmNEuXYWBBWZo7JOkAJLoCrtLKP 8NjADsKbb3HPXQB7JUmAD8DurAM8Gyh7tRnkGyAE6P5FdUeCjmQb0vBhQ7mnzt7BAKgfwIZvlgXv xfIoCkzzWJWrAwm068BElXb42ArEHV5Y6AKmVJIPyHGGrKDPxw6QKGY4LkKDuEoMcYFGgaWETKeH NdtCNRohKuqzywWyQXbsHBiGo8GP9RP8AddDTNzcWU0jAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIx LTA1LTAzVDA5OjE3OjU4KzAwOjAw0z61KAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNS0wM1Qw OToxNzo1OCswMDowMKJjDZQAAAAASUVORK5CYII= X-Now-Playing: Sector 27's _Sector 27 Complete_: "Total Recall" Date: Mon, 03 May 2021 11:52:52 +0200 In-Reply-To: <83zgxd7a1r.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 02 May 2021 12:35:28 +0300") Message-ID: <87bl9scfez.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Because image-animate-timeout calls image-metadata (via > image-multi-frame-p), which calls lookup_image, which regenerates the > pixmap. Aah! Thanks; image.el doesn't have to keep calling that function -- it can just call it once and then stash the data in the image plist. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47895 Cc: 47895@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Because image-animate-timeout calls image-metadata (via > image-multi-frame-p), which calls lookup_image, which regenerates the > pixmap. Aah! Thanks; image.el doesn't have to keep calling that function -- it can just call it once and then stash the data in the image plist. I've now done that change on the trunk, and my test case went from using 100% CPU to using 7% CPU, which is an improvement. :-) Virtually all of the remaining CPU usage comes from the call to `force-window-update' -- and I guess that shouldn't be called if the buffer isn't displayed in a window. Let's see... Yup, with that change, the CPU usage went down to 2%. So I think that this problem is now fixed, and I'm closing this bug report. > But no repetitions were actually displayed yet, so won't this be > confusing? Shouldn't we start counting only when the image is > actually visible? I don't really have an opinion here -- but the image animation code hasn't taken this into consideration before, so that would be a change in behaviour. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon May 03 05:53:12 2021 Received: (at control) by debbugs.gnu.org; 3 May 2021 09:53:12 +0000 Received: from localhost ([127.0.0.1]:46249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldVGJ-00044J-TA for submit@debbugs.gnu.org; Mon, 03 May 2021 05:53:12 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldVGI-000446-BM for control@debbugs.gnu.org; Mon, 03 May 2021 05:53:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VyzRlESE0uz1XE2HxGQ3Q30gNfeljrd2loqKn0FdIKA=; b=Ljo4uR+AaFNb0MYhfqM5iy0vVC eKVKzc4aWFJND1u1hOiyyFM+KW1ZcudNlGU66dMPdYDkgjt5IupOmb9g3oV2Xlwmskgrsh8CbP4ah wYWWy9M3esEUxCJj0Tn9ZzLSy4uYvwRFc6TNl1eezJwJ0yursCC927QPLUXLE1CO1E8o=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldVGA-0003Xg-QD for control@debbugs.gnu.org; Mon, 03 May 2021 11:53:04 +0200 Date: Mon, 03 May 2021 11:53:02 +0200 Message-Id: <87a6pccfep.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #47895 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 47895 fixed close 47895 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 47895 fixed close 47895 28.1 quit From unknown Mon Jun 23 16:45:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 31 May 2021 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator