From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#47895: 28.0.50; Emacs should only animate images that are visible Date: Sun, 25 Apr 2021 20:48:47 +0200 Message-ID: <87v98ajj3k.fsf@gnus.org> References: <87r1j6m920.fsf@gnus.org> <8335vmrux2.fsf@gnu.org> <87mttum230.fsf@gnus.org> <83r1j5qd2x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15058"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 47895@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 25 20:49:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lajoc-0003mK-69 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Apr 2021 20:49:10 +0200 Original-Received: from localhost ([::1]:38416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lajob-0005Gw-2R for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Apr 2021 14:49:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lajoU-0005Ge-9m for bug-gnu-emacs@gnu.org; Sun, 25 Apr 2021 14:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60454) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lajoU-00007r-2x for bug-gnu-emacs@gnu.org; Sun, 25 Apr 2021 14:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lajoU-0004KU-0A for bug-gnu-emacs@gnu.org; Sun, 25 Apr 2021 14:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Apr 2021 18:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47895 X-GNU-PR-Package: emacs Original-Received: via spool by 47895-submit@debbugs.gnu.org id=B47895.161937653916634 (code B ref 47895); Sun, 25 Apr 2021 18:49:01 +0000 Original-Received: (at 47895) by debbugs.gnu.org; 25 Apr 2021 18:48:59 +0000 Original-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 Original-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=; Original-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 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" In-Reply-To: <83r1j5qd2x.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Apr 2021 16:51:02 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204905 Archived-At: 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