Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107264: shr.el (shr-rescale-image): Allow viewing large images.

[Lars Ingebrigtsen <larsi@gnus.org>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> By '9gag' do you mean 9gag.com?

Yup.

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

Yeah, it's a laptop with a 1280x800 screen.  I'd guesstimate that about
one fifth of the images from 9gag don't display with the 6.0 default.

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

I think that's probably a better solution than the frame size thing.
Would it affect animated gifs, though?  I mean, currently Emacs doesn't
balk at displaying a 1TB huge animated GIF (or something :-)...

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

I think the limit should be set to something that gives as little
problems to real-world usage as realistic.  6.0 is too small, nil is
unresponsible, and 60.0 is probably too large.  10.0?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome