emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107264: shr.el (shr-rescale-imag


From: Paul Eggert
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107264: shr.el (shr-rescale-image): Allow viewing large images.
Date: Tue, 14 Feb 2012 00:20:31 -0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0

On 02/13/2012 12:33 PM, Lars Ingebrigtsen wrote:
> the default value of 6.0 disallows a lot of real-world
> images.  (9gag in particular.)  Perhaps binding it to, say, 60.0 in
> shr.el would make sense?

We have to do something.  The recently-changed trunk behavior,
where there's no limit at all, is asking for trouble.
It really needs to get fixed before Emacs 24 comes out.

By '9gag' do you mean 9gag.com?  Currently, its third image
<http://d24w6bsrhbeh9d.cloudfront.net/photo/2611347_460s.jpg>
is 472x4464, which I suppose could run into a problem with
max-image-size being 6.0 if your screen is small.

But 60.0 would be way too large.  A typical frame size for me
is 500x1100, and allowing 30,000x66,000 images would make my
5-year-old desktop (with 2 GiB of RAM) keel over and die.

I suggest the following heuristic instead.  Take the total amount
of physical memory, divide by 64, and reject images
that would consume more than that amount of RAM.
For example, my desktop has 2 GiB of physical RAM, so any image
requiring more than 32 MiB of RAM would be rejected;
this would easily allow the 9gag image mentioned above,
which consumes about 9 MiB assuming 32 bits per pixel.
The divisor "64" is a heuristic that could be user-adjusted;
but the point is that dividing RAM by 64 is a more-useful default
than multiplying the frame size by 6.

If all this is too much trouble, I suggest going back to the 6.0
limit for now, and revisiting this issue after Emacs 24.1 comes out.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]