On Wed, Sep 5, 2012 at 2:00 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Wed, Sep 5, 2012 at 12:35 PM, Asher Feldman afeldman@wikimedia.org wrote:
Browser scaling is also at least worth experimenting with. Instances where browser scaling would be bad are likely instances where the image is already subpar if viewed on a
high-dpi
/ retina display.
Other instances where browser scaling is bad are:
- PoS browsers that don't render SVGs (how old are these by now?)
IE up through 8, and Android stock browser through 2.3. Neither are dead yet, so we still gotta deal with rasterization for them.
* Even modern browsers have subpar SVG rendering at 1x, PNG looks better
Examples? Sounds like bugs need to be filed with some of those browsers. :)
- Some media types are "scaled" in unusual ways (SVGs, but also video
stills, PDF pages, ...)
- Some original images are really friggin' large (20-30 megapixels
sometimes), so at least some downscaling is needed there
You'd absolutely want to do server-side downscaling to the base sizes in the appropriate file formats -- we wouldn't try to download multi-megapixel originals just to make a tiny thumbnail, and some formats require conversion to a format the browser can read.
For an example if we were to standardize on sizes: (we wouldn't use these actual sizes because they do NOT fit our usage) * 32px * 64px * 128px * 256px * 512px * 1024px * 2048px
Then somebody requesting a 400px image might get the next size up, the 512px image delivered and scaled down in the browser. (On a high-resolution display, you might fetch the 1024px image.)
In reality we'd want sizes that fit most common usage, and perhaps make future markup & visual editor widgets promote using of standard sizes to minimize the cases where you end up with something that's not an exact fit.
- Mobile clients will want to minimize the amount of data transferred
This is a good reason for picking appropriate default sizes that would fit with actual common usage.
Note that with SVG, SVG originals can be either much smaller or much larger than a rasterized image -- in many cases we have SVGs that are much more detailed than they need to be. So serving of SVG doesn't guarantee a bandwidth save, though it can in well-designed cases.
Mobile also has the case that many (possibly even most in some markets) devices have a greater than 1.0 device-to-CSS pixel ratio, so loading 1.5X or 2.0X versions of raster images may be something we want in many cases. In theory you could make a switch -- just as we have a 'disable images' switch, we could make it a three-way control 'no images - low-resolution images - high-resolution images'.
[And just to screw with people, Windows 8 / Windows RT is going with 1.4x and 1.8x scaling factors instead of the 1.5x and 2.0x that Android and iOS -- and Windows Phone 7 -- use. Fun huh! We're probably not going to have exact scaled versions of them, they'll get the 1.5 or 2.0 and scale it down a little probably.]
-- brion