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

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Po Lu <luangruo@yahoo.com> writes:

> 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.

Yes scaled SVG tend to take much space but in the example you gave (zoom
in and out of a SVG in image-mode), I think it has more to do with the
cache not being adapted for such usage: the fact that an image spec
contains its size and is retain for 300 seconds by default (as you
said).

> 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.

Ok but is there such usage of SVG icons into Emacs?  If there is it
would require a much more smarter cache or, even better, a fast
rasterizer.

> 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.

I've never hit this case but I don't have a high density display.  Is it
something that happen to you regularly?
-- 
Manuel Giraud