GNU bug report logs - #67810
29.1; fonts use synthetic bold on Linux / pgtk

Previous Next

Package: emacs;

Reported by: Tim Ruffing <crypto <at> timruffing.de>

Date: Wed, 13 Dec 2023 12:05:01 UTC

Severity: normal

Found in version 29.1

Full log


Message #122 received at 67810 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Tim Ruffing <crypto <at> timruffing.de>, Eli Zaretskii <eliz <at> gnu.org>,
 67810 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk
Date: Sun, 14 Jan 2024 22:10:00 +0800
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Yes.  As Eli explained to me in bug#68006 (correct me if I'm wrong), the
> image cache was designed to work with the display engine (for icons and
> toolbars).  For other usage, like image-mode for instance, we might need
> something else.

I understand you haven't made reference to the provisions for
user-specified image caches that you have proposed in that thread, but
it's still relevant that although such provisions will work in
image-mode's favor, they cannot resolve the memory consumption problems
inherent in the practice of caching scaled SVG images in the first
place.

Or on the flip side, performance degradation incurred by calling into
SVG for many dozens of small icons, which are removed from the image
cache after the eviction delay elapses without regard to their size or
the frequency at which they are invoked.

Worse yet, the display connection is cut when the image cache consumes
all bitmap memory allotted by the X server to Emacs.  This generates an
asynchronous Alloc error that Emacs is not in a position to detect until
it next returns to the event loop.

With the size of images as they exist today, and the density of the
devices on which they are displayed, I think that caching complete
images for N number of seconds has become an outmoded solution for not
loading images redundantly.  It's unpleasant for increasing
doc-view-resolution to force you to hold your breath before typing "n"
in a DocView buffer, out of a sense of apprehension that the subsequent
page might be sufficiently large to trigger such an error.




This bug report was last modified 1 year and 152 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.