HiDPI display support

High resolution; HiDPI; Retina Display™ etc. refers to a class of higher resolution displays that attempt to match or surpass the resolution of the human eyes at normal viewing distances. Around 2012, Apple introduced a web standard enabling websites to serve higher resolution images to such devices using the srcset attribute. Support for this was introduced into MediaWiki with 1.21 in 2012. In February 2016, it was removed again from the mobile site, which appears to have improved performance slightly according to early results.

Apple, Toshiba, Google, and others are now shipping laptops with displays in the 2560x1600 to 2880x1800 range which render text beautifully^{[citation needed]}, at twice the horizontal & vertical resolution of classic displays. We've already seen this in the mobile world with the iPhone 4 and iPad 3, but it's going to get harder to ignore now that it's hitting laptops.

Current support

Image thumbnails

As of 1.21, the $wgResponsiveImages setting controls generation of additional image thumbnails for [[File:]] links at 1.5x and 2x the requested resolution, which are put into a srcset attribute on the img tag, a new part of the HTML 5 draft spec.

Compatibility JavaScript is used to check the device resolution and load up the higher-resolution images; if native srcset support is used this JS is skipped and things should work automatically. This can be tested on high-DPI laptop systems with a nightly WebKit with srcset support; native support should reach release browsers later in 2013 or early 2014.

There is not currently any user-facing way to disable high-DPI image loading (other than disabling JavaScript).

Concerns:

• bandwidth
  • loading high-resolution images can eat up much more bandwidth than low-resolution ones. Currently we have no way to distinguish a high-DPI device on a fast network from one on a slow or metered network.
    • Wikipedia Zero might consider stripping the hi-DPI photo links versions from output, for instance
  • adding all those 'srcset' attributes increases HTML size; it's mostly gzipped out but will eat some memory on device etc
• load time: loading larger images increases the total load time, but shouldn't affect time-to-first-display or time-to-responsiveness since they're fetched after onload.

In progress

Skin chrome

This is still inconsistent, but coming along:

• MobileFrontend UI usually uses a 2.0x-density PNG unconditionally for icons, which compress well and scale down fairly cleanly.
• Some desktop UI modules use SVG icons (using a CSS background-image hack that falls back to .png on older browsers)
• As of MediaWiki 1.24 there is another option for including SVG icons with PNG fallback.
  • SVG icons should be run through svgo to remove redundant metadata and decrease file size. See Manual:Assets

Vector SVG icons

Do we have SVG files for Vector's icons? I'm only seeing png in skins/vector/images. --Cmelbye (talk) 23:54, 30 June 2012 (UTC)

• In many cases we only seem to have low-resolution PNGs. These will get replaced over time.....

Site logos

Site logos are the biggest low-hanging fruit: it's relatively isolated and since it's on every page and large, it's visible.

Logo is set with inline CSS; with some trickery we could change to a <style> tag and use media queries to load a high-res version if available.

Math

The optional MathJax rendering mode uses real text-rendering and looks great in HiDPI modes. However, it is not yet the default mode.

• fix bugs
• set MathJax as default rendering mode?

It's also possible we could render 1.5x and 2x images from texvc, and use srcset.

Browser compatibility

Firefox

• Release versions now support HiDPI on Android, and Mac and Windows 8 desktop. (Manual adjustment in about:config works on Linux as well.)
• -moz-device-pixel-ratio, min--moz-device-pixel-ratio in CSS media queries

Safari

• Safari supports HiDPI modes on Mac, iPhone, and iPad.
• -webkit-device-pixel-ratio, -webkit-min-device-pixel-ratio usable in CSS media queries
• window.devicePixelRatio works as expected, returning 1 or 2 as appropriate
  • beware that on Mac, the ratio can change over time! Currently we are ignoring this and only checking it once.
• Native srcset support is in development WebKit builds.
  • this also only seems to take effect at load time, switching screens requires a reload to refetch the right images

Chrome

• Chrome supports HiDPI on Mac, Android, iOS, ChromeOS, and as an experimental option on Windows (untested).
• -webkit-device-pixel-ratio, -webkit-min-device-pixel-ratio usable in CSS media queries
  • window.devicePixelRatio works as expected on Mac.
• WebKit's new native srcset support may get copied over to Blink engine.

Android classic browser

• Android phones and tablets with 1.33x, 1.5x, 2x, and even 3x pixel ratios exist
• -webkit-device-pixel-ratio, -webkit-min-device-pixel-ratio usable in CSS media queries
• window.devicePixelRatio works

Internet Explorer - Windows

• 1.4x and 1.8x scaling for Windows 8 Metro interface at some resolutions, can be tested in SDK simulator
• CSS media queries may or may not work, check me.
  • Doesn't seem to support device-pixel-ratio, but you can use dpi in resolution[1]
  • This makes a "ratio>1.0 -> use SVG if possible" rule seem kind of wise. :)
• currently using window.msMatchMedia to do media query checks, just checking >= 144 (1.5+) and >= 196 (2+)

Internet Explorer - Windows Phone

• no window.devicePixelRatio
• no window.msMatchMedia
• can assume that all Windows Phone 7 devices are 1.5x though...
  • Windows Phone 8 supports both 1.5x and 2.0x-ish resolutions. And it should have IE 10, which should support window.msMatchMedia, so... hopefully it'll "just work" and we can leave WP7 as-is.

BlackBerry 10

• reports window.devicePixelRatio of approximately 2.25 (slightly less on my dev alpha, at least)