Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 6 Jan 2024 13:07:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 06 08:07:50 2024
Received: from localhost ([127.0.0.1]:58796 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rM6Oz-00052A-RG
for submit <at> debbugs.gnu.org; Sat, 06 Jan 2024 08:07:50 -0500
Received: from ledu-giraud.fr ([51.159.28.247]:37099)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rM6Ow-000520-CO
for 68006 <at> debbugs.gnu.org; Sat, 06 Jan 2024 08:07:48 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=1IfwkwgZ
VJETuKGxa8APc0L9Q2tMahpnURz3xcU8IOo=;
h=date:references:in-reply-to:
subject:cc:to:from; d=ledu-giraud.fr; b=k3VUWy7LVxjIJ6mhojOeC5zf/+8R0B
ihiuUiyENdf5Ri8vWBZkie9d4+lRAXU4om3aG6mtRq9IIIDP7ywJKnDw==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=1IfwkwgZVJETuKGx
a8APc0L9Q2tMahpnURz3xcU8IOo=;
h=date:references:in-reply-to:subject:
cc:to:from; d=ledu-giraud.fr; b=bLGtgFfjWmRm3m/fB8oWzNGAtOdJoaRRKEiBFJ
35UzuCLeasunOG6Xx8FN7GSpgX+VC7PUznxLzwiRUbne1E6HQvG+mJixgor8mo9BVWbpgF
+GlAgs6x1zeD6Y38XFnoSMtceL5natiuRCUQaTyiVAWPEpXLrVGvmmZ4ZuYS4RTCpbZ05O
RVeXkIbc3dPp4l7vABXytTPb6JZCb1yTwvGCORBGQ2nwnMiHjrHqsLc6mJQDtfYvwDcZOj
hzJmI1rSwxo3/R0/r5YGuNjdfQ3SF1f96UiFdR0pKZ9X1JUJoIiLssdYbEXFB/+A28cwvO
J3KAZmygA5plAvzpPt4IpuRQ==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 9842ea9d
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Sat, 6 Jan 2024 14:07:39 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
In-Reply-To: <83a5pjvo3s.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 05 Jan
2024 16:41:59 +0200")
References: <87le9jlfd6.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN>
<87frzjvpb5.fsf@HIDDEN>
<CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN>
<83le9a3kqs.fsf@HIDDEN>
<CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN>
<83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN>
<83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN>
<83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN>
<83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN>
<83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN>
<831qawvx7q.fsf@HIDDEN> <871qavhpxf.fsf@HIDDEN>
<83edevvqyj.fsf@HIDDEN> <87v887g85d.fsf@HIDDEN>
<83a5pjvo3s.fsf@HIDDEN>
Date: Sat, 06 Jan 2024 14:07:37 +0100
Message-ID: <87a5pid2zq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hi,
Here is a diff of where I'm headed to. 'user-image-cache' is not used
at all yet. I imagine that a user could fill it with a call to
'make-image-cache' (when it exists). Anyway, WDYT?
diff --git a/src/image.c b/src/image.c
index 252b83da992..27d564fb49c 100644
--- a/src/image.c
+++ b/src/image.c
@@ -2086,7 +2086,7 @@ image_alloc_image_color (struct frame *f, struct image *img,
Image Cache
***********************************************************************/
-static void cache_image (struct frame *f, struct image *img);
+static void cache_image (struct image_cache **pc, struct image *img);
/* Return a new, initialized image cache that is allocated from the
heap. Call free_image_cache to free an image cache. */
@@ -2103,15 +2103,14 @@ make_image_cache (void)
return c;
}
-/* Find an image matching SPEC in the cache, and return it. If no
+/* Find an image matching SPEC in the cache C, and return it. If no
image is found, return NULL. */
static struct image *
-search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash,
+search_image_cache (struct image_cache *c, Lisp_Object spec, EMACS_UINT hash,
unsigned long foreground, unsigned long background,
int font_size, char *font_family, bool ignore_colors)
{
struct image *img;
- struct image_cache *c = FRAME_IMAGE_CACHE (f);
int i = hash % IMAGE_CACHE_BUCKETS_SIZE;
if (!c) return NULL;
@@ -2185,12 +2184,13 @@ uncache_image (struct frame *f, Lisp_Object spec)
{
struct image *img;
EMACS_UINT hash = sxhash (filter_image_spec (spec));
+ struct image_cache *cache = FRAME_IMAGE_CACHE (f);
/* Because the background colors are based on the current face, we
can have multiple copies of an image with the same spec. We want
to remove them all to ensure the user doesn't see an old version
of the image when the face changes. */
- while ((img = search_image_cache (f, spec, hash, 0, 0, 0, NULL, true)))
+ while ((img = search_image_cache (cache, spec, hash, 0, 0, 0, NULL, true)))
{
free_image (f, img);
/* As display glyphs may still be referring to the image ID, we
@@ -3359,6 +3359,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
unsigned long background = face->background;
int font_size = face->font->pixel_size;
char *font_family = SSDATA (face->lface[LFACE_FAMILY_INDEX]);
+ struct image_cache *cache;
/* F must be a window-system frame, and SPEC must be a valid image
specification. */
@@ -3367,7 +3368,13 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
/* Look up SPEC in the hash table of the image cache. */
hash = sxhash (filter_image_spec (spec));
- img = search_image_cache (f, spec, hash, foreground, background,
+
+ if (!NILP (Vuser_image_cache))
+ cache = XUNTAG (Vuser_image_cache, Lisp_Vectorlike, struct image_cache);
+ else
+ cache = FRAME_IMAGE_CACHE (f);
+
+ img = search_image_cache (cache, spec, hash, foreground, background,
font_size, font_family, false);
if (img && img->load_failed_p)
{
@@ -3380,7 +3387,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
{
block_input ();
img = make_image (spec, hash);
- cache_image (f, img);
+ cache_image (&cache, img);
img->face_foreground = foreground;
img->face_background = background;
img->face_font_size = font_size;
@@ -3470,16 +3477,17 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
}
-/* Cache image IMG in the image cache of frame F. */
+/* Cache image IMG in the image cache C. */
static void
-cache_image (struct frame *f, struct image *img)
+cache_image (struct image_cache **pc, struct image *img)
{
- struct image_cache *c = FRAME_IMAGE_CACHE (f);
+ struct image_cache *c;
ptrdiff_t i;
- if (!c)
- c = FRAME_IMAGE_CACHE (f) = make_image_cache ();
+ if (!*pc)
+ *pc = make_image_cache ();
+ c = *pc;
/* Find a free slot in c->images. */
for (i = 0; i < c->used; ++i)
@@ -12975,6 +12983,10 @@ syms_of_image (void)
The function `clear-image-cache' disregards this variable. */);
Vimage_cache_eviction_delay = make_fixnum (300);
+
+ DEFVAR_LISP ("user-image-cache", Vuser_image_cache,
+ doc: /* TBD. */);
+ Vuser_image_cache = Qnil;
#ifdef HAVE_IMAGEMAGICK
DEFVAR_INT ("imagemagick-render-type", imagemagick_render_type,
doc: /* Integer indicating which ImageMagick rendering method to use.
--
Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 14:55:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 09:55:04 2024 Received: from localhost ([127.0.0.1]:56798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLlbE-0007zK-HI for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:55:04 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:9221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLlbB-0007y7-86 for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:55:02 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=THaElXIO sJQggPYma3lvsEnJ12P/nH4YPJD5VronHaI=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=d6Ik42VnoGZPySEwVGzCV/B4Kvd/5Q GLeK+po2hHLzpBIc45oTR4g8+Qe0YkGMJrZwL7J0Fz+CKGUKF61RmuCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=THaElXIOsJQggPYm a3lvsEnJ12P/nH4YPJD5VronHaI=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=x+TeTaHmju5z5HaHeke0dQU16vBIfDImIp4W6t qN9L826bAhhSnCJlSwgtuh/oiLfgm7C/Vgkx2iOsdUfEvCdCltRFAz0oVe2q1aMxrFvLqs cT4nJq585tu4GHMIhi2wqFzSUAZfoeP1nAkEr4SST2QLE56Nv6OWydO1O+N/ximlDsl2Ey N4GAtm9+D+p8y5AIquE6hmr+LcXnl21w8kDD6OdXOXzpH4ODcEacASpR6661azlYbe9WE8 Xm0Hfe0MGHOpkGLDMZoIiA08h0Q6vc5BLrj9B8dFNOv9navyI6VIib7NbcO1z7sbxDkpAA 2uJZE7A5n+JJ8SiIap9dCVTA== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 2022d30c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 5 Jan 2024 15:54:54 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83a5pjvo3s.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 05 Jan 2024 16:41:59 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> <831qawvx7q.fsf@HIDDEN> <871qavhpxf.fsf@HIDDEN> <83edevvqyj.fsf@HIDDEN> <87v887g85d.fsf@HIDDEN> <83a5pjvo3s.fsf@HIDDEN> Date: Fri, 05 Jan 2024 15:54:53 +0100 Message-ID: <87r0ivg79e.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Manuel Giraud <manuel@HIDDEN> >> Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org >> Date: Fri, 05 Jan 2024 15:35:42 +0100 >> >> I also imagine it would be mostly in C. But looking at the code, I >> think I have overlooked something: lookup_image is what currently does >> most of the work (with caching) and this is in called in many places in >> "xdisp.c". Of course, I think we should keep that... but then how could >> we design this new cache? > > For example, lookup_image could look in both the existing and this new > cache. Yes why not. So your idea is to have just one more other cache that we can access differently than the current one. I was thinking more of something to let Lisp programs create their own image cache but that may be less practical. -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 14:42:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 09:42:26 2024 Received: from localhost ([127.0.0.1]:56734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLlP0-0004wg-K3 for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:42:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLlOw-0004wR-OB for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:42:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLlOl-0000DE-MU; Fri, 05 Jan 2024 09:42:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SeHBovf2XRw9/Mfvd8q7C842qwNWnB8apU5MWhgOmtw=; b=CVwUunmi+z6w MqFKMAduPW0xP5MOS5nNptUHdG2DUuY9zA7Y+z3l8P8ZB5MV6UxQkz3jxmce1Gra4uKs7SW95FIC4 g2UdxlLo1o5HH2urMZpfPb3D5RvSiLjjOJwGiejmzq1n+5NgkcVbrzbeF0cohnjGKB+Fm+RkvigSx a8WussjQefsn7VNdbHX/7idH/nSCXnZGTNDqJ2htS45lUZlAX1loNXM8wyH6sC5EXfHH1RmZle0xQ 053sAzbSSs98Bt6QTxF+ZLpKRrZSp8NUGR/bd7q9zr2JVaJIyG4flna7RzZertmNwCZ4SnXr8rNk6 txZ9zl54j7NQjOt97AxKOQ==; Date: Fri, 05 Jan 2024 16:41:59 +0200 Message-Id: <83a5pjvo3s.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87v887g85d.fsf@HIDDEN> (message from Manuel Giraud on Fri, 05 Jan 2024 15:35:42 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> <831qawvx7q.fsf@HIDDEN> <871qavhpxf.fsf@HIDDEN> <83edevvqyj.fsf@HIDDEN> <87v887g85d.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Fri, 05 Jan 2024 15:35:42 +0100 > > I also imagine it would be mostly in C. But looking at the code, I > think I have overlooked something: lookup_image is what currently does > most of the work (with caching) and this is in called in many places in > "xdisp.c". Of course, I think we should keep that... but then how could > we design this new cache? For example, lookup_image could look in both the existing and this new cache.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 14:35:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 09:35:55 2024 Received: from localhost ([127.0.0.1]:56729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLlIg-0004n3-Pd for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:35:55 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:6979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLlIa-0004mr-V5 for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 09:35:53 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=/E0bJ4X2 S+mNv5ldcAorMb/pt6xV6/BSuShSeOUYrRM=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=5FdHTJUKHrzuueaIMp65xn+EfDE+f7 k2KT1P2DastxrcAeuZdyTTnj4m2uR4aM8XfGCaN9Au7IX7cnXH68HKBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=/E0bJ4X2S+mNv5ld cAorMb/pt6xV6/BSuShSeOUYrRM=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=I/DFtG1PaA1tUOo0xTYbX1g2Ulpl8Pk5n5nrGb wfDR9hcRgp4ADRn/qIJ2h+dSnxbg59h4xJ+vLKUIbSEwzSc64Q8X662H646giCoXgIRZAL PJ6kKl1z6MLsGRVwPZ6v5g13S50hFXmGS1exyoFWkuxX31id2ietFzN+rlj85iMczwVbCm P9cbr4vOopWvX3bw2wYG8Xh+j39ntgTpw8C+aAX/ENikgckggezd5ohCYLU4aflzfP6fb/ u7St9PYLCss5b7CEwv9e1LV2Dyf9URNXQHORcAXE4A3KPw3AFS/DDG+DA01LD7aJlTQm8N VwvEXkKBrhKYoSS3HlZsuJfg== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id f8b501cc (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 5 Jan 2024 15:35:43 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83edevvqyj.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 05 Jan 2024 15:40:20 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> <831qawvx7q.fsf@HIDDEN> <871qavhpxf.fsf@HIDDEN> <83edevvqyj.fsf@HIDDEN> Date: Fri, 05 Jan 2024 15:35:42 +0100 Message-ID: <87v887g85d.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Manuel Giraud <manuel@HIDDEN> >> Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org >> Date: Fri, 05 Jan 2024 14:26:20 +0100 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> > But we might need to store additional information there, like the >> >> > buffer of the image, for example. >> >> >> >> I don't understand. Where do you think that the buffer of the image >> >> should be stored? >> > >> > In the cache, together with the image, I think. >> >> You mean in struct image_cache? > > Yes. > >> > How else would the Lisp programs know which images "belong" to them, >> > and when to uncache them? >> >> I don't know exactly. My idea was that an image-mode buffer has (buffer >> local I guess) variable that will hold its image cache. > > That is also possible, but then will the cache itself be implemented > only in Lisp? I assumed at least some of it will be in C. I also imagine it would be mostly in C. But looking at the code, I think I have overlooked something: lookup_image is what currently does most of the work (with caching) and this is in called in many places in "xdisp.c". Of course, I think we should keep that... but then how could we design this new cache? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 13:40:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 08:40:46 2024 Received: from localhost ([127.0.0.1]:56693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLkRK-0001VV-Jy for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 08:40:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLkRI-0001VG-9J for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 08:40:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLkR7-0004U9-U6; Fri, 05 Jan 2024 08:40:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=h1QCDdA5zWBLMy4rLq8+xad1fuXYNkvZ0M1pqc4TkLc=; b=nHpMjp5Ohikb f3KBsmMz2PzpXiD/oJEtHGV0pKJnkSkbq3o1SIJ5msfd733htymB26Yy8bTdblV5nsml1892RnVI2 rRRniPi6ntf8zEUQtGX1GApj9Y0KB2tJ5bkiTSoTK89t9ACExthi8KIefuE9mgxBrxFYVOvb2TWdR fhOuLuctdHSNYgawEVrDszvBDZq5b7pxw0gcD0g09MpX+BMgoQP3qRYQfq1u2/yi0O5Ng/GjfPhEs hDZQAF2h2lGjs8FHzEH7MFKcmNkchkt5x1CyU5n0zdITOTgYJC2WVfv1zQmTO4QM2NZTdGnVfiDLW 5WmJlrl9xFxVyip7OJJjTw==; Date: Fri, 05 Jan 2024 15:40:20 +0200 Message-Id: <83edevvqyj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <871qavhpxf.fsf@HIDDEN> (message from Manuel Giraud on Fri, 05 Jan 2024 14:26:20 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> <831qawvx7q.fsf@HIDDEN> <871qavhpxf.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Fri, 05 Jan 2024 14:26:20 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> > But we might need to store additional information there, like the > >> > buffer of the image, for example. > >> > >> I don't understand. Where do you think that the buffer of the image > >> should be stored? > > > > In the cache, together with the image, I think. > > You mean in struct image_cache? Yes. > > How else would the Lisp programs know which images "belong" to them, > > and when to uncache them? > > I don't know exactly. My idea was that an image-mode buffer has (buffer > local I guess) variable that will hold its image cache. That is also possible, but then will the cache itself be implemented only in Lisp? I assumed at least some of it will be in C.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 13:26:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 08:26:32 2024 Received: from localhost ([127.0.0.1]:56669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLkDX-0006wN-QF for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 08:26:32 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:42593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLkDU-0006vw-FO for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 08:26:29 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=9XqCYQVR mcngCGutEAH05q1wjie/NyygP5fQibI15Hg=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=7WWEjWpphu7b9pmszjfcxCdvsXm38n DhzjTZ2fNaaROJ1JvPRuimwUGsB+Qxcix5rR9F8dav6F0/UUc8Xx7jBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=9XqCYQVRmcngCGut EAH05q1wjie/NyygP5fQibI15Hg=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Ffztsu9lWofE1duqWk1gXAAHAVS+ax5YSWtVm+ 2oxvVd+5CmpclKdrl4WY3ksYrHu+/qlPIpp2D58HtVFOzviHQhtf7yEanRDm4JCGh8zWFZ L0FIIufgNa8MhNhZhx14OqovqLyHBpJjyvFJki4lfgiX9Hbm1EvrNV9xb7nL9UMkUuIG+G hU3LBkcDoIhqAkqRW7XP0GYD4IwbRwyBP3NC69gWeX5IS5wp7qiodrod5x8vwKxM/+2Uhm OpufpC5jXuqsAz7SAdUZHyscaW6obQoDECLX/yvTEc8p4ZrIIkpslcH6yiggrRm4NynIHZ hyNwb3hYQKdH4R1gVOIxG+hw== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 77ef53f8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 5 Jan 2024 14:26:21 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <831qawvx7q.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 05 Jan 2024 13:25:13 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> <831qawvx7q.fsf@HIDDEN> Date: Fri, 05 Jan 2024 14:26:20 +0100 Message-ID: <871qavhpxf.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] >> > But we might need to store additional information there, like the >> > buffer of the image, for example. >> >> I don't understand. Where do you think that the buffer of the image >> should be stored? > > In the cache, together with the image, I think. You mean in struct image_cache? > How else would the Lisp programs know which images "belong" to them, > and when to uncache them? I don't know exactly. My idea was that an image-mode buffer has (buffer local I guess) variable that will hold its image cache. > I guess some other information relevant to the cache-removal decision > will also need to be stored there. Yes, I imagine. -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 11:25:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 06:25:47 2024 Received: from localhost ([127.0.0.1]:56530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLiKg-0008Io-RE for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 06:25:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLiKd-0008IY-CP for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 06:25:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLiKQ-0000Ay-Lc; Fri, 05 Jan 2024 06:25:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Svw7jbnJjY/sd8MVT/gwBIMNJaP8qBlSCEyLEsxi1nE=; b=ZLuHLM4okULq GrWHgORv/n5kOiFiqtl45YQPNrx2ZamS/pxXBAiLrJMnl8yJ44SI35U8IBQuzS0lpyT5WBFZpHpT8 pRow2bsZRFd5xvbWe1jjSECeUMVoGOkFw086RYKqRby2RW1j+A8hDZ8mINkcUVIqnHu+QRz4B21t3 C/k8qrpZM08tJgr+HVGZAfkrV9AJOHFeAyJMABxyu2BzeBn9ObOABchnsTHh11PhAF4sMsW2qpuGU /IvQ3EoL4TX8fnchaTr8Rl8G/8WAOhiix0XPWVEW+BQKKD8U0e/XhOEM7CX/skU/o8r/oUnb/Ekf/ 9jR6jSfIHVMQ45dX4/Xi0w==; Date: Fri, 05 Jan 2024 13:25:13 +0200 Message-Id: <831qawvx7q.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <875y08gikv.fsf@HIDDEN> (message from Manuel Giraud on Fri, 05 Jan 2024 11:50:24 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> <875y08gikv.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Fri, 05 Jan 2024 11:50:24 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Ok. Maybe we should re-use the current C cache code with a "nice" > >> interface for this too. > > > > Yes, that can be done. > > Ok. More thinking: my idea is to have an interface to create/destroy > image caches and feed/query them. And why not have a Lisp interface to > it so something like image-mode could use this to manage its own cache. Yes, of course. We have a Lisp API for the existing cache as well, but this new one will need it much more, since we basically rely on the Lisp programs to manage this new cache. > > But we might need to store additional information there, like the > > buffer of the image, for example. > > I don't understand. Where do you think that the buffer of the image > should be stored? In the cache, together with the image, I think. How else would the Lisp programs know which images "belong" to them, and when to uncache them? I guess some other information relevant to the cache-removal decision will also need to be stored there.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 5 Jan 2024 10:50:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 05 05:50:39 2024 Received: from localhost ([127.0.0.1]:56438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLhmh-000224-4o for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 05:50:39 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:28456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLhmb-00021q-IC for 68006 <at> debbugs.gnu.org; Fri, 05 Jan 2024 05:50:37 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=p47ERYFm MpM1u14k4ocrSgFkB9ZHmVvYXIHc/R0eEL8=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=IbWegUjSEpxAvTl0xy12uZ4hfjZgyD aHpQrqKuIvr3xBIYaJKvfXp6SV5CDKa0XyDzXtgal3+thjShQMo2+VAg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=p47ERYFmMpM1u14k 4ocrSgFkB9ZHmVvYXIHc/R0eEL8=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=GGHHgrdGWOCo0pa3xX4063G79WH5nrpAY+jk40 J1Hyd9yTVDGWYibeYXaLIbPQ+vTMf91dT94LxnJfINrrMKNKWfgbGArnI9c3C0XyDusu0F cQNjaCcPfWAfIBUFVGpt2V+LXJ5ZfvkyxSAy8Dq3+ETfZaTRl0YmnVMplHdEK3fyQAI0rg lMnn34c1J5+3+sMSRkfutq7pqhImoSm1fnAvF6qoF249b65SjaabzVhg6WGiA1rRoAQoQ1 BNsVx/dWquU6LGmJooOYPCOHHnTClT+LDm/O1aM5u+krXALjr4IJ5HbOEeyi0BpClcifqn 9iZhxUn/J/Gn8MXw+hYltNIw== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 60bc53cd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 5 Jan 2024 11:50:27 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83il48x4a8.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 04 Jan 2024 21:54:55 +0200") References: <87le9jlfd6.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> <83il48x4a8.fsf@HIDDEN> Date: Fri, 05 Jan 2024 11:50:24 +0100 Message-ID: <875y08gikv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Manuel Giraud <manuel@HIDDEN> >> Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org >> Date: Thu, 04 Jan 2024 20:16:19 +0100 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > Yes, probably. And if you are going for the simple solution, please >> > keep in mind that image-cache-eviction-delay is a global variable, and >> > the images are cached on a per-frame basis. So if image-mode enlarges >> > image-cache-eviction-delay, it will affect all the images, not just >> > those in image-mode buffers. One more reason why I think we should >> > provide a separate and differently managed cache for this purpose. >> >> Ok. Maybe we should re-use the current C cache code with a "nice" >> interface for this too. > > Yes, that can be done. Ok. More thinking: my idea is to have an interface to create/destroy image caches and feed/query them. And why not have a Lisp interface to it so something like image-mode could use this to manage its own cache. > But we might need to store additional information there, like the > buffer of the image, for example. I don't understand. Where do you think that the buffer of the image should be stored? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 19:55:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 14:55:25 2024 Received: from localhost ([127.0.0.1]:55760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLToL-0007fQ-8B for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 14:55:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLToJ-0007fD-M9 for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 14:55:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLTo9-0005vp-UE; Thu, 04 Jan 2024 14:55:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4H/d7/0gCLNNc1TTrJYHtUJvDVahvy3aNeVdOJNeprI=; b=f8EUNPncmO1a FjvhIrU5G12AEHw5jRqtP7a7o2l2wBBvKEgjYKIYKVpxsbnjARvUj+WG0FjvpiaJhBi/IcqTmNZ2t i/obruN6/tPo31Q31GhiRtXCrfXROpJZoFqrgoZ21eZ5adGxmH6h7pbSBQxp78MYUzk0z8mkbPfOh S+iEo/uEzMfhpSsgpVNrH3AB6SaEuuwz+wQSebsrFxsgEcmBNdKdJ+ogEzMhPXQmfHj/egfnPPZn3 LNeG+e4otNLkoxghU7h+GD7Xo2AuCWewgt9e8EoV0Qx7C/N7nPby8C8Kh7T3vCs2jP5FcSPXGrzEv +f9Y6qh+O9yMRrh5jMzZBw==; Date: Thu, 04 Jan 2024 21:54:55 +0200 Message-Id: <83il48x4a8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87bka0hpto.fsf@HIDDEN> (message from Manuel Giraud on Thu, 04 Jan 2024 20:16:19 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> <87bka0hpto.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Thu, 04 Jan 2024 20:16:19 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Yes, probably. And if you are going for the simple solution, please > > keep in mind that image-cache-eviction-delay is a global variable, and > > the images are cached on a per-frame basis. So if image-mode enlarges > > image-cache-eviction-delay, it will affect all the images, not just > > those in image-mode buffers. One more reason why I think we should > > provide a separate and differently managed cache for this purpose. > > Ok. Maybe we should re-use the current C cache code with a "nice" > interface for this too. Yes, that can be done. But we might need to store additional information there, like the buffer of the image, for example.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 19:16:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 14:16:32 2024 Received: from localhost ([127.0.0.1]:55717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLTCi-0001Pi-1q for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 14:16:32 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:1382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLTCc-0001L0-Pu for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 14:16:31 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=K7AoKnvq R0I6F7A1rl0xp330BH7sx7cGV8aFlkwUOec=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=Ymxgl35F80GWlsQgDsDBuB3uEYR/qi InKIchitjJLQpfSaHV9WEsF04O6EObFbfSUAlkUko1zw0cfwDJfvQFDw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=K7AoKnvqR0I6F7A1 rl0xp330BH7sx7cGV8aFlkwUOec=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=iJIT3iWFyUSS58KVWC/4Zq4bHuuiJAeUJa1fxp +eCvFjSTLFx8REjnZNj3XxqzH0CXumfHhA5zLajcCf5TN5zkZOLHhPHHmmFur5PU733OsT Hs8+RF8BuQc/CUE51MPCquBMJ9/v0gfRI0LWPiTgCFlIiei9aiVM7QepAjlgGNNcu0EEdK QUbR4k28sLgIeeOxuofq/pru1dWYJKThmeKjhDQsG4B190dsVCq6fFnUviFi9fSQFYR5/t E4+mB2qjdmtTEiSZcxxTUj/qlt4HF6YG8VOz+9+T5TcWAY6zi7ZfGvtqdhInxQeFtnz1Ck n4rjP1Ek3G1YT6ILxbUbXSuA== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 4ef76d49 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 4 Jan 2024 20:16:21 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83jzopvsgj.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 04 Jan 2024 20:55:40 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> <83jzopvsgj.fsf@HIDDEN> Date: Thu, 04 Jan 2024 20:16:19 +0100 Message-ID: <87bka0hpto.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Manuel Giraud <manuel@HIDDEN> >> Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org >> Date: Thu, 04 Jan 2024 19:42:53 +0100 >> >> But anyway, you're thinking about another image cache completely user >> manageable? > > Yes. > >> I guess it is a much more harder problem to tackle. > > Probably. But anything else will be IMO a kludge. (We do have > kludges in Emacs, so we could have one here as well, of course. I > just thought that it would be good to avoid it if possible). Ok. >> For starters, as the current image-mode is using the 'image' display >> property which uses the current image cache, I imagine that it >> should then be replaced by something else? Thinking about that, maybe we could have this other cache on top of the current one (and still on top of the image display property). > Yes, probably. And if you are going for the simple solution, please > keep in mind that image-cache-eviction-delay is a global variable, and > the images are cached on a per-frame basis. So if image-mode enlarges > image-cache-eviction-delay, it will affect all the images, not just > those in image-mode buffers. One more reason why I think we should > provide a separate and differently managed cache for this purpose. Ok. Maybe we should re-use the current C cache code with a "nice" interface for this too. -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 18:56:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 13:56:08 2024 Received: from localhost ([127.0.0.1]:55709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLSsx-0004GX-Ox for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 13:56:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLSst-0004Fz-IT for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 13:56:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLSsk-0000eD-7M; Thu, 04 Jan 2024 13:55:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=T/qdtXM5vyBdjl0hJRjq9dhL2JKRlePQjFNwoa+vGio=; b=hpwChtncAF8h SQ2sUAZMNUnNIKcWsTbcIqzCB8wnBdwMPufQleb/V9q6eswfM+2PjVFN24zm8MQqnbi53+jb8WXfm 9wdtCyfIaXM/FKfhPvxJ9xzs7TPX+06jJ4nw/BpO7izgzkuVBgwZrOBKoiG0JCzISqQ5Lq03cj3Do cbOolUEF0Wk86/bWAYDSoT44yM0OBBCjaQNgC1QeTMZyMqdTj2S5Hp0D5L2M2GbTt12V1KDoASv+u NirmA+io6IBKPmllnKu6rTYIo/u9EMHccRFlbOiT1y38KsKhpMa0aVmrgoV1ToXU9qWhUj9AbF/0V f2Mi6Zlz/WePWQ770BRbxg==; Date: Thu, 04 Jan 2024 20:55:40 +0200 Message-Id: <83jzopvsgj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87h6jtrlci.fsf@HIDDEN> (message from Manuel Giraud on Thu, 04 Jan 2024 19:42:53 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> <87h6jtrlci.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Thu, 04 Jan 2024 19:42:53 +0100 > > But anyway, you're thinking about another image cache completely user > manageable? Yes. > I guess it is a much more harder problem to tackle. Probably. But anything else will be IMO a kludge. (We do have kludges in Emacs, so we could have one here as well, of course. I just thought that it would be good to avoid it if possible). > For starters, as the current image-mode is using the 'image' display > property which uses the current image cache, I imagine that it > should then be replaced by something else? Yes, probably. And if you are going for the simple solution, please keep in mind that image-cache-eviction-delay is a global variable, and the images are cached on a per-frame basis. So if image-mode enlarges image-cache-eviction-delay, it will affect all the images, not just those in image-mode buffers. One more reason why I think we should provide a separate and differently managed cache for this purpose.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 18:43:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 13:43:05 2024 Received: from localhost ([127.0.0.1]:55704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLSgL-0001I8-Bi for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 13:43:05 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:8746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLSgG-0001He-C2 for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 13:43:04 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=1npjlZqw GE0wXfSjuAU+dzLqsgo7iZds8JIhomwKVIc=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=BxX5K6+dd8ljxKWMA6zfvzEM3PQFy0 Z8nnqGe7tkbv3dYDvnQeYNnYV83YuvNhOshaLDDuKcEs4rcJ40UaHkAA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=1npjlZqwGE0wXfSj uAU+dzLqsgo7iZds8JIhomwKVIc=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=GWsK1KqQHqdqC7DWTJuf2QemtJfwuUsLU1m0ro izNeWQ3IS5eRudzVGDUIlQ7BfNyyQTaCLJ3BwA8XTZZ/fMnCMKKfxBeVLstG0i6hyyEplJ fDPVHQirBk6W+QSud9gBE05hBMrkuzAafwx48YHAttLGitky4P/HyBEuoE68ugS4Pq7DIS G93Emt0AhmSOuKmK0aPUWj5JQpqh9m4RvOqxrw8eFH3P8i+OgKxBJIteB6X4149kzENEr+ oLH/hf6mO0oJWl80sPU6f2ssD7y96uFOrfabDWJpjB1y+AIt8tpm4O9iFsapvU3DPa6K33 EiFRwG4ZO0HQtxiBFl//5T8w== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 320f5eba (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 4 Jan 2024 19:42:54 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83plyhvvso.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 04 Jan 2024 19:43:35 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> <83plyhvvso.fsf@HIDDEN> Date: Thu, 04 Jan 2024 19:42:53 +0100 Message-ID: <87h6jtrlci.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] >> I've tried to think about it a bit but I don't understand why do you >> think it should be a different one. > > Because its purpose is different, and the conditions to flush are also > different. > >> With `image-cache-eviction-delay' being 300 seconds by default, I >> think this is enough time for this usage too. > > I'm not sure I understand why time since caching is relevant for the > purpose that you want to cache images. Suppose there's an image that > should be displayed during the entire session -- how does it make > sense to remove it from the cache after 5 minutes? OTOH, another > image that is displayed just once doesn't need to be cached for more > than a few seconds. My idea was just to have image-mode to feel that it display images faster. In the first time, by caching already displayed images and maybe, in a second time, by doing some prefetching of nearby images. For this usage, I thought that 5 minutes was also a quite good value. But anyway, you're thinking about another image cache completely user manageable? I guess it is a much more harder problem to tackle. For starters, as the current image-mode is using the 'image' display property which uses the current image cache, I imagine that it should then be replaced by something else? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 17:44:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 12:44:05 2024 Received: from localhost ([127.0.0.1]:55608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLRlE-00068L-Mq for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 12:44:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rLRlA-00067g-Kk for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 12:44:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rLRl0-0002vW-K1; Thu, 04 Jan 2024 12:43:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=v1O28KbK6Z6adYYBUa+pRQ8nlAe7gvybPTzIa/6OS1Y=; b=J/5mtvxZhJPj N0MjW8JqV5+SjbuzIGM2/LuasCywyZTE/NFe1Bxarw+xqMZIWuBt5PKzaezyQ1/5xtKRe9hlbtGO+ Ms0O3Ix2fLDIGoczITjsQGTlbXsKYYSlq2JdWB+LpBHxpuejeqrGdC3Bz5GZ5ahoxGsju7/7spVvz 7RMRaIr1hGUm1qiWb7IK61FnJw/b3fXfx6SrePfZ7lnexSJI6AkoGWZYKgFLuNaxpcE67woLlM7la eDeTBy6m3AtJNkMbeE6AIzqA0MdyZaUIAZJ//9+YXy9vDqE8qLn3UGcvjXwfEVfo4+T8uYg7vxHZ2 H8KlKWltiFYtvZfQ/WnMyg==; Date: Thu, 04 Jan 2024 19:43:35 +0200 Message-Id: <83plyhvvso.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87le95rqoh.fsf@HIDDEN> (message from Manuel Giraud on Thu, 04 Jan 2024 17:47:42 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> <87le95rqoh.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org > Date: Thu, 04 Jan 2024 17:47:42 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Do you think we need a completely different cache or just some handles > >> on the current one? > > > > A different cache, I think. > > Hi, > > I've tried to think about it a bit but I don't understand why do you > think it should be a different one. Because its purpose is different, and the conditions to flush are also different. > With `image-cache-eviction-delay' being 300 seconds by default, I > think this is enough time for this usage too. I'm not sure I understand why time since caching is relevant for the purpose that you want to cache images. Suppose there's an image that should be displayed during the entire session -- how does it make sense to remove it from the cache after 5 minutes? OTOH, another image that is displayed just once doesn't need to be cached for more than a few seconds.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 4 Jan 2024 16:48:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 04 11:48:01 2024 Received: from localhost ([127.0.0.1]:55540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rLQsy-0005Mc-Ic for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 11:48:00 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:32414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rLQso-0005LS-FV for 68006 <at> debbugs.gnu.org; Thu, 04 Jan 2024 11:47:58 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=6Ej5/i+4 ix3YqkhI5kZsMMXPWp8gF9ct0leC4paXmWs=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=O3lHP+cuqvWwcXW/aEP/QKpgcWg1vq pbkG/G38v7hadUoqM8z8lO1lZmTQQgJifgqKwPaI7g6ermK7Rh24XBCQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=6Ej5/i+4ix3YqkhI 5kZsMMXPWp8gF9ct0leC4paXmWs=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=BWVMKssankgDN5yJJEPlN1zjnz8qRTrh6jADJj DPnRQKbtHLwuNg+pw0lKo1Gy9g8Ybs62nP30xN31kVzQsilQzyqlIf5MLdnTbW+iVDpWf3 L5MnAyTlVlzK9ZpQDKIuhsKkmbPTaEyCBmGNDoHokdKYFMxgcKn/zCJZaG8CcfQxD8JnBM 2NrW9cf26eefKFZmPM9dz76JPKrIBYGCdWmvaDxFcf6RPQ2TO8nJ92g10V11OoWigUcvWy zmZEk7HNrS1dBE7VCJE8BQH56+hRSkaes2vXW8GspUnGvJOW3t7SMJii9wKzSrUFFYT1qD Psa3HCHkLVQN2nPaZDfbdyjA== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 95bb9b7f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 4 Jan 2024 17:47:44 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83r0izzn1p.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Jan 2024 19:02:10 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> <83r0izzn1p.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 04 Jan 2024 17:47:42 +0100 Message-ID: <87le95rqoh.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Manuel Giraud <manuel@HIDDEN> >> Cc: Stefan Kangas <stefankangas@HIDDEN>, 68006 <at> debbugs.gnu.org >> Date: Tue, 02 Jan 2024 17:04:09 +0100 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > My point was that you are expecting from this cache something that it >> > wasn't intended to provide. As a corollary, I think if we want to >> > speed up paging through images, we should design and implement a >> > separate cache, which is designed to support the use case of going >> > through many images one by one, back and forth. >> >> Do you think we need a completely different cache or just some handles >> on the current one? > > A different cache, I think. Hi, I've tried to think about it a bit but I don't understand why do you think it should be a different one. With `image-cache-eviction-delay' being 300 seconds by default, I think this is enough time for this usage too. -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 17:02:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 02 12:02:45 2024 Received: from localhost ([127.0.0.1]:51142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rKiA9-0005Xu-0k for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 12:02:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rKiA5-0005Xf-06 for 68006 <at> debbugs.gnu.org; Tue, 02 Jan 2024 12:02:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rKi9u-0003bO-Ph; Tue, 02 Jan 2024 12:02:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=d1B1eJ6wZZC814wxVLZVlNZO5TGWLKUGVTPD7ULNqJg=; b=S3oX2A88PYFc VYINecEcIlMkB94UHT0SOKagnvzZrwM13J76fc1zKK1vNg0YFKoJszETxgkLn1D4ET7ifdLHHmkO5 48NMwgoQWyHjdNkOt4xXc5zm54VjskRD1QEVCDF17Yg2Q6azTIcQRLkajD9Kq4lNzlyijKcaJPWXi Ukc5d33Zo33AX56xjuGV1uX/yjgL2zuTcMmRQxWhkuYtao2l97ryPjXPPdzMd32rasiTxs1wwwkkd rG7d1UnvAVPd6094IcBrDF6zVrXdLbbfN+A+cBnZ7U9EHZNmZOug5kY68NHaacxtcAwMDnZ9fyjIE 1kRvhMkTwN11nfeQutSI0g==; Date: Tue, 02 Jan 2024 19:02:10 +0200 Message-Id: <83r0izzn1p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87mstnafie.fsf@HIDDEN> (message from Manuel Giraud on Tue, 02 Jan 2024 17:04:09 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> <87mstnafie.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: stefankangas@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: Stefan Kangas <stefankangas@HIDDEN>, 68006 <at> debbugs.gnu.org > Date: Tue, 02 Jan 2024 17:04:09 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > My point was that you are expecting from this cache something that it > > wasn't intended to provide. As a corollary, I think if we want to > > speed up paging through images, we should design and implement a > > separate cache, which is designed to support the use case of going > > through many images one by one, back and forth. > > Do you think we need a completely different cache or just some handles > on the current one? A different cache, I think.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 16:04:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 02 11:04:25 2024 Received: from localhost ([127.0.0.1]:51087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rKhFg-00020x-OL for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 11:04:24 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:16606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rKhFd-00020n-91 for 68006 <at> debbugs.gnu.org; Tue, 02 Jan 2024 11:04:23 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=mYAiK9Bc 46bA+gXh9KZIwGSF39YQQTluhlCSayi5H2M=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=mnhkZCf0AeLXkC5Mxhba7aOyhFaC1j /gWPpkvmQCNSYzmAtdwtZwV7YpIDYAooG9bOMUWmYcnMsu5UrxLqbrDw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=mYAiK9Bc46bA+gXh 9KZIwGSF39YQQTluhlCSayi5H2M=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=UliLNcrXMdJyp+abAjIBxT5Vy3h5LjsXn9tHXq xbbL1V2S33DplhGE1xf3/N1oQgRK1Rw+TJJDnANPYj8kfnPKF0cdb9l9yDt1ChsRNBMrhk uZo+uJ6S5e/E4//o2P4KSxwgXC1QDaWxboCPGCPK200Lic9jf9DtLpOwR6LD0zNL53dvRO rJr8urCMnStyv8BdjOhmZTktSR2RYhf1ntwGqMotkb6iQpyTd0iWkh10QGXApQWeYBdWLS nYyb2QRnpOxZhS+0IdSkfmvznsOejyHK8ZhbBfO2r/wl++RGDdeiyMDVKHK+BDNB9JxXXF cv3VN3tJ3Jt7nP50qYimk51w== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id d8bfbc03 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 2 Jan 2024 17:04:16 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83zfxnzyrb.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Jan 2024 14:49:12 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> <83zfxnzyrb.fsf@HIDDEN> Date: Tue, 02 Jan 2024 17:04:09 +0100 Message-ID: <87mstnafie.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: Stefan Kangas <stefankangas@HIDDEN>, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] > My point was that you are expecting from this cache something that it > wasn't intended to provide. As a corollary, I think if we want to > speed up paging through images, we should design and implement a > separate cache, which is designed to support the use case of going > through many images one by one, back and forth. Do you think we need a completely different cache or just some handles on the current one? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 12:49:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 02 07:49:44 2024 Received: from localhost ([127.0.0.1]:49571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rKeDI-0004x2-3R for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 07:49:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rKeDE-0004wj-Rc for 68006 <at> debbugs.gnu.org; Tue, 02 Jan 2024 07:49:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rKeD5-0002LF-QF; Tue, 02 Jan 2024 07:49:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Nv2Ys+Oi8Aa7KB+7g6mZ0aD+26JUa1jCYpEwb2w1t7w=; b=bllS++2V0Tou qzNXZxN6d3fQ+LMYTxmJL5FV72cAYXh2eU8hGrOMh4b5HUYAR/F9uKskGxo8mQJTvb2jwjjCMs0Wc ztlvE5E8JqUNyGBgpWeF9fV/9K4fbxowuBdyMkklOrAJ+P0P8jhFbS2dY1gysoLCdjnM+gLMNPKfX XjfdPzWEdJEBhsGKm5FnHhvqwMbhuW3jzBM+0THEMyejE+IkDmhQXbe94z56vY0AGlxSIEx7c89O+ HQMRhKc/wtsw0vhMmlsLRy0PNFuRjiy73YdB5eApr06sVF+NmAyFR/iHW4mqnl+vsc0jQ1LDq1xFI 0ppdqJsmQWOTD6rU9qcxkA==; Date: Tue, 02 Jan 2024 14:49:12 +0200 Message-Id: <83zfxnzyrb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> (message from Stefan Kangas on Mon, 1 Jan 2024 16:19:31 -0800) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: manuel@HIDDEN, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Kangas <stefankangas@HIDDEN> > Date: Mon, 1 Jan 2024 16:19:31 -0800 > Cc: manuel@HIDDEN, 68006 <at> debbugs.gnu.org > > > The real purpose of the image cache is not to hold the image in > > memory for displaying it again and again, the purpose is to allow > > the display engine to generate the pixels once, then reuse those > > pixels during the current redisplay cycle or a few following > > redisplay cycles. > > Basically, I don't see how this difference relates to manually evicting > the cache or not. My point was that you are expecting from this cache something that it wasn't intended to provide. As a corollary, I think if we want to speed up paging through images, we should design and implement a separate cache, which is designed to support the use case of going through many images one by one, back and forth. > > In a nutshell, this cache is ephemeral anyway, and will be flushed at > > some arbitrary time whether we want it or not, because its purpose is > > not what you think it is. > > If it is flushed anyways, then that is exactly what we want here, I > think. The idea is to flush it less often, AFAIU. My point is that you cannot currently control when it is flushed, not fully anyway. Again, the reason is that the cache was not for the purpose we need caching images in the case that's being discussed here. > > In any case, if you intend to not flush the cache at all, then what > > does that mean for Emacs sessions running for days and weeks, let > > alone months, on end? will they keep these images in memory forever? > > Or should GC sometimes evict those images from the cache, and if so, > > under what conditions? > > Are you saying that, if this particular call is removed, we will never > flush the cache Not just this call: you'd need to remove or disable the code which evicts images from the cache "when the display engine feels like it". And if you do that, then yes, the images will never be flushed, since there will be nothing the flushes the cache. > (i.e. we will have memory leaks)? Not a memory leak, but memory that is never released. Basically, we lack a good way of knowing that a given cached image is no longer needed. The cache as it exists now doesn't care, since it isn't supposed to hold the image long enough for that to matter; but if you want a tighter control on when an image is uncached, we need to design and implement a way for that, and the main stumbling block in that case is how to define conditions under which an image can be evicted from the cache.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 12:10:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 02 07:10:58 2024 Received: from localhost ([127.0.0.1]:49549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rKdbl-0004Vp-Lz for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 07:10:57 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:34142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rKdbi-0004Vd-Su for 68006 <at> debbugs.gnu.org; Tue, 02 Jan 2024 07:10:56 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=3UfKJcW5 02k6VMAcbmFJaHi93fMmQKtT+uHxl+aA4S0=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=1ZxicNQIe7JIdkJIU1g+kPXmD9urFv QJYpDXuux3IUriL2lR066D3ma7XxfwHlMToP3XpLWtoMbPLBnVbxBHAQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=3UfKJcW502k6VMAc bmFJaHi93fMmQKtT+uHxl+aA4S0=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=no3UOGZKSX5JKpvzXXKK+Mw3+gKDdK1uLuZk6T PHf0JaNV4jr1rwAHa+vT2u/Uxl1Jz4gaUT9EWN5efexrlWq4mc1m0/nL/57X9tJCu5vXcf OH16iCkLHmT26DYrKntIKVPEQp1unEJYo0LxHBrojVp4Ze6sKEFax3lFwEEi79+Z9QX/ev 1JiufBdCJLbfawOe1XJlR067VT1QCO0BNtOJOOwDZf8F1B4FQCEfxAUOVbIs44tHZswNS8 DCfkodxNTAXrPvJ4nVlJdUakk8jvky+RmsviJdtCgaf+hVs1/bb8PhRPU+ZzxsPTOi7v6D DT5c9Xr39J7yw67sTPkO/7Vg== Received: from computer (2630.fr [82.65.148.221]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e37ef0e4 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 2 Jan 2024 13:10:51 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> (Stefan Kangas's message of "Mon, 1 Jan 2024 16:19:31 -0800") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> <83le9a3kqs.fsf@HIDDEN> <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN> Date: Tue, 02 Jan 2024 13:10:48 +0100 Message-ID: <87r0j09bqv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: Eli Zaretskii <eliz@HIDDEN>, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Kangas <stefankangas@HIDDEN> writes: [...] >> In a nutshell, this cache is ephemeral anyway, and will be flushed at >> some arbitrary time whether we want it or not, because its purpose is >> not what you think it is. > > If it is flushed anyways, then that is exactly what we want here, I > think. The idea is to flush it less often, AFAIU. Yes that's it: flush less often (at the expense of more used memory of course) >> In any case, if you intend to not flush the cache at all, then what >> does that mean for Emacs sessions running for days and weeks, let >> alone months, on end? will they keep these images in memory forever? >> Or should GC sometimes evict those images from the cache, and if so, >> under what conditions? > > Are you saying that, if this particular call is removed, we will never > flush the cache (i.e. we will have memory leaks)? I don't know what Eli had in mind but removing this particular call would not remove the timely cache eviction mechanism (via 'image-cache-eviction-delay') -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 00:19:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 01 19:19:41 2024
Received: from localhost ([127.0.0.1]:48972 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rKSVR-0006rQ-Ge
for submit <at> debbugs.gnu.org; Mon, 01 Jan 2024 19:19:41 -0500
Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:58684)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stefankangas@HIDDEN>) id 1rKSVP-0006r9-Fe
for 68006 <at> debbugs.gnu.org; Mon, 01 Jan 2024 19:19:40 -0500
Received: by mail-ed1-x535.google.com with SMTP id
4fb4d7f45d1cf-553ba2f0c8fso9976474a12.1
for <68006 <at> debbugs.gnu.org>; Mon, 01 Jan 2024 16:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1704154771; x=1704759571; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=+imye1P6v/le7MbZ2XtWS+R9TGZfOryjH9/K84RKFNE=;
b=aBsHWVOK5lAbhe8c+aL3IzleTTX3bdG7QzYxi0Y4tx8oBlBmZb3Q9EDJzdfllTYEwY
geSzm1qlbZEbuxch4zoV3G36HvKZRV/BsB1PKE2y8uLybc0hysyPDpn6pqiHPiRc3+pJ
OXMfDMiLCPInQM2AQ6BaUK3CCkDF7qIs4DNbiHJtjX38sNQRo4UmThX8Ub5pPedCB9Z2
Q7GYR3uXsDPwHeZr6AmqqupwX+P1zyQLNvqtlFZxJXPE/73PMzRD4MH3TZ+IuwrtPlFo
RMpJt2vy2V4aBZk03/L43DctSXAk9O/osqhmUQvjMTKxPzCKEwJChMgkXb8F5+nG7Cdc
8myg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1704154771; x=1704759571;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=+imye1P6v/le7MbZ2XtWS+R9TGZfOryjH9/K84RKFNE=;
b=WN3CV4PYnMA7A5sK9uOYQ4lRjj8FAn6DjLvmDPYej76EjyeLa3jyMUxa1T7ANPhGvT
l2XjlnRRdmD+qCjbrP9Yry1cMiuEhSXU5obuJtsf6gD31SCARtIlLewB0bIHMkz6tjtP
JfL+GiU/P1Q8dxFrDV81aV3U37e2qPUzRzH4yxla6kY7lp3Zs27fGFVw5WiU7ibGxi+2
7E77kpunpLqq1rbyLGC4ylxjU9WwfxvYv65nwq/tYXV1mg0wIkXpKnoU9qn+OBGfhizo
uGT68MlYkn8zk2e1Rk73rDpsOOAVMhensYZHqfgSzKBozpvviIJdKENWXKcXcskBq5lN
dIBg==
X-Gm-Message-State: AOJu0YzaYAebCjXHNr3A/ou104xo6resN+Gp1vr4EFVBOzGBId61QDb8
BPl8hgUtAD7VeUZyzWVhvX8CgoKYTXZ4kUxxd5k=
X-Google-Smtp-Source: AGHT+IGxIbKYqf1WT4v0bfQzEFwBrGS63x6wCTqIKhX4/sHDq3ndvjut/YbmwyOiCORx3LekzPOIQJJSFTtsnG6g/GM=
X-Received: by 2002:aa7:d495:0:b0:555:3252:9770 with SMTP id
b21-20020aa7d495000000b0055532529770mr2947215edr.33.1704154771586; Mon, 01
Jan 2024 16:19:31 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Mon, 1 Jan 2024 16:19:31 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <83le9a3kqs.fsf@HIDDEN>
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN>
<83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN>
<8334voanr1.fsf@HIDDEN>
<877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN>
<87zfxvalnq.fsf@HIDDEN>
<83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN>
<83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN>
<CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN>
<83le9a3kqs.fsf@HIDDEN>
MIME-Version: 1.0
Date: Mon, 1 Jan 2024 16:19:31 -0800
Message-ID: <CADwFkm=N3=V_nPDEZe6sMMxPC-d=EkfMSUq+xmmz5BaFumP3tw@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: manuel@HIDDEN, 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Stefan Kangas <stefankangas@HIDDEN>
>> Date: Sat, 30 Dec 2023 15:57:28 -0800
>> Cc: 68006 <at> debbugs.gnu.org
>>
>> 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?
>
> See my explanation of the purpose of this particular cache here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68006#14
I read that, yes. Quoting what you wrote there, and I hope I'm quoting
the most relevant part:
> The real purpose of the image cache is not to hold the image in
> memory for displaying it again and again, the purpose is to allow
> the display engine to generate the pixels once, then reuse those
> pixels during the current redisplay cycle or a few following
> redisplay cycles.
Basically, I don't see how this difference relates to manually evicting
the cache or not.
> In a nutshell, this cache is ephemeral anyway, and will be flushed at
> some arbitrary time whether we want it or not, because its purpose is
> not what you think it is.
If it is flushed anyways, then that is exactly what we want here, I
think. The idea is to flush it less often, AFAIU.
> In any case, if you intend to not flush the cache at all, then what
> does that mean for Emacs sessions running for days and weeks, let
> alone months, on end? will they keep these images in memory forever?
> Or should GC sometimes evict those images from the cache, and if so,
> under what conditions?
Are you saying that, if this particular call is removed, we will never
flush the cache (i.e. we will have memory leaks)?
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 1 Jan 2024 10:10:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 01 05:10:53 2024 Received: from localhost ([127.0.0.1]:47356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rKFG1-0004QL-CL for submit <at> debbugs.gnu.org; Mon, 01 Jan 2024 05:10:53 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:11436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rKFFq-0004Q2-97 for 68006 <at> 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== Received: from computer (<unknown> [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) From: Manuel Giraud <manuel@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> (Stefan Kangas's message of "Sat, 30 Dec 2023 15:57:28 -0800") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> Date: Mon, 01 Jan 2024 11:10:33 +0100 Message-ID: <87v88d9xeu.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: Eli Zaretskii <eliz@HIDDEN>, 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Kangas <stefankangas@HIDDEN> writes: > Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" <bug-gnu-emacs@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 31 Dec 2023 07:16:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 31 02:16:26 2023
Received: from localhost ([127.0.0.1]:45554 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rJq3d-0002m5-UX
for submit <at> debbugs.gnu.org; Sun, 31 Dec 2023 02:16:26 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:48218)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1rJq3c-0002fu-0x
for 68006 <at> debbugs.gnu.org; Sun, 31 Dec 2023 02:16:24 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1rJq3V-0002RM-H6; Sun, 31 Dec 2023 02:16:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=6h9ETueef17aOJ0Mi1QFwoQ+3MjcsJ56hdXNT4vTHrE=; b=PD2/IUky5pOM
Uhn6YdgatWfDSZjWn01xZFn2nnf2uN43jxhSZdGBNz2yzSxYEXIDCD/hm+O38L8UitJmbxSdVON3O
SL8mhyK3YcJ0LuNxsbr6MdQhcg4naChb+ROAJMLAIfWHVFQRhfuAvxqCYBo3GfSYHO5YPjk7XW8l4
eOs6ace30335aVx3sInjdqMxBkTFcEkNbIwK2zcttS0X27tAxh2+aPg4PGcWpMJn+Dpd0iIKfB05t
rW8Nkp/viu39+b6zzWYd5REpxCcQKWHSQKSVEexFmq97NfVam4yeiCejRhoPhz8BMD6Es2pUKEG1A
Cu0dhQtx/37izN2OzZP2Bw==;
Date: Sun, 31 Dec 2023 09:16:11 +0200
Message-Id: <83le9a3kqs.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN>
(message from Stefan Kangas on Sat, 30 Dec 2023 15:57:28 -0800)
Subject: Re: bug#68006: 30.0.50; Image-mode speed
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN>
<83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN>
<8334voanr1.fsf@HIDDEN>
<877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN>
<87zfxvalnq.fsf@HIDDEN>
<83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN>
<83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN>
<CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 68006
Cc: manuel@HIDDEN, 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Stefan Kangas <stefankangas@HIDDEN>
> Date: Sat, 30 Dec 2023 15:57:28 -0800
> Cc: 68006 <at> debbugs.gnu.org
>
> 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?
See my explanation of the purpose of this particular cache here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68006#14
In a nutshell, this cache is ephemeral anyway, and will be flushed at
some arbitrary time whether we want it or not, because its purpose is
not what you think it is.
In any case, if you intend to not flush the cache at all, then what
does that mean for Emacs sessions running for days and weeks, let
alone months, on end? will they keep these images in memory forever?
Or should GC sometimes evict those images from the cache, and if so,
under what conditions?
As for the differences between images and other buffers, there are
some:
. many buffers are smaller than images nowadays
. buffers with images are in many cases showing text we are
interested in temporarily, like Web pages (program source code
rarely if ever includes images, right?)
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 30 Dec 2023 23:57:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 30 18:57:40 2023 Received: from localhost ([127.0.0.1]:45295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rJjD2-0005Hb-4C for submit <at> debbugs.gnu.org; Sat, 30 Dec 2023 18:57:40 -0500 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]:46289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1rJjCy-0005HK-My for 68006 <at> debbugs.gnu.org; Sat, 30 Dec 2023 18:57:38 -0500 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-555e07761acso1243574a12.0 for <68006 <at> debbugs.gnu.org>; Sat, 30 Dec 2023 15:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703980649; x=1704585449; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=ShQYqxKpQwTiW7tf2Kfmkj1Q2xK1JuXN/3ojJWWyKBs=; b=IMrP6cJHOgaZkoU3imY7674KSdns1lLYNPoG3iUvjda5ZGXuyYCWI/06Dz0WtcTaS7 Mch7z3J9Oaz72/amiKWTr1NmcHdFolICiF5YVZ61uX6VJYQRVDNkZUoeC/knCgulNB99 8sDcA4RS75c0Yaj5zt6qSpbNC9jt4aES6N9bSIU6vKOCjD2D8b8OYwuNwyfbpV2WOSut LP0EDzMkW/9SxIuV6DlIGs5Z8BJaOkqSM/SyhyCxvWs2bBTu0j33QTTFbKzRgtmK4tXn GDk1CfAk50DlRITdip5tg7I2LH6HnacFOxEqkh/sw8hChtWJS1QnyTZWmZXI023+1PqR ntMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703980649; x=1704585449; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ShQYqxKpQwTiW7tf2Kfmkj1Q2xK1JuXN/3ojJWWyKBs=; b=u82yHrvIOQuo2/xr/UEJ48bwK2s2JL9kHZuRN3p/e7tENdDe08CNeB1zPWGu9EnfKm CO7JhTj6/lsVTFWlZfzhIcM0maeCnnqinisKeo3XsU+72rg9R5KNmVAsXXYNhENBF681 VB3+l7TziQmSBCOEDdvG8bTWOjjQ7iEwZHQHbi4porkgwSkMYuSxOZwEGlo/U24p6kXo s5WxxF0jiYlYPiyouz1JBw00LAJPdF+aI24AqHySaWbMvor3YE0zLrC0/EsRUohbmMgo Gi5FruGoHHECNZc1Ne2DKzidnx6L2atfcInEL617bSeNBg5NnRv3D0O/O+wwKA5bdc4a quEQ== X-Gm-Message-State: AOJu0YziCTbPbuZbNAfoKh5OCg2g33VYV58IkgnJJK4SY9xNwTKOM/JB /gOmo1FZE5qIE+1wnTJj7OOE6bvJdQfmICkx29hwTXHYDhs= X-Google-Smtp-Source: AGHT+IGVQJzCMohnzM4+dU/1GwiXoKhaBH9nYSkuk+abnGymd6T2EE6cmi8YGLUgYMjGm6gES1sVLsM0hyekMk4AqfA= X-Received: by 2002:a50:ab1d:0:b0:553:49f1:8366 with SMTP id s29-20020a50ab1d000000b0055349f18366mr5929227edc.77.1703980649476; Sat, 30 Dec 2023 15:57:29 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 30 Dec 2023 15:57:28 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87frzjvpb5.fsf@HIDDEN> References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN> <87frzjvpb5.fsf@HIDDEN> MIME-Version: 1.0 Date: Sat, 30 Dec 2023 15:57:28 -0800 Message-ID: <CADwFkmma1gADfbcH4Z_+ytUka0=C7xxvdDodHvihFKF5g7HB9A@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed To: Manuel Giraud <manuel@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> 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). 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. 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? 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'?
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 30 Dec 2023 12:38:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 30 07:38:00 2023
Received: from localhost ([127.0.0.1]:43257 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rJYbH-0004WR-TZ
for submit <at> debbugs.gnu.org; Sat, 30 Dec 2023 07:38:00 -0500
Received: from ledu-giraud.fr ([51.159.28.247]:33478)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rJYbC-0004WF-Hi
for 68006 <at> debbugs.gnu.org; Sat, 30 Dec 2023 07:37:58 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=HXR5w0Pw
/A/3pdQhOfocZYr1ipHEQtqSeoWkG8rkH5Q=;
h=date:references:in-reply-to:
subject:cc:to:from; d=ledu-giraud.fr; b=zwWXuJpMR46HkP/Ql58Xp+Udtv8Y63
vJ9F+DoTpZk7BrXNAo6vJUP4xAXWBnsTtA5TzHIi21m9KjsJ5s5j74DQ==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=HXR5w0Pw/A/3pdQh
OfocZYr1ipHEQtqSeoWkG8rkH5Q=;
h=date:references:in-reply-to:subject:
cc:to:from; d=ledu-giraud.fr; b=Iw58XhQCRfbrTO95iFllZjLvOckbCrsEEKvckq
C0RxiNzHPjNRH6gC+rvlTn/UKiUwjgJzZ7AjB37FIbOlhEUNf7mqofpjCL36ITsHOf+niE
+D5h02IAucNIq5mG9n+9HYGnfw6+csemlFEszAV/Yg0WXiVrD10Zyg4Xmz5VCKMcAsrOyT
GSz0NUCo0a21gE8obmzwVuyd4+T33fURO6FOGlgduE7PuaMDMQBELqzCBsIs+cO3feadIA
2AFdw/LgKzKfIZ8oSwp3oi7T8O36+wd5CkYaMU6avvRs/cKk0aUbgyhvW8zRQOJsHt6dGJ
7a4alWTU3e1NZYsthuvX10Xw==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 4b00a024
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Sat, 30 Dec 2023 13:37:52 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
In-Reply-To: <83mstt5hrk.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 29 Dec
2023 14:13:03 +0200")
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN>
<87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN>
<877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN>
<87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN>
<87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN>
Date: Sat, 30 Dec 2023 13:37:50 +0100
Message-ID: <87frzjvpb5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Manuel Giraud <manuel@HIDDEN>
>> Cc: 68006 <at> debbugs.gnu.org
>> Date: Fri, 29 Dec 2023 12:11:44 +0100
>>
>> What about this new patch? It works for me as intended but might need
>> better names and better docs. Thanks.
>>
>> +(defcustom image-mode-eager-cache-flush t
>> + "Non-nil means flush image from cache eagerly.
>> +When set to nil, be aware that the image cache could grow fast
>> +but an image previously displayed will show faster."
>
> This doc string should explain the effects better, in terms of
> user-facing behavior, not in terms of technical aspects of the code.
And here is a new version of the patch. Maybe, we need a NEWS entry for
this too.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Add-some-user-control-in-image-mode-caching.patch
From 49f1af6333b90a700c52fd4845583c0506d14795 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@HIDDEN>
Date: Fri, 29 Dec 2023 11:48:21 +0100
Subject: [PATCH] Add some user control in image-mode caching
Bug#68006
* lisp/image-mode.el (image-mode-eager-cache-flush): New custom.
(image-toggle-display-image): Add a contents hash in image spec
when flushing cache lazily.
* lisp/image/image-dired-util.el (image-dired-thumb-name):
* lisp/image.el (image-contents-sha1): Move
'image-dired-contents-sha1' to 'image-contents-sha1' in toplevel
image library.
---
lisp/image-mode.el | 20 ++++++++++++++++++--
lisp/image.el | 11 ++++++++++-
lisp/image/image-dired-util.el | 8 +-------
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index d5ca6348c92..68be3faaae7 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -93,6 +93,16 @@ image-auto-resize-on-window-resize
:version "27.1"
:group 'image)
+(defcustom image-mode-eager-cache-flush t
+ "Non-nil means an image is flushed from the cache before being
+read again. When set to nil, an image spec is not removed from
+the cache so it will be displayed faster the second time.
+
+See `image-cache-eviction-delay'."
+ :type 'boolean
+ :version "30.1"
+ :group 'image)
+
(defvar-local image-transform-resize nil
"The image resize operation.
Non-nil to resize the image upon first display.
@@ -954,8 +964,14 @@ image-toggle-display-image
(plist-put (cdr image) :width
(plist-get (cdr image) :max-width)))))
- ;; Discard any stale image data before looking it up again.
- (image-flush image)
+ (if image-mode-eager-cache-flush
+ ;; Discard any stale image data before looking it up again.
+ (image-flush image)
+ ;; Add a content based hash into image spec to be sure that the
+ ;; cache is updated should the on disk image change.
+ (when (and filename (file-exists-p filename))
+ (setq image (append image (list :hash (image-contents-sha1 filename))))))
+
(setq image (append image (image-transform-properties image)))
(setq props
`(display ,image
diff --git a/lisp/image.el b/lisp/image.el
index e20fbcf4c98..0f1c74d9250 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -401,7 +401,16 @@ image-type-from-file-name
;; If nothing seems to be supported, return first type that matched.
(or first (setq first type))))))))
- ;;;###autoload
+;;;###autoload
+(defun image-contents-sha1 (filename)
+ "Compute the SHA-1 of the first 4KiB of FILENAME's contents.
+The first 4KiB does not represent the whole file but was chosen
+because it is fast enough for interactive usage."
+ (with-temp-buffer
+ (insert-file-contents-literally filename nil 0 4096)
+ (sha1 (current-buffer))))
+
+;;;###autoload
(defun image-supported-file-p (file)
"Say whether Emacs has native support for displaying TYPE.
The value is a symbol specifying the image type, or nil if type
diff --git a/lisp/image/image-dired-util.el b/lisp/image/image-dired-util.el
index e17cc6c919f..e5f526fec57 100644
--- a/lisp/image/image-dired-util.el
+++ b/lisp/image/image-dired-util.el
@@ -59,12 +59,6 @@ image-dired-dir
(message "Thumbnail directory created: %s" image-dired-dir))
image-dired-dir))
-(defun image-dired-contents-sha1 (filename)
- "Compute the SHA-1 of the first 4KiB of FILENAME's contents."
- (with-temp-buffer
- (insert-file-contents-literally filename nil 0 4096)
- (sha1 (current-buffer))))
-
(defun image-dired-thumb-name (file)
"Return absolute file name for thumbnail FILE.
Depending on the value of `image-dired-thumbnail-storage' and
@@ -99,7 +93,7 @@ image-dired-thumb-name
(concat (md5 (concat "file://" file)) ".png")
(expand-file-name thumbdir (xdg-cache-home))))
(let ((name (if (eq 'sha1-contents image-dired-thumb-naming)
- (image-dired-contents-sha1 file)
+ (image-contents-sha1 file)
;; Defaults to SHA-1 of file name
(sha1 file))))
(cond ((or (eq 'image-dired image-dired-thumbnail-storage)
--
2.43.0
--=-=-=
Content-Type: text/plain
--
Manuel Giraud
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 30 Dec 2023 11:37:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 30 06:37:02 2023
Received: from localhost ([127.0.0.1]:43216 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rJXeI-0000pz-FE
for submit <at> debbugs.gnu.org; Sat, 30 Dec 2023 06:37:02 -0500
Received: from ledu-giraud.fr ([51.159.28.247]:42072)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rJXeE-0000ph-TR
for 68006 <at> debbugs.gnu.org; Sat, 30 Dec 2023 06:37:00 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=sGlKDl14
jr9ewBy4LMcDwcksBbYRTrGbDXYPKnVP0dc=;
h=date:references:in-reply-to:
subject:cc:to:from; d=ledu-giraud.fr; b=aYn3jYIbOHqeL7APPWtcJYNh+dZv9l
EYagaRoVO9OEGTktHNNoZ7vVSrUXLIb+epGOjloY/hRHWEXzeo+JHjDA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=sGlKDl14jr9ewBy4
LMcDwcksBbYRTrGbDXYPKnVP0dc=;
h=date:references:in-reply-to:subject:
cc:to:from; d=ledu-giraud.fr; b=BGZ1Y5e7dI2d5AyFAjZeJSJjuu5O7M9aQUzMN3
k6yggF60t0HMoroHCmoZGausGFBvsZHq8iWCupLEUI4T6+WXz3oX5bVyxhG9qF5EgyEpqJ
V8PShOJNN12uJY99LCryrwbCFWM1qGbvEZ9N4w/iubPD8cmZiniOol1N0B2bYf9DUlX9sJ
wqFLiINLJmpYDOahI4dnFyZtRNdSBp4k8n3K4FW97VySB2DMZvSc4WZZlEMh3KB3u+ek6X
GZJDikl6eFE5itjDEcSzVfygNzCtc4NJ1R4SxG/0AdDJArnUbQcSOG+gkBadGl4OM3AndK
MbwmiwjF1xU7r6SqG2rVRcyA==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 52b8891c
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Sat, 30 Dec 2023 12:36:56 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
In-Reply-To: <83mstt5hrk.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 29 Dec
2023 14:13:03 +0200")
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN>
<87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN>
<877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN>
<87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN>
<87wmsxmff3.fsf@HIDDEN> <83mstt5hrk.fsf@HIDDEN>
Date: Sat, 30 Dec 2023 12:36:54 +0100
Message-ID: <87y1db3ort.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
[...]
>> - ;; Discard any stale image data before looking it up again.
>> - (image-flush image)
>> + (if image-mode-eager-cache-flush
>> + ;; Discard any stale image data before looking it up again.
>> + (image-flush image)
>> + ;; Add a content based hash into image spec to be sure that the
>> + ;; cache is updated should the on disk image change.
>> + (when (and filename (file-exists-p filename))
>> + (setq image (append image (list :hash (image-contents-sha1 filename))))))
>> +
>
> I'm probably missing something: how would this assure that if the
> image file is replaced, we re-read it from disk?
The logic goes like this:
- I compute a new hash of the content on disk
- This hash is add to the spec
- Now a key in the image cache is computed for this spec
(i.e. filename, size and *hash* included)
- If the hash was changed the cache will miss and read the new image
content. If hash and size had not changed the cache will hit and
return the correct image.
Is it more clear? Or maybe I do not answer your question?
I'll try to address your other remarks in a new version of this patch.
--
Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 29 Dec 2023 12:13:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 29 07:13:39 2023 Received: from localhost ([127.0.0.1]:40862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rJBkA-0004eN-FI for submit <at> debbugs.gnu.org; Fri, 29 Dec 2023 07:13:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rJBjt-0004dv-VT for 68006 <at> debbugs.gnu.org; Fri, 29 Dec 2023 07:13:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rJBjo-0006Xa-2v; Fri, 29 Dec 2023 07:13:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wjdI58Iwc6yDlSGv5OCUica7CLoD2PTrzn370Pms5OQ=; b=BgNID3qc+VgK C1DKYvsu98bniB25WRP2DkwCmbndhntM9irXNQjEOc1mTnz4vvD0+zFg9nCLk9BVnJfTUD2JEPV97 fWCRqc2hrJSmJJFtE0OGpTcxu8FwSysqgHsdY5NC0QqKPgagnUftKMUXewrju5erOkMWiCh4Kj2rh ZnJDUkR2UuMaeGDd+CULdEbpLfAmehxk+KUucK99fHsm/CEKnGHQpcnqY9xLlE4aopleie0Zq3Kv5 rKL1+XrLDF+MfJrcRLizSan9yC32DW+0cxcLX6ISdlUQ0ibFsk7oqVWu9wYHopgi4La4rGzNjIa0Z hCAFVsYNI354O9ija6neOw==; Date: Fri, 29 Dec 2023 14:13:03 +0200 Message-Id: <83mstt5hrk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87wmsxmff3.fsf@HIDDEN> (message from Manuel Giraud on Fri, 29 Dec 2023 12:11:44 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN> <87wmsxmff3.fsf@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Fri, 29 Dec 2023 12:11:44 +0100 > > What about this new patch? It works for me as intended but might need > better names and better docs. Thanks. > > +(defcustom image-mode-eager-cache-flush t > + "Non-nil means flush image from cache eagerly. > +When set to nil, be aware that the image cache could grow fast > +but an image previously displayed will show faster." This doc string should explain the effects better, in terms of user-facing behavior, not in terms of technical aspects of the code. > - ;; Discard any stale image data before looking it up again. > - (image-flush image) > + (if image-mode-eager-cache-flush > + ;; Discard any stale image data before looking it up again. > + (image-flush image) > + ;; Add a content based hash into image spec to be sure that the > + ;; cache is updated should the on disk image change. > + (when (and filename (file-exists-p filename)) > + (setq image (append image (list :hash (image-contents-sha1 filename)))))) > + I'm probably missing something: how would this assure that if the image file is replaced, we re-read it from disk? > +(defun image-contents-sha1 (filename) > + "Compute the SHA-1 of the first 4KiB of FILENAME's contents. The > +first 4KiB does not represent the whole file but was chosen > +because it is fast enough for interactive usage." The first line of a doc string should be a single complete sentence. Thanks.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 29 Dec 2023 11:11:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 29 06:11:51 2023
Received: from localhost ([127.0.0.1]:40806 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rJAmN-0000xR-1T
for submit <at> debbugs.gnu.org; Fri, 29 Dec 2023 06:11:51 -0500
Received: from ledu-giraud.fr ([51.159.28.247]:14532)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rJAmK-0000xH-RL
for 68006 <at> debbugs.gnu.org; Fri, 29 Dec 2023 06:11:50 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=ymVTTx7b
VqRs9QONUHgejgUCuICB4RyGmglMIyAn3M0=;
h=date:references:in-reply-to:
subject:cc:to:from; d=ledu-giraud.fr; b=iUHnFmkrgaZwFn1sKWwP6E5NVjTd7M
Jh9XM5vxH5vSCleVlXujTinzfSCK1gMoXRdHyV8nFpH4YPbB1kB3EZBg==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=ymVTTx7bVqRs9QON
UHgejgUCuICB4RyGmglMIyAn3M0=;
h=date:references:in-reply-to:subject:
cc:to:from; d=ledu-giraud.fr; b=qdkeGK/yZEAir3RFVVy2AgYaF1RqDTfjeXwzfI
hwmMf2xjRPsbXzNqdFLwTNhnsRYJwlMdFo9Jm8zJEnaJ5zTmj4y/aARa/sukcjRApvcF/1
f0OEbp7h/g1fw6PA0MMUA5mcFCpznYt9eAWCSKhsL8YfAY24OQoHiY6/tf+7RIgeP0gg3/
zC/Lai4R1bFXz8lXi81JwTrwAzKfZPE7FX5IlSpvjUHd5T93DsOBzBFhJ+OnWtGg2xHol3
wohL3CxtMZ24vzPiR8QBKEAB29IeMFoEYSrCp1uqag7GAmmkd/RjikEPapHX1aUuhu2rIj
lwG2KlJUQWBR/ctlO6hXIVzA==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 5bd0795d
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Fri, 29 Dec 2023 12:11:45 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
In-Reply-To: <83o7eb938y.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 27 Dec
2023 15:36:13 +0200")
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN>
<87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN>
<877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN>
<87zfxvalnq.fsf@HIDDEN> <83o7eb938y.fsf@HIDDEN>
Date: Fri, 29 Dec 2023 12:11:44 +0100
Message-ID: <87wmsxmff3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Manuel Giraud <manuel@HIDDEN>
>> Cc: 68006 <at> debbugs.gnu.org
>> Date: Wed, 27 Dec 2023 13:13:13 +0100
>>
>> I was comtemplating the idea of using 'image-dired-contents-sha1' to
>> ensure that the image contents has not changed on disk. But then I
>> asked myself if a function "give me a unique id of this file based on
>> its content" does not already exist in Emacs. I could not found one but
>> maybe we could create one (eg. file-unique-identifier)?
>>
>> Or do you prefer to keep this into the image library? In which case,
>> i'll move this function to "image.el" or "image-mode.el".
>
> I think for now it should be kept in the image library, yes. I don't
> quite see why it would be needed for other files (if it was, we would
> have had it already by now).
Hi Eli,
What about this new patch? It works for me as intended but might need
better names and better docs. Thanks.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Add-some-user-control-in-image-mode-caching.patch
From c131c03dafedbdaa9035c95386a081c452f00934 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@HIDDEN>
Date: Fri, 29 Dec 2023 11:48:21 +0100
Subject: [PATCH] Add some user control in image-mode caching
* lisp/image-mode.el (image-mode-eager-cache-flush): New custom.
(image-toggle-display-image): Add a contents hash in image spec
when flushing cache lazily.
* lisp/image/image-dired-util.el (image-dired-thumb-name):
* lisp/image.el (image-contents-sha1): Move
'image-dired-contents-sha1' to 'image-contents-sha1' in toplevel
image library.
---
lisp/image-mode.el | 18 ++++++++++++++++--
lisp/image.el | 11 ++++++++++-
lisp/image/image-dired-util.el | 8 +-------
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index d5ca6348c92..bad6624bc96 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -93,6 +93,14 @@ image-auto-resize-on-window-resize
:version "27.1"
:group 'image)
+(defcustom image-mode-eager-cache-flush t
+ "Non-nil means flush image from cache eagerly.
+When set to nil, be aware that the image cache could grow fast
+but an image previously displayed will show faster."
+ :type 'boolean
+ :version "30.1"
+ :group 'image)
+
(defvar-local image-transform-resize nil
"The image resize operation.
Non-nil to resize the image upon first display.
@@ -954,8 +962,14 @@ image-toggle-display-image
(plist-put (cdr image) :width
(plist-get (cdr image) :max-width)))))
- ;; Discard any stale image data before looking it up again.
- (image-flush image)
+ (if image-mode-eager-cache-flush
+ ;; Discard any stale image data before looking it up again.
+ (image-flush image)
+ ;; Add a content based hash into image spec to be sure that the
+ ;; cache is updated should the on disk image change.
+ (when (and filename (file-exists-p filename))
+ (setq image (append image (list :hash (image-contents-sha1 filename))))))
+
(setq image (append image (image-transform-properties image)))
(setq props
`(display ,image
diff --git a/lisp/image.el b/lisp/image.el
index e20fbcf4c98..072549aa88f 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -401,7 +401,16 @@ image-type-from-file-name
;; If nothing seems to be supported, return first type that matched.
(or first (setq first type))))))))
- ;;;###autoload
+;;;###autoload
+(defun image-contents-sha1 (filename)
+ "Compute the SHA-1 of the first 4KiB of FILENAME's contents. The
+first 4KiB does not represent the whole file but was chosen
+because it is fast enough for interactive usage."
+ (with-temp-buffer
+ (insert-file-contents-literally filename nil 0 4096)
+ (sha1 (current-buffer))))
+
+;;;###autoload
(defun image-supported-file-p (file)
"Say whether Emacs has native support for displaying TYPE.
The value is a symbol specifying the image type, or nil if type
diff --git a/lisp/image/image-dired-util.el b/lisp/image/image-dired-util.el
index e17cc6c919f..e5f526fec57 100644
--- a/lisp/image/image-dired-util.el
+++ b/lisp/image/image-dired-util.el
@@ -59,12 +59,6 @@ image-dired-dir
(message "Thumbnail directory created: %s" image-dired-dir))
image-dired-dir))
-(defun image-dired-contents-sha1 (filename)
- "Compute the SHA-1 of the first 4KiB of FILENAME's contents."
- (with-temp-buffer
- (insert-file-contents-literally filename nil 0 4096)
- (sha1 (current-buffer))))
-
(defun image-dired-thumb-name (file)
"Return absolute file name for thumbnail FILE.
Depending on the value of `image-dired-thumbnail-storage' and
@@ -99,7 +93,7 @@ image-dired-thumb-name
(concat (md5 (concat "file://" file)) ".png")
(expand-file-name thumbdir (xdg-cache-home))))
(let ((name (if (eq 'sha1-contents image-dired-thumb-naming)
- (image-dired-contents-sha1 file)
+ (image-contents-sha1 file)
;; Defaults to SHA-1 of file name
(sha1 file))))
(cond ((or (eq 'image-dired image-dired-thumbnail-storage)
--
2.43.0
--=-=-=
Content-Type: text/plain
--
Manuel Giraud
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 27 Dec 2023 13:37:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 27 08:37:03 2023 Received: from localhost ([127.0.0.1]:35531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rIU5n-0008Hi-9h for submit <at> debbugs.gnu.org; Wed, 27 Dec 2023 08:37:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rIU5l-0008HA-59 for 68006 <at> debbugs.gnu.org; Wed, 27 Dec 2023 08:37:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rIU5R-0002Vz-S5; Wed, 27 Dec 2023 08:36:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=x/ntuj/+VQTZk5LPdyfblFLgA8SFD8nEHgabwuUZJE4=; b=cBSy6aCXnZCp IRbL6fLJNOPDzwC95S/owhLawEgTmo/+UUQOCYasU2+oYTZukfVPq3H8Mpn0oVdtwTPIL1+1DpS9Y vmtcaT8aoTm8XgvTUGkdehFE2Otl4NIlbn4ts99r57rM3ZS8oiq1UEVSzFKPnJZWh2/xbR/THVM++ H2PfRLUE5pgGt5T/t0RQPcHrWabFNRPEk/EIExYIdVO0jBZkHMozRMAwzgu3kMdKDab/nY5xA5r0/ 7xBroV+dGkmeTjZW/r+NUvqBtdmom8KpEw+TCZZzgDcmz0gB7vx0HdsQQKlctq/ZMxW/bTAkB4/70 UFV8xXyBDTGOQuzAJRNaLg==; Date: Wed, 27 Dec 2023 15:36:13 +0200 Message-Id: <83o7eb938y.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87zfxvalnq.fsf@HIDDEN> (message from Manuel Giraud on Wed, 27 Dec 2023 13:13:13 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> <87zfxvalnq.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Wed, 27 Dec 2023 13:13:13 +0100 > > I was comtemplating the idea of using 'image-dired-contents-sha1' to > ensure that the image contents has not changed on disk. But then I > asked myself if a function "give me a unique id of this file based on > its content" does not already exist in Emacs. I could not found one but > maybe we could create one (eg. file-unique-identifier)? > > Or do you prefer to keep this into the image library? In which case, > i'll move this function to "image.el" or "image-mode.el". I think for now it should be kept in the image library, yes. I don't quite see why it would be needed for other files (if it was, we would have had it already by now). Thanks.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 27 Dec 2023 12:13:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 27 07:13:17 2023 Received: from localhost ([127.0.0.1]:35460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rISmi-0007Mt-Pv for submit <at> debbugs.gnu.org; Wed, 27 Dec 2023 07:13:17 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:10802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rISmh-0007Mk-1A for 68006 <at> debbugs.gnu.org; Wed, 27 Dec 2023 07:13:16 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=PwLZSm+7 ZH7xDwpa8SuaynST884xBPQvFS3wq/M+eo0=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=6hX8iP4rY2VXvWAzJOVVwT3oqBaVrt isu3ssPjagKL/p4/DVLvvvpeEKJD6vwQd4lE2wAIuurXdD1vFehVygAw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=PwLZSm+7ZH7xDwpa 8SuaynST884xBPQvFS3wq/M+eo0=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=v6gkkb5Od0pjEO4FfL20WtRYb0DUsrvAZnfY11 gBEqlMpwwHjoj1AHYyOEl97nj5OvaRpsd7p23YyoWUKBfRQMcCjtLVlx1pFMofCtvlWltx SfozY6BKCrAP0HTSgn6Oq7HG4c0UXpj/76ugzryJ4uXJNQi71SBefYZPqKBJqQuejT7XNy 1/hni8MPm6JqneTmXR9Rxv3d2AzzLqjtXFXQzqbYX4hf739EMNInCw6YoYChR/GaWW88Kl lA+HW9H1TpWgtTiJhCAgjB6ClCjocxEWz5vvjCvwVq00reAd5nPjakXQK1tGOaoBscUjEC V8UghFX4QcNMtTT2HXGqLZ6g== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 815d631c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 27 Dec 2023 13:13:14 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83y1dg954u.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 26 Dec 2023 20:43:13 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> <83y1dg954u.fsf@HIDDEN> Date: Wed, 27 Dec 2023 13:13:13 +0100 Message-ID: <87zfxvalnq.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] >> For image-dired, there is 'image-dired-contents-sha1'. Maybe this the >> one you thought about? > > Probably. Hi Eli, I was comtemplating the idea of using 'image-dired-contents-sha1' to ensure that the image contents has not changed on disk. But then I asked myself if a function "give me a unique id of this file based on its content" does not already exist in Emacs. I could not found one but maybe we could create one (eg. file-unique-identifier)? Or do you prefer to keep this into the image library? In which case, i'll move this function to "image.el" or "image-mode.el". -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 26 Dec 2023 18:43:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 26 13:43:38 2023 Received: from localhost ([127.0.0.1]:35040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rICOv-0007Yb-RY for submit <at> debbugs.gnu.org; Tue, 26 Dec 2023 13:43:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rICOu-0007YP-HK for 68006 <at> debbugs.gnu.org; Tue, 26 Dec 2023 13:43:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rICOq-0008ED-Ak; Tue, 26 Dec 2023 13:43:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MZavMOOoY36wzgYfyRplqp7PgCDHpOzRZeutCI96E+A=; b=OMt/IPU8XWyT sDrrw2R7ga8kmCovyVMu9XwoIM3MaFoW9hARg0JSpsadFCEYvCPjFHrc5n3PGLtDhzhxcQGZuBobZ uRPlSvZZ5NK+6TlUJ2XD5X1lz7ReYFDMdbCPVmrKN1lrdTHvVuiBa2btnFkHNFGOEbm8yT1v2x+LG J9mU1eQdUDby3HQK/id5/iAL0Lc3kMZjwZ+4avZx+GA1Gdr0L1eIUZkfsVjaZ7BRMyfyQj9p/4Jdy W2s7ob0uXppAllls/hXFgv//dlUbeMWxyhtInyiTZW9tJLEO8YPMyBxkFDeuxnQHSZ4MYhLxfMPf1 hnFWLk82qoe/0WKGisKU3Q==; Date: Tue, 26 Dec 2023 20:43:13 +0200 Message-Id: <83y1dg954u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <877cl0zvln.fsf@HIDDEN> (message from Manuel Giraud on Tue, 26 Dec 2023 19:07:00 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> <877cl0zvln.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Tue, 26 Dec 2023 19:07:00 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The comparison with times-less-p is also risky: what if someone > > replaces the image file with an older file? > > I don't understand what the risk is here? It is just a cache. The risk is that you won't notice the fact that the image file was replaced. > > I'd trust some kind of file checksum better, which we will have to > > store alongside the image spec or as part of it. (Don't we already do > > something like that somewhere in image-*.el files?) > > For image-dired, there is 'image-dired-contents-sha1'. Maybe this the > one you thought about? Probably.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 26 Dec 2023 18:07:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 26 13:07:05 2023 Received: from localhost ([127.0.0.1]:35012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rIBpZ-0001Qh-IX for submit <at> debbugs.gnu.org; Tue, 26 Dec 2023 13:07:05 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:30175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rIBpW-0001QD-OY for 68006 <at> debbugs.gnu.org; Tue, 26 Dec 2023 13:07:04 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=Z2f22vuQ 1kJxXG2LFn7whO610MNGk0+GG9JiWHJl0V8=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=n0JEG86iwbhA2mq/vCwlMzJRvs3y3a YbUw3tlDLSqwplW9gM+9NPejAI39cpXF3ilXWjYY44Pp0QoDJYMY1PBA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=Z2f22vuQ1kJxXG2L Fn7whO610MNGk0+GG9JiWHJl0V8=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=QTPpctMRMHMamBM0cewHnZ4zzzNj+gdbpqi1v2 tZr4PxyUvRGNMxtK9/Exr27KKGckWJwTAilC8pngxH1tRXaR8wkxDlahFenpH+1gh6qc/1 vuEKdcgKbfQQIjseLC6WkbIa4jENamKkfJS0iAeJE4I+n8pV1hSO8ajRjdFD2Vq/u5ZEu2 EeApeg7rzoDPslj0rYY5asNQjPYwCghS4UQdn6XZS/dQJGX95KI1IjBDNdexp2C8ObRKym ZB0T3R6XEfoVB0rvgMy/DAd9wE+LYlIARwTAXGjDQGjnnIEkCCY2avvIaQZJbo0bK8P7Mr FAqlhv9GYelXu+dCM5r64H6w== Received: from computer (2630.fr [82.65.148.221]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 7f0c6325 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 26 Dec 2023 19:07:02 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <8334voanr1.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 26 Dec 2023 19:15:46 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> <8334voanr1.fsf@HIDDEN> Date: Tue, 26 Dec 2023 19:07:00 +0100 Message-ID: <877cl0zvln.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] > Using img->timestamp is not reliable enough, since that timestamp is > updated each time we call prepare_image_for_display, which can happen > many times during a session for the same image, and not necessarily > for actually displaying the image in a window. For example, AFAICT if > you move across an image with C-n/C-p, we update the time stamp each > time vertical motion crosses the screen line with the image. So I > think we'd need to store the file's time stamp or some other > signature. Right. > The comparison with times-less-p is also risky: what if someone > replaces the image file with an older file? I don't understand what the risk is here? It is just a cache. > I'd trust some kind of file checksum better, which we will have to > store alongside the image spec or as part of it. (Don't we already do > something like that somewhere in image-*.el files?) For image-dired, there is 'image-dired-contents-sha1'. Maybe this the one you thought about? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at 68006) by debbugs.gnu.org; 26 Dec 2023 17:31:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 26 12:31:56 2023
Received: from localhost ([127.0.0.1]:34897 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rIBHX-0003aA-Jj
for submit <at> debbugs.gnu.org; Tue, 26 Dec 2023 12:31:56 -0500
Received: from ledu-giraud.fr ([51.159.28.247]:11871)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rIBHV-0003Zz-3I
for 68006 <at> debbugs.gnu.org; Tue, 26 Dec 2023 12:31:54 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=NTymdhPU
4PYbhaMzMQUSgDEcBrbDuJLxfI/NOdnISa8=;
h=date:references:in-reply-to:
subject:cc:to:from; d=ledu-giraud.fr; b=aFEXtcSRVvHfjwxGwC+Q98Rch/jxzm
ic8hps9xC+XFJjBh2S4xADkFd7kFZYndaxGkX7deSQJUELf0mwZNtFDw==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=NTymdhPU4PYbhaMz
MQUSgDEcBrbDuJLxfI/NOdnISa8=;
h=date:references:in-reply-to:subject:
cc:to:from; d=ledu-giraud.fr; b=U11NZbeDl9HLIrrnOkL5TBBaXWldke2I7mrQh3
Ye6jhu5fGJuNE5IfjBNCRJGw1GiYpHjItCgoGNCbzDwD+e4AbydQlJUUhTXCxQMVbLbwLP
JjO0kPXpBUZ5AcIdD9m9DyCWXvT+D4Wi2UhxXnC7Z2qpjqVB2q6tEjvPXdM8vPAyDS5bEi
Puvb/U2MrZ9i/CsUs68gjct4UzC3HxrbMjSL0+oxiSXHXpYOJkXin6mU05RVjiaw7N5ICB
CCfDGPrm0Q/OGpr+PkiigzA+fQBWCQmOH3hr4Hc1yH7IfEb7i9su9hnSIPgWrpvw6OUCP8
IyZCjtrWemkFKYchirKQnPeg==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 9dc08124
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Tue, 26 Dec 2023 15:45:13 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68006: 30.0.50; Image-mode speed
In-Reply-To: <83bkae9j11.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 25 Dec
2023 21:30:50 +0200")
References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN>
<87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN>
<87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN>
Date: Tue, 26 Dec 2023 15:45:11 +0100
Message-ID: <87bkadyqdk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 68006
Cc: 68006 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Manuel Giraud <manuel@HIDDEN>
>> Cc: 68006 <at> debbugs.gnu.org
>> Date: Mon, 25 Dec 2023 19:59:10 +0100
>>
>> About being sure to display the file on disk, maybe we could call
>> 'image-flush' only if the file has changed since its display. WDYT?
>
> Provided that the check is reliable, I guess so.
>
> In any case, I think we should be cautious and leave a knob to get
> back the old behavior, in case there are some situations we don't
> anticipate that need to flush the caches.
Hi,
What do you think of this? Of course, it will need a NEWS entry but I
wanted to polish it first. I have made it opt-in. I have used it a bit
the cache could grow fast but I find it quite pleasant to use (for
Docview also).
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Add-some-user-control-on-image-caching.patch
From 4f941c1fe7bc91b121f305b3a3239cf9a3944a6b Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@HIDDEN>
Date: Tue, 26 Dec 2023 15:35:17 +0100
Subject: [PATCH] Add some user control on image caching
* lisp/image-mode.el (image-eager-flush): New custom to control
image cache flush.
(image-toggle-display-image): Flush image upon on file disk
change.
* src/image.c (Fimage_timestamp): New function to access image
display timestamp.
---
lisp/image-mode.el | 16 ++++++++++++++--
src/image.c | 25 +++++++++++++++++++++++++
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index d5ca6348c92..ccea96ecc26 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -93,6 +93,12 @@ image-auto-resize-on-window-resize
:version "27.1"
:group 'image)
+(defcustom image-eager-flush t
+ "Non-nil means flush image from cache eagerly."
+ :type 'boolean
+ :version "30.1"
+ :group 'image)
+
(defvar-local image-transform-resize nil
"The image resize operation.
Non-nil to resize the image upon first display.
@@ -954,8 +960,14 @@ image-toggle-display-image
(plist-put (cdr image) :width
(plist-get (cdr image) :max-width)))))
- ;; Discard any stale image data before looking it up again.
- (image-flush image)
+ ;; Discard image data if its file has changed on disk.
+ (when (or image-eager-flush
+ (and filename
+ (time-less-p
+ (image-timestamp image)
+ (file-attribute-modification-time
+ (file-attributes filename)))))
+ (image-flush image))
(setq image (append image (image-transform-properties image)))
(setq props
`(display ,image
diff --git a/src/image.c b/src/image.c
index 651ec0b34e5..3c2697d1e6f 100644
--- a/src/image.c
+++ b/src/image.c
@@ -1650,6 +1650,30 @@ DEFUN ("image-metadata", Fimage_metadata, Simage_metadata, 1, 2, 0,
return ext;
}
+DEFUN ("image-timestamp", Fimage_timestamp, Simage_timestamp, 1, 2, 0,
+ doc: /* Return the time in seconds at which the image SPEC was
+last displayed.
+
+FRAME is the frame on which the image was displayed. FRAME nil or
+omitted means use the selected frame. */)
+ (Lisp_Object spec, Lisp_Object frame)
+{
+ Lisp_Object timestamp;
+
+ timestamp = Qnil;
+ if (valid_image_p (spec))
+ {
+ struct frame *f = decode_window_system_frame (frame);
+ ptrdiff_t id = lookup_image (f, spec, -1);
+ struct image *img = IMAGE_FROM_ID (f, id);
+
+ if (img)
+ timestamp = make_lisp_time (img->timestamp);
+ }
+
+ return timestamp;
+}
+
/***********************************************************************
Image type independent image structures
@@ -12908,6 +12932,7 @@ syms_of_image (void)
defsubr (&Simage_size);
defsubr (&Simage_mask_p);
defsubr (&Simage_metadata);
+ defsubr (&Simage_timestamp);
defsubr (&Simage_cache_size);
defsubr (&Simagep);
--
2.43.0
--=-=-=
Content-Type: text/plain
--
Manuel Giraud
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 26 Dec 2023 17:16:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 26 12:16:13 2023 Received: from localhost ([127.0.0.1]:34872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rIB2K-0000TX-Pk for submit <at> debbugs.gnu.org; Tue, 26 Dec 2023 12:16:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rIB2I-0000LG-Ga for 68006 <at> debbugs.gnu.org; Tue, 26 Dec 2023 12:16:11 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rIB2E-0002Qs-A4; Tue, 26 Dec 2023 12:16:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gdqUIvnxpOV7/81jd+QIOI+1XyqBoMXNb/b/ZgwOQ5c=; b=bdARTC8t5nwB aiqXDxDHEPy3kP0xXvrAO7X+1ZN4bXZCPWMUZdGAWRRcMQMTCcKM62QEIyvxyXUJesBOX7jkoQ8Vz kMatFY6pQmnl+mkCtRJZx6TTqfkn18GgJOXQhJT7YVqzGmjocLpmCYgMstJ59dbySc3frKzT7gqPt UD4e4CZqJQLqnCKGkqlGew/HjeanSUeQ8D64MdO0qNYZ5l+kmDw8Rm0ezAa9pwJ0RtBXuhFszS6QF s83LHdZzGHL6+MxD2wPMyTaOHbhaIcM/YK9qha7wkmB5N/20t7amAYLbRz8liiCIW1jR4n9lPflof 5FsCp50osRnoOTc9N37nKA==; Date: Tue, 26 Dec 2023 19:15:46 +0200 Message-Id: <8334voanr1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87bkadyqdk.fsf@HIDDEN> (message from Manuel Giraud on Tue, 26 Dec 2023 15:45:11 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> <83bkae9j11.fsf@HIDDEN> <87bkadyqdk.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Tue, 26 Dec 2023 15:45:11 +0100 > > >> About being sure to display the file on disk, maybe we could call > >> 'image-flush' only if the file has changed since its display. WDYT? > > > > Provided that the check is reliable, I guess so. > > > > In any case, I think we should be cautious and leave a knob to get > > back the old behavior, in case there are some situations we don't > > anticipate that need to flush the caches. > > Hi, > > What do you think of this? Of course, it will need a NEWS entry but I > wanted to polish it first. I have made it opt-in. I have used it a bit > the cache could grow fast but I find it quite pleasant to use (for > Docview also). Using img->timestamp is not reliable enough, since that timestamp is updated each time we call prepare_image_for_display, which can happen many times during a session for the same image, and not necessarily for actually displaying the image in a window. For example, AFAICT if you move across an image with C-n/C-p, we update the time stamp each time vertical motion crosses the screen line with the image. So I think we'd need to store the file's time stamp or some other signature. The comparison with times-less-p is also risky: what if someone replaces the image file with an older file? I'd trust some kind of file checksum better, which we will have to store alongside the image spec or as part of it. (Don't we already do something like that somewhere in image-*.el files?)
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 25 Dec 2023 19:31:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 25 14:31:13 2023 Received: from localhost ([127.0.0.1]:55406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rHqfQ-00043c-Nw for submit <at> debbugs.gnu.org; Mon, 25 Dec 2023 14:31:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rHqfM-0003uO-AU for 68006 <at> debbugs.gnu.org; Mon, 25 Dec 2023 14:31:12 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rHqf8-0003Zl-Tf; Mon, 25 Dec 2023 14:30:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=K9E28L3ptUVgc0nIoQkPG50afLiaBg6NddxB/c2MkBI=; b=PBtdEDcWTrVi DCfXCZKxKIf95O1LsnHxlFlTGJt6AS38IXXL6Vg/6OAX7REq6u6nXuBeB3Gps5jtmsfjJpJwzvcdl 6tjFh4+8RtTYwxBdLW8/nG7Qel0RC+Lb3tNL6q1yDRDys/+ISrRrpIxGfCmT9PNRvlrP69kVcKPIU Z7ZmU5Od+p9/ewOsTvGJILj1XoaG9y6LvP+2pMwDzJYDpROhHzbD+fyc0LNQ3q74oettLzTzYQQQ5 AmZX85BsosbEBjrp3eex+eMoLd2cRDATBIIvFlMNnG9VLDh4Ec+71dlkCdf3MSFQq8E0yE60n6yH0 GQqPboDb3x9LJN3cCWkk/A==; Date: Mon, 25 Dec 2023 21:30:50 +0200 Message-Id: <83bkae9j11.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87il4m6rcx.fsf@HIDDEN> (message from Manuel Giraud on Mon, 25 Dec 2023 19:59:10 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> <87il4m6rcx.fsf@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Mon, 25 Dec 2023 19:59:10 +0100 > > About being sure to display the file on disk, maybe we could call > 'image-flush' only if the file has changed since its display. WDYT? Provided that the check is reliable, I guess so. In any case, I think we should be cautious and leave a knob to get back the old behavior, in case there are some situations we don't anticipate that need to flush the caches.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 25 Dec 2023 18:59:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 25 13:59:25 2023 Received: from localhost ([127.0.0.1]:55381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rHqAf-0003zH-De for submit <at> debbugs.gnu.org; Mon, 25 Dec 2023 13:59:25 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:30248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rHqAa-0003z5-A7 for 68006 <at> debbugs.gnu.org; Mon, 25 Dec 2023 13:59:24 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=FuEHaSMo M6qE+/ROjTUl+tfPXNS6ZTJM+g6y/45IL5s=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=BDYwF9a6G/rKVaqFACgK3HK7Iqtgit 4dW4gRpudPM1OyYz8U3k++ZfuNUdjdwvWzj/lpUAw/ZEwDSaMWzQ/QCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=FuEHaSMoM6qE+/RO jTUl+tfPXNS6ZTJM+g6y/45IL5s=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=zQQIIBgHWL2PIbYCEggDMJn61BJcBjLGwPzzJP JwUJEr1guAYQeLP2J+N4Nv9Zbkc/2+fzVyKqnk0QsUwrrQRUUvhpc7sj6aL09EAhUmER5m 4ixI5XXxGkCQnDQS62wHo9xqfF7CMxVCZdwl12OWyHi2HCWZzCcwpHrit+Puno9oGKE9by ZZdWyCY1jf+Ai2gEHXbWyY+jWWHHXvwVaJeKT3mOsBB4ibTtakEaV3Q5cu/qBUEAZCuvOg FKdrjh1e1pF4gtBejl9Sk/Fr4JnoHFdLfqE1iX5oR4biigdPETTqR8QcHc84qqg1U6zYwL 97t0YqlZ3ZSwRvghXqOCgwGA== Received: from computer (<unknown> [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 026980fb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 25 Dec 2023 19:59:11 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83wmt29zfy.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 25 Dec 2023 15:36:17 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> <83wmt29zfy.fsf@HIDDEN> Date: Mon, 25 Dec 2023 19:59:10 +0100 Message-ID: <87il4m6rcx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] > I think the reason is what I mentioned above. > > You seem to interpret the purpose of the image-cache differently from > its real purpose. The real purpose of the image cache is not to hold > the image in memory for displaying it again and again, the purpose is > to allow the display engine to generate the pixels once, then reuse > those pixels during the current redisplay cycle or a few following > redisplay cycles. That's why we can so easily evict images from the > cache when some time has passed: the cache is ephemeral anyway, and is > intended to serve only as a short-term memory. Ok, I guess I understand this purpose... > When working with external image files, flushing the image cache is a > good measure to make sure we always display the file on disk, not some > previous copy of it. ... but then this does not seem like a good fit for the usage in image-mode. When using 'image-next-file'/'image-previous-file', I imagine that the idea is browse some pictures seamlessly. Removing an image from the cache each time seems to go against this. About being sure to display the file on disk, maybe we could call 'image-flush' only if the file has changed since its display. WDYT? -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 25 Dec 2023 13:36:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 25 08:36:36 2023 Received: from localhost ([127.0.0.1]:54171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rHl8F-0007Hj-Mw for submit <at> debbugs.gnu.org; Mon, 25 Dec 2023 08:36:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rHl8D-0007HV-Q7 for 68006 <at> debbugs.gnu.org; Mon, 25 Dec 2023 08:36:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rHl81-00050t-4I; Mon, 25 Dec 2023 08:36:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Xot8+5pceZYGQ3mGckkxospnhHXqCWbofqkuFxa+VQQ=; b=mdIzKgWroO8D Y7FZOl+zdOddybCMkaZ3UbVFVrRgkevSXjc/HYEpyzgugBZRT17lQqPz7B9MfcgJm+nUf9l5Ysmt4 9OZQHx8NSRGBMFa0gMIHxsnzAgMKk+lma2olI1ZHdeGfyYrvKrRDa9s2KPdjIlqyGSB4R1NU/PeWe ATuk6tzVod4tdnLnJvOBgE05h9kle3LOOLWH/lUGk31LVCVE035W9YX1szx3R2zAmL39hzyNL7yZg WyNBRkjuECR+CiSVsFLM4T0UzEoe6qlFb/F6zlEqg3s+F0c2jM8LY23noeI/yRCU5ey+zEDg8fKz3 umloUmYsH6DWJAzJ0uRflg==; Date: Mon, 25 Dec 2023 15:36:17 +0200 Message-Id: <83wmt29zfy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87h6k6lgdy.fsf@HIDDEN> (message from Manuel Giraud on Mon, 25 Dec 2023 11:34:49 +0100) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> <87h6k6lgdy.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Manuel Giraud <manuel@HIDDEN> > Cc: 68006 <at> debbugs.gnu.org > Date: Mon, 25 Dec 2023 11:34:49 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Look at its Git history, and look up discussions and bugs from those > > times. > > > > AFAIR, one problem is that images can change behind our backs. But > > maybe there are other reasons. > > So I trace this call back to dc255b24e30a (Chong Yidong, 2007-05-21). At > that time 'image-flush' was called 'image-refresh' with the same > functionality of uncaching an image given its spec. > > Before that, the whole image cache was cleared (fcfc4732e0d9, Chong > Yidong, 2006-02-09). I did not find a bug reference and I still don't > understand why it is/was needed. I think the reason is what I mentioned above. You seem to interpret the purpose of the image-cache differently from its real purpose. The real purpose of the image cache is not to hold the image in memory for displaying it again and again, the purpose is to allow the display engine to generate the pixels once, then reuse those pixels during the current redisplay cycle or a few following redisplay cycles. That's why we can so easily evict images from the cache when some time has passed: the cache is ephemeral anyway, and is intended to serve only as a short-term memory. When working with external image files, flushing the image cache is a good measure to make sure we always display the file on disk, not some previous copy of it. If you have a specific application in mind where this cache must be kept for longer times, we could perhaps arrange for that, but we will then also need to make sure images are not evicted from the cache during that time.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 25 Dec 2023 10:35:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 25 05:35:04 2023 Received: from localhost ([127.0.0.1]:54047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rHiIa-0004fI-AN for submit <at> debbugs.gnu.org; Mon, 25 Dec 2023 05:35:04 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:4164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manuel@HIDDEN>) id 1rHiIV-0004el-FR for 68006 <at> debbugs.gnu.org; Mon, 25 Dec 2023 05:35:03 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=M0f+dZn7 jySuGiucYsUqwzyogrfFmS/6f8ZGkmXohRA=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=8WRD9bSisiNn4BvpRGXSOhb9MD0P9F lwONnK5/qU+WMQ38N8J3XcBYpBMzuze7Bc9rEs56uUSR6B99sAb5byBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=M0f+dZn7jySuGiuc YsUqwzyogrfFmS/6f8ZGkmXohRA=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=kdRK8FZBBEMH2l6TATiwFbcbj6vC3JmzHc95Z8 RW6q6bujpDl+HWqy4GejmWA6wwb1s4sb+e1I1ORcRj+XnxXgLkDU9bMabWFkpq3ooR1gth R2Abqj4BuLhIQOTe6sn7kd4P2N0kT8gqjyKtWo0Y5mH1JCXqlW2PdHjhFVnYX90mGafUL4 6edtpmtgh6pS8lJo97uj9+rbKUrn7SMD5gkNP+rcccDBNYQGo8GQEleNFvzAd1K821XO0/ JgMeF/xADivghx8+z7pr5vIWP2HYH1xE9XKWXFYnG/rmZEu7QkqAL+l+ZDYBwOkFeF/O7N bhfqqEfKLD4i65+856BPG4tg== Received: from computer (2630.fr [82.65.148.221]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id bbc4e2ef (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 25 Dec 2023 11:34:50 +0100 (CET) From: Manuel Giraud <manuel@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#68006: 30.0.50; Image-mode speed In-Reply-To: <83wmt3bkla.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 24 Dec 2023 19:01:53 +0200") References: <87le9jlfd6.fsf@HIDDEN> <83wmt3bkla.fsf@HIDDEN> Date: Mon, 25 Dec 2023 11:34:49 +0100 Message-ID: <87h6k6lgdy.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: [...] >> The call to 'image-flush' defeats the entire purpose of having an image >> cache. If I remove it, moving from previous/next is much more faster >> (once this image is in the cache, of course). Do you know why this code >> is like that? > > Look at its Git history, and look up discussions and bugs from those > times. > > AFAIR, one problem is that images can change behind our backs. But > maybe there are other reasons. So I trace this call back to dc255b24e30a (Chong Yidong, 2007-05-21). At that time 'image-flush' was called 'image-refresh' with the same functionality of uncaching an image given its spec. Before that, the whole image cache was cleared (fcfc4732e0d9, Chong Yidong, 2006-02-09). I did not find a bug reference and I still don't understand why it is/was needed. -- Manuel Giraud
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.Received: (at 68006) by debbugs.gnu.org; 24 Dec 2023 17:02:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 24 12:02:17 2023 Received: from localhost ([127.0.0.1]:53466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rHRrk-0004QG-In for submit <at> debbugs.gnu.org; Sun, 24 Dec 2023 12:02:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rHRrh-0004Pw-Mv for 68006 <at> debbugs.gnu.org; Sun, 24 Dec 2023 12:02:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rHRrV-0001m4-Vw; Sun, 24 Dec 2023 12:02:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=f00x4ZJFqfrPj7uX+7wHJIKQAaBgeuW0uf4FUW+M+lw=; b=ha6+EktV1XWS C+UgqhWtTKl/wCaajzviU00B12nsiU8EZI2H8wAA9W66s50mK1Q9XtBvA25BNvl7TrNIycVa1PDrr vN+SxmyX9J3ozjalUOh871BgGSBG9Y1/8P3vQaT1JEkHsxGIQX/AemUZwwhMn/IgfShwvfUSmxe5Q LLfRZhR7KBgao9geSmMjj8qaUJdjxPg1rH8ToAs+YJGtnSMkGeeeYFgM0mDAXzGCoXj/og6LVap2G y/VEGZ0+wc7xwnmpnIcaXC2J6Dx5pk3NYnPAudrSmsfTrsJ02CQsLHTxDsYNAsGkOWa7qryAKkTNV FYzsZLxROrjmbNQ8ymkTZg==; Date: Sun, 24 Dec 2023 19:01:53 +0200 Message-Id: <83wmt3bkla.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Manuel Giraud <manuel@HIDDEN> In-Reply-To: <87le9jlfd6.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#68006: 30.0.50; Image-mode speed References: <87le9jlfd6.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68006 Cc: 68006 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 24 Dec 2023 17:44:37 +0100 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > I was looking into performance issue using image-mode when going from > one image to the next/previous (with 'image-next/previous-file') and I > found those lines in "image-mode.el": > > --8<---------------cut here---------------start------------->8--- > ;; Discard any stale image data before looking it up again. > (image-flush image) > (setq image (append image (image-transform-properties image))) > (setq props > `(display ,image > ;; intangible ,image > rear-nonsticky (display) ;; intangible > read-only t front-sticky (read-only))) > --8<---------------cut here---------------end--------------->8--- > > The call to 'image-flush' defeats the entire purpose of having an image > cache. If I remove it, moving from previous/next is much more faster > (once this image is in the cache, of course). Do you know why this code > is like that? Look at its Git history, and look up discussions and bugs from those times. AFAIR, one problem is that images can change behind our backs. But maybe there are other reasons.
bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 24 Dec 2023 16:44:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 24 11:44:59 2023
Received: from localhost ([127.0.0.1]:53405 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rHRb1-00074b-5a
for submit <at> debbugs.gnu.org; Sun, 24 Dec 2023 11:44:59 -0500
Received: from lists.gnu.org ([2001:470:142::17]:60022)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manuel@HIDDEN>) id 1rHRay-00074K-7R
for submit <at> debbugs.gnu.org; Sun, 24 Dec 2023 11:44:58 -0500
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 <manuel@HIDDEN>)
id 1rHRam-000304-DR
for bug-gnu-emacs@HIDDEN; Sun, 24 Dec 2023 11:44:44 -0500
Received: from ledu-giraud.fr ([51.159.28.247])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <manuel@HIDDEN>)
id 1rHRak-0005q0-2o
for bug-gnu-emacs@HIDDEN; Sun, 24 Dec 2023 11:44:44 -0500
DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=KPLCkRUf
9KrQ8FxbASLNWrW1DseEnfAMYrluJTEwAOA=; h=date:subject:to:from;
d=ledu-giraud.fr;
b=gF1wEl7oTyLfSRqXzl/6vxQcDW1I4CfLIllWvFs8K4IHlRvJEo
JiEqCiZMitMSLRH2JSIrGSbIpovwO4nZ00Bw==
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=KPLCkRUf9KrQ8Fxb
ASLNWrW1DseEnfAMYrluJTEwAOA=; h=date:subject:to:from;
d=ledu-giraud.fr; b=SiLzVldkODMmnj8SXFlx937EO6gcrAN/PxYnaWVFrl2T8eomKa
/GiAOYUbrHjucFvGYcc3xnuwEp2Wof/d4nTgKUJ96oMoRnFPxS1GPTEV/+r0Yq2RRzGXCo
RRtokoYH0NuSOV81exFIK+BswC9nT8nJ2QRhyyByJ1NIzrmha7FUsNFSbHowdlLeUFvaFV
GNh/hxnIs97LHazqJ1XYgkrUBNkNebDoQKi3GOYXhCpb4U/65XHtOVp9XIj2QZeqBjdLnJ
raqKNEaVnhx11M4M3sCUjs6rIPYGn7k808Hxz6hxf0VgH5xYavV5aUOW/d3916MdXuRaQ5
zhuBTnZjF0LA==
Received: from computer (<unknown> [10.1.1.1])
by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 3524267e
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <bug-gnu-emacs@HIDDEN>;
Sun, 24 Dec 2023 17:44:38 +0100 (CET)
From: Manuel Giraud <manuel@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.0.50; Image-mode speed
X-Debbugs-Cc:
Date: Sun, 24 Dec 2023 17:44:37 +0100
Message-ID: <87le9jlfd6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@HIDDEN;
helo=ledu-giraud.fr
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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
Hi,
I was looking into performance issue using image-mode when going from
one image to the next/previous (with 'image-next/previous-file') and I
found those lines in "image-mode.el":
--8<---------------cut here---------------start------------->8---
;; Discard any stale image data before looking it up again.
(image-flush image)
(setq image (append image (image-transform-properties image)))
(setq props
`(display ,image
;; intangible ,image
rear-nonsticky (display) ;; intangible
read-only t front-sticky (read-only)))
--8<---------------cut here---------------end--------------->8---
The call to 'image-flush' defeats the entire purpose of having an image
cache. If I remove it, moving from previous/next is much more faster
(once this image is in the cache, of course). Do you know why this code
is like that?
Best regards,
In GNU Emacs 30.0.50 (build 2, x86_64-unknown-openbsd7.4) of 2023-12-24
built on computer
Repository revision: 13e46e2c1d33a3a48ecdcb56b745dbc53a4a3831
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: OpenBSD computer 7.4 GENERIC.MP#1549 amd64
Configured using:
'configure CC=egcc CPPFLAGS=-I/usr/local/include
LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
--bindir=/home/manuel/bin --with-x-toolkit=no --without-cairo
--without-dbus --without-gconf --without-gsettings --without-sound
--without-compress-install'
Configured features:
FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBXML2
MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TREE_SITTER WEBP X11 XDBE XFT XIM XINPUT2 XPM ZLIB
Important settings:
value of $LC_CTYPE: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: ELisp/l
Minor modes in effect:
bug-reference-prog-mode: t
paredit-mode: t
display-time-mode: t
display-battery-mode: t
desktop-save-mode: t
server-mode: t
override-global-mode: t
repeat-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/manuel/.emacs.d/elpa/ef-themes-1.4.1/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs
Features:
(shadow sort mail-extr emacsbug vc-annotate smerge-mode diff vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util whitespace
image-file image-converter org-agenda org-indent org-element org-persist
org-id avl-tree oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb
ol-w3m ol-doi org-link-doi gnus-icalendar org-capture org-refile org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint
org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys
oc org-loaddefs org-version org-compat org-macs autorevert filenotify
vc-hg sh-script smie treesit executable eww url-queue mm-url mule-util
jka-compr on-screen vc-dir ewoc vc vc-git diff-mode vc-dispatcher
bug-reference paredit gnus-dired time battery cus-load desktop frameset
exwm-randr xcb-randr exwm-config ido exwm exwm-input xcb-keysyms xcb-xkb
exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout
exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types
xcb-debug server modus-operandi-theme modus-themes zone speed-type
url-http url-auth url-gw nsm compat ytdious mingus libmpdee reporter
edebug debug backtrace transmission color calc-bin calc-ext calc
calc-loaddefs rect calc-macs supercite regi ebdb-message ebdb-gnus
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
nnoo gnus-spec gnus-int gnus-range message sendmail yank-media puny
rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums gmm-utils
mailheader gnus-win ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev
eieio-opt speedbar ezimage dframe find-func eieio-base timezone
icalendar gnus nnheader gnus-util mail-utils range mm-util mail-prsvr
wid-edit web-mode derived disp-table erlang-start skeleton cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs slime-asdf grep slime-tramp tramp rx trampver tramp-integration
files-x tramp-message tramp-compat xdg shell pcomplete parse-time
iso8601 time-date format-spec tramp-loaddefs slime-fancy
slime-indentation slime-cl-indent cl-indent slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
apropos compile text-property-search etags fileloop generator xref
project arc-mode archive-mode noutline outline icons pp comint ansi-osc
ansi-color ring hyperspec thingatpt slime-autoloads edmacro kmacro
use-package-bind-key bind-key appt diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs pcase dired-x dired-aux dired dired-loaddefs
cl-extra help-mode use-package-core repeat easy-mmode debbugs-autoloads
ebdb-autoloads ef-themes-autoloads exwm-autoloads hyperbole-autoloads
magit-autoloads git-commit-autoloads magit-section-autoloads
dash-autoloads on-screen-autoloads osm-autoloads paredit-autoloads
rust-mode-autoloads speed-type-autoloads transmission-autoloads
with-editor-autoloads info compat-autoloads ytdious-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads kqueue lcms2 dynamic-setting font-render-setting xinput2 x
multi-tty move-toolbar make-network-process emacs)
Memory information:
((conses 16 793954 635507) (symbols 48 52684 2)
(strings 32 255659 44607) (string-bytes 1 7175025)
(vectors 16 150516) (vector-slots 8 2617297 42627)
(floats 8 567 3230) (intervals 56 20138 6985) (buffers 992 49))
--
Manuel Giraud
Manuel Giraud <manuel@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#68006; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.