From: Paul Eggert <eggert@cs.ucla.edu>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Katsumi Yamaoka <yamaoka@jpl.org>,
Stefan Monnier <monnier@IRO.UMontreal.CA>,
emacs-devel@gnu.org
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 [thread overview]
Message-ID: <4F3A194F.8000508@cs.ucla.edu> (raw)
In-Reply-To: <8762fawk1t.fsf@gnus.org>
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.
next prev parent reply other threads:[~2012-02-14 8:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1RwnLm-0007NV-Lm@vcs.savannah.gnu.org>
2012-02-13 13:15 ` [Emacs-diffs] /srv/bzr/emacs/trunk r107264: shr.el (shr-rescale-image): Allow viewing large images Stefan Monnier
2012-02-13 19:57 ` Andy Moreton
2012-02-13 20:03 ` Lars Ingebrigtsen
2012-02-13 20:01 ` [Emacs-diffs] " Lars Ingebrigtsen
2012-02-13 20:29 ` Paul Eggert
2012-02-13 20:33 ` Lars Ingebrigtsen
2012-02-13 20:41 ` Ted Zlatanov
2012-02-15 6:26 ` Chong Yidong
2012-02-15 13:40 ` Ted Zlatanov
2012-02-14 8:20 ` Paul Eggert [this message]
2012-02-14 14:49 ` Lars Ingebrigtsen
2012-02-14 15:56 ` Paul Eggert
2012-02-14 18:26 ` Lars Ingebrigtsen
2012-02-15 6:42 ` Chong Yidong
2012-02-15 6:27 ` Chong Yidong
2012-02-14 17:43 ` Stefan Monnier
2012-02-13 21:24 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F3A194F.8000508@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=yamaoka@jpl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).