On Sun, Jan 6, 2013 at 10:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Sun, Jan 6, 2013 at 9:59 PM, Greg Stark <stark@mit.edu> wrote:
>>> I would be more concerned with the file size. You don't want someone
>>> to be able to make an archive page send a hapless viewer a 100M image
>>> file. Luckily file size doesn't require parsing the meta data.
>>>
>>> Can you not deal with the image size by just sticking a css attribute
>>> for max-height and max-width on the inlined image?
>
>> That's certainly another option - limit it by size that way, and then
>> limiting it by filesize for whether we include it or not. We can even
>> give it scrollbars, I guess. That does make even more sense.
>
> A file-size-based limit on what we'll inline seems perfectly sensible
> from here. As for scrollbars, if it's big enough to need those, we
> probably don't want it inline ...
Yeah, I was thinking scrollbars rather than cut. Turns out the
max-width option actually rescales the image, so we're fine.
I've applied a change that makes it now inline all images <75kb, and
rescaling them down to 600 pixels wide if they are bigger.
The example URL you used have been reloaded from the new code, so it
shows what it looks like. Any other pages that had images on them that
were already viewed are currently cached the old way, but will
automatically update once they expire from the cache (max 4 hours).
--Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
