HiDPI display support

From MediaWiki.org
Jump to: navigation, search

High resolution; HiDPI; Retina Display(TM), whatever you call it.... it's here.

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[edit | edit source]

Image thumbnails[edit | edit source]

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[edit | edit source]

Skin chrome[edit | edit source]

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.[1]
    • SVG icons should be run through svgo to remove redundant metadata and decrease file size. See Manual:Assets

Vector SVG icons[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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)