From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68006: 30.0.50; Image-mode speed Date: Tue, 02 Jan 2024 14:49:12 +0200 Message-ID: <83zfxnzyrb.fsf@gnu.org> References: <87le9jlfd6.fsf@ledu-giraud.fr> <83wmt3bkla.fsf@gnu.org> <87h6k6lgdy.fsf@ledu-giraud.fr> <83wmt29zfy.fsf@gnu.org> <87il4m6rcx.fsf@ledu-giraud.fr> <83bkae9j11.fsf@gnu.org> <87bkadyqdk.fsf@ledu-giraud.fr> <8334voanr1.fsf@gnu.org> <877cl0zvln.fsf@ledu-giraud.fr> <83y1dg954u.fsf@gnu.org> <87zfxvalnq.fsf@ledu-giraud.fr> <83o7eb938y.fsf@gnu.org> <87wmsxmff3.fsf@ledu-giraud.fr> <83mstt5hrk.fsf@gnu.org> <87frzjvpb5.fsf@ledu-giraud.fr> <83le9a3kqs.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manuel@ledu-giraud.fr, 68006@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 02 13:50:29 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rKeE1-0006FP-DC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Jan 2024 13:50:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKeDc-0000aB-BS; Tue, 02 Jan 2024 07:50:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rKeDZ-0000Zo-2T for bug-gnu-emacs@gnu.org; Tue, 02 Jan 2024 07:50:01 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rKeDY-0002Pk-QO for bug-gnu-emacs@gnu.org; Tue, 02 Jan 2024 07:50:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rKeDa-0004xm-Nc for bug-gnu-emacs@gnu.org; Tue, 02 Jan 2024 07:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jan 2024 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68006 X-GNU-PR-Package: emacs Original-Received: via spool by 68006-submit@debbugs.gnu.org id=B68006.170419978419040 (code B ref 68006); Tue, 02 Jan 2024 12:50:02 +0000 Original-Received: (at 68006) by debbugs.gnu.org; 2 Jan 2024 12:49:44 +0000 Original-Received: from localhost ([127.0.0.1]:49571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKeDI-0004x2-3R for submit@debbugs.gnu.org; Tue, 02 Jan 2024 07:49:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKeDE-0004wj-Rc for 68006@debbugs.gnu.org; Tue, 02 Jan 2024 07:49:42 -0500 Original-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 ) 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==; In-Reply-To: (message from Stefan Kangas on Mon, 1 Jan 2024 16:19:31 -0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277234 Archived-At: > From: Stefan Kangas > Date: Mon, 1 Jan 2024 16:19:31 -0800 > Cc: manuel@ledu-giraud.fr, 68006@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.