On Wed, Sep 5, 2012 at 2:00 PM, Roan Kattouw <[email protected]> wrote:
> On Wed, Sep 5, 2012 at 12:35 PM, Asher Feldman <[email protected]> > 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
