Automatic Image Resizing Checked In
Sunday January 19th, 2003
David Illsley writes: "Yesterday saw the checkin of automatic image resizing (bug 73322) to the Mozilla trunk. When turned on (it's disabled by default) it shrinks any image that is bigger than the window to make the whole image visible. When this is done, the cursor over the image changes to tell you that if you click, the image is restored to full size. You get the best of both worlds! This currently doesn't have a prefs UI in Phoenix but if you put the appropriate pref in you user.js file, it works just fine. This is one of the few features in IE that I have seen and liked and it's great that Moz now has it too. Thanks guys."
To enable this feature in Mozilla, go to Edit > Preferences > Appearance and check the 'Enable automatic image resizing' box. If you're using Phoenix, add the following line to your prefs.js or user.js file:
#56 Re: Nearest Neigbour
Tuesday January 21st, 2003 3:40 AM
You are replying to this message
My point re memory was that it doesn't need to take any more memory than the current resizing strategy. However much memory that is, is rather irrelevant. It needn't increase memory usage. Of course, it would if it then forced you to cache the image (which seems sensible), but you were trying to have that as a different point. You can't have your cake and eat it - either it takes too much cpu because we recalculate every time it paints, or it takes too much memory because we cache it. Not both. :)
(I think it's worth caching resampled images, even if it does potentially double memory costs - I don't think mozilla will automatically resize up so it could not have a higher impact than that. Additionally it would be easy to add thresholds, like using 'dumb' resize if memory is low or if the resized version is much larger than the original.)
I'm not saying this is an essential feature that needs to be in right now, just that it should really be there eventually. I heard somebody just ten minutes ago complaining about how awful IE's image resizing looked...
And although it's a lot more CPU than resizing, I don't think (linear) resampling need be all that slow. Certainly given it would only be used for full-screen image viewing where the image had been shrunk, I don't see it causing a huge difficulty. Again, you can have thresholds for this so that it is turned off on slow machines.
(I have written code like this in a Java application; by default, images are resampled smoothly as users drag them around, adjust their size, etc, but the system calculates approximate resample time per image area on that cpu. If paint for a particular image is predicted to take more than n milliseconds then it will be resized instead. So slower computers don't get dragged down, but faster machines get the benefit. BTW we don't cache resampled images there either but it is not too slow and that's in Java, although I should admit that we have a limit on image size of about 500x400 or so, so we don't see the slowdown from really huge images.)
Oh. And somebody pointed out that what I'm referring to as 'resizing' *is* a resampling strategy; yes it is, but traditionally in practical computing those words are used to indicate the difference between nearest-neighbour resampling and anything more clever. And it's a lot shorter. :)