From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68006: 30.0.50; Image-mode speed Date: Mon, 01 Jan 2024 11:10:33 +0100 Message-ID: <87v88d9xeu.fsf@ledu-giraud.fr> References: <87le9jlfd6.fsf@ledu-giraud.fr> <83wmt3bkla.fsf@gnu.org> <87h6k6lgdy.fsf@ledu-giraud.fr> <83wmt29zfy.fsf@gnu.org> <87il4m6rcx.fsf@ledu-giraud.fr> <83bkae9j11.fsf@gnu.org> <87bkadyqdk.fsf@ledu-giraud.fr> <8334voanr1.fsf@gnu.org> <877cl0zvln.fsf@ledu-giraud.fr> <83y1dg954u.fsf@gnu.org> <87zfxvalnq.fsf@ledu-giraud.fr> <83o7eb938y.fsf@gnu.org> <87wmsxmff3.fsf@ledu-giraud.fr> <83mstt5hrk.fsf@gnu.org> <87frzjvpb5.fsf@ledu-giraud.fr> Reply-To: Manuel Giraud Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36427"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 68006@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 01 11:13:34 2024 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 1rKFIb-0009Gk-2D for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Jan 2024 11:13:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKFGA-0007YP-0r; Mon, 01 Jan 2024 05:11:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rKFG8-0007X9-Nc for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 05:11:00 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rKFG8-0000ww-E1 for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 05:11:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rKFG9-0004Qj-P4 for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 05:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jan 2024 10:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68006 X-GNU-PR-Package: emacs Original-Received: via spool by 68006-submit@debbugs.gnu.org id=B68006.170410385317014 (code B ref 68006); Mon, 01 Jan 2024 10:11:01 +0000 Original-Received: (at 68006) by debbugs.gnu.org; 1 Jan 2024 10:10:53 +0000 Original-Received: from localhost ([127.0.0.1]:47356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKFG1-0004QL-CL for submit@debbugs.gnu.org; Mon, 01 Jan 2024 05:10:53 -0500 Original-Received: from ledu-giraud.fr ([51.159.28.247]:11436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKFFq-0004Q2-97 for 68006@debbugs.gnu.org; Mon, 01 Jan 2024 05:10:51 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=a2pQJcJC ZLcLwdW6shhocNHhobDucvQJs8XtWzqCJ9M=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=nfaT3TXt1vIbga6TjvR9XRlD5tUYQZ 7PvW0HvnOI2EhMnRyjXuIa+P2ywp1ip5lhGaYnP06jYtfz3wV00lE6DA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=a2pQJcJCZLcLwdW6 shhocNHhobDucvQJs8XtWzqCJ9M=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=AW1PiLGYH9H16JK3PnEgP3iZjcqhufpdCdg1Qo +N7dmqS8UHr5PX5QtPj6gBm5kZ1iDqH/k6PegUQLU1lascH2qnI5d2mMzuTAKIN6VaXnIT X3PZkq3QxnbEBGxM4rNenzdMQtxI7/DVLwjBFmF9OPETEM/nh3Rr46dFxrDkxyQzkEwANC dYD7/QM85RrUAtaOB8v3beTqjyMdaz59MwbpkqbSEgpCpJBa6ama3u1rK5gBH/2AYavJxB Lc1+9KtjFudm5AdJKzsgFMj3u6DJr8/VcxD0hdO+yLakiSvGhVtnodZS0sfYAirbEhHEXW nVJwHs7DImN3g1uKHx/6+vGA== Original-Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 06749aab (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 1 Jan 2024 11:10:38 +0100 (CET) In-Reply-To: (Stefan Kangas's message of "Sat, 30 Dec 2023 15:57:28 -0800") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277172 Archived-At: Stefan Kangas writes: > Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> And here is a new version of the patch. Maybe, we need a NEWS entry for >> this too. > > If we have an option, then yes we should add it to NEWS too. > > But I'm not sure about this one: > > Flushing the image cache all the time is fine for images that are 4KB in > size, but these days we routinely work with images that are several > megabytes in size (to give an idea, searching online tells me that > Twitter allows uploading photos up to 2 MB, Facebook up to 15 MB). Hi Stefan, First, I want to say that here we're just talking about image-mode (and its derivatives like docview) and how the image cache is managed in this mode only. "Flushing the image cache all the time" is what is done *now* in image-mode. In fact, this new option permits to inhibit it. > Furthermore, my experience with image-dired has taught me that Emacs is > terribly slow when compared to all other programs capable of viewing > images out there. So I think we should think a bit more about this > one. Yes and this slowness was what I wanted to speed up in the first place in image-mode: moving from one image to the next is slower than any other program. I know that working on the image cache is picking a low-hanging fruit here but I'm not an expert in fast image processing. > Taking a step back, why are images treated differently from other > buffers? If the risk is that the image changes on disk without us > noticing, then users should need to either run `revert-buffer' or enable > `auto-revert-mode'. If we are talking about images that are inline in a > buffer, the cache should be flushed only when the buffer itself is > reverted. What am I missing? I guess that makes sense but would it be easy to plug the 'revert-buffer' machinery into the image cache internals? I don't know. > Lastly, I'm not sure about the "hash the first 4 KB of an image" > heuristic, for starters because images can be several megabytes in size. > Would it not be both more accurate and faster to check the mtime and/or > the size of the file? Or do we need different heuristic for different > image formats? (Maybe JPEG changes the first 4 KB on save, but I don't > think all bitmap formats do.) But wouldn't it be even better to use the > notify system when possible, like with `auto-revert-use-notify'? You're right that this heuristic might not be the best one. I repurposed it from image-dired when Eli suggested something content based. Maybe we could have a modification time of the image into its spec and compare it to said image file before display. Best regards, -- Manuel Giraud