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#45224: 28.0.50; eww and GIFS (cpu usage shoots through the roof) Date: Sun, 31 Oct 2021 16:10:29 +0100 Message-ID: <87pmrlnsbe.fsf@gnus.org> References: <87r1ntnabo.fsf@gmail.com> <87eejsz5aw.fsf@gnus.org> <87lfe0fbuv.fsf@gmail.com> <877dpkfbf9.fsf@gmail.com> <874kkn39t3.fsf@gnus.org> <87h7ojlage.fsf@gmail.com> <87h7ojjvhd.fsf@gnus.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="24476"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Madhavan Krishnan , 45224@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 31 16:11:12 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 1mhCUJ-0006Bl-8v for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Oct 2021 16:11:11 +0100 Original-Received: from localhost ([::1]:56990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhCUH-0000Js-TQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Oct 2021 11:11:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhCUA-0000JT-Gq for bug-gnu-emacs@gnu.org; Sun, 31 Oct 2021 11:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49498) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhCUA-0002bA-7t for bug-gnu-emacs@gnu.org; Sun, 31 Oct 2021 11:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mhCUA-0007ZG-3A for bug-gnu-emacs@gnu.org; Sun, 31 Oct 2021 11:11: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, 31 Oct 2021 15:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45224 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 45224-submit@debbugs.gnu.org id=B45224.163569304129063 (code B ref 45224); Sun, 31 Oct 2021 15:11:02 +0000 Original-Received: (at 45224) by debbugs.gnu.org; 31 Oct 2021 15:10:41 +0000 Original-Received: from localhost ([127.0.0.1]:32811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhCTo-0007Yg-Lg for submit@debbugs.gnu.org; Sun, 31 Oct 2021 11:10:40 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:39472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhCTn-0007YS-2f for 45224@debbugs.gnu.org; Sun, 31 Oct 2021 11:10:39 -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=DtdhFE7aQBOwSWKqJ8/wUnz56w2vV9Pc8ceUQi1UQ94=; b=QGzoPjaZHrdQDZ4UhdcYzBHN2A XGLlscXpDJPuhkJz6/0N5x7jl338udsdZ6zSyK2C+q8Flls4yFiz04gisfV7FnWlyYrs0LBvezlcn Edw6szm10NwND3mtykpUqkXPL+J2mUNgGPepsoLsBdVcdp77woo0ejkkkGTKl460BRhc=; Original-Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhCTd-0004Fi-LR; Sun, 31 Oct 2021 16:10:32 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEU8Y0FJhztjl1Jo mlKDqW6mwZH///+tjQ/pAAAAAWJLR0QGYWa4fQAAAAd0SU1FB+UKHw4lKvFBS8IAAAGiSURBVDjL dZTrccQwCITlTAowuIETbiABdyBXkP6LyS6SH7m7KD/Osx+wgDQp5TwiukYVETOrlzxRiTATq3oB ymIOQPUClEUDx0WZ9LjiEeYrgKnqCSQBdZpUnQdIA1SgR5gD6ONMQKFlZJjKBSoTDgD01UHVKqad wAPfj26hHEJTd0d6TfOJBlxDejsyFhcAyV1oPZqytXz+sNDcp2ZldwvMZ4ubH+vgGixWFrKFQalr OkQuhM1xhR9FZraBffhq6MloZueeOJ2hMqNxKd/o9bBAee9TA/jIQF3cBa8vKsffDqAjkJeRv2iv ZgYuu+s04Wbon+PVcIahrwTgkYATZ8qa/lvgL0v5sUEOohZ726J35ZRpUtnUvu+RgKvt+pBbEOCe 2MiWOSiytw4wCaoiMCKjs85GMOEp760hKtUW3a4Iy7DOCM7TAMbn6OU8HWwZvt30sARtdHJLUIKt 7fF0XEpavZwqJd6e/8D6b4a8B3h+74FXmctLKB/TEzCZ8c5mXlG5AG5PIOaLmvh716U8gy6/gHzL fwA/jP8+VOUGYF/KLwhdnHdfNotSAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTEwLTMxVDE0OjM3 OjQyKzAwOjAwtnwaKgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0xMC0zMVQxNDozNzo0MiswMDow MMchopYAAAAASUVORK5CYII= X-Now-Playing: Oval's _94diskont_: "Cross Selling" In-Reply-To: (Stefan Kangas's message of "Sat, 30 Oct 2021 18:50:19 -0700") 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:218693 Archived-At: Stefan Kangas writes: > The value of :animate-tardiness is updated in image.el on every > iteration. When image.el updates :animate-tardiness, it will never be > equal to something in the cache and we always get a cache miss! Ahh! Yes, this has bit us before, I think (with image.el changing the plist triggering recalculation unnecessarily. Uhm... 4aa4a8f9 for instance. > Option A) seems ugly to me: why would we be consing up Lisp lists on > such a low level, which also makes me worry about creating a lot of > unnecessary garbage. So I prefer Option B). Yes, me too. > The struct also seems more clean to me. Perhaps there are some > performance implications I'm not thinking of? Or perhaps there is > some even better way to do the cache check than a struct, such as > using the "image struct" directly? The problem is that it's not well-defined which elements in the plist really affect display and which ones don't. If you change :max-width of an image plist, then it should definitely affect display, but if you change :gazonk, then it shouldn't. So perhaps we should just document which elements that affect display, and put those fields into the struct? (And then use the struct instead of the plist for caching.) That way, if somebody adds a new field that affects display, then they know to also update the struct. > A third alternative is to somehow change image.el to put this > information outside the image specifier, but that leaves unfixed a > rather subtle issue with caching. That issue may or may not bite > someone later. That would be a simpler solution -- image.el could easily just use a hash table to keep track of the data. But as you say, people will trip over this elsewhere, too, because stashing data in the plist seems like such an obvious thing to do. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no