bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu]

Manuel Giraud <manuel@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.