unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: mail@jao.io, 56546@debbugs.gnu.org
Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images
Date: Thu, 14 Jul 2022 11:20:53 +0200	[thread overview]
Message-ID: <87mtdcnj7u.fsf@gnus.org> (raw)
In-Reply-To: <83leswt5q1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 12:15:50 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

> When we remove an image from the cache, its animations should also be
> removed, I agree.

The image cache is for displayed images, so an animated image will
usually have dozens of image cache entries, so it doesn't work that way.

> GC could be problematic.  Imagine someone who has a frame displayed at
> all times animating something -- you don't want to clear those caches,
> right?

No, but the cache should be pruned of old entries.  (Which is what the
pruning function does.)

>> Finally, image-cache-size should also report the animation cache size, I
>> think.
>
> That'd help, yes.

Looking at that now, that's easier said than done, because the animation
caches are opaque -- we call out to support libraries, and it doesn't
look like all of them have a way to say how much memory they use.  (I'm
looking at the webp functions right now...)

But we can at least include the size of the main data blob (e.g., the
.webp data itself); we know the size of that for all the anim caches.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2022-07-14  9:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  1:35 bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Jose A. Ortega Ruiz
2022-07-14  5:45 ` Eli Zaretskii
2022-07-14  6:04   ` Eli Zaretskii
2022-07-14  8:53     ` Lars Ingebrigtsen
2022-07-14  9:15       ` Eli Zaretskii
2022-07-14  9:20         ` Lars Ingebrigtsen [this message]
2022-07-14 10:01           ` Lars Ingebrigtsen
2022-07-14 10:10             ` Eli Zaretskii
2022-07-14 10:15               ` Lars Ingebrigtsen
2022-07-14 12:23   ` Jose A. Ortega Ruiz
2022-07-14 16:59 ` Lars Ingebrigtsen
2022-07-14 17:26   ` Eli Zaretskii
2022-07-14 17:51   ` Glenn Morris
2022-07-14 18:08     ` Lars Ingebrigtsen
2022-07-15 23:42   ` Jose A. Ortega Ruiz
2022-07-16 10:37     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtdcnj7u.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=56546@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mail@jao.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).