High-density displays are already here on small screens, and should start hitting tablets, laptops, and desktops in the next couple years. Apple’s iPhone 4 and current-model iPod Touch sport a best-of-breed 326dpi display, while lots of Android and Windows Phone devices have an intermediate 240dpi resolution. With the new Galaxy Nexus, Android’s entering the 320+dpi world as well.
The most immediate effect is of course that text renders as sharply on screen as in print. As a web-based application, Wikipedia gets this über-shiny text rendering “for free”… but for graphics, we’ll have to work a little harder.
Most images you’ll find on the wikis are either largeish raster images that are being scaled down for in-article viewing, or scalable SVG drawings that are being rasterized to PNG on the servers for broadest browser compatibility.
Unfortunately neither automatically takes advantage of a high-density display!
For SVG drawings, we can simply start serving the original SVGs instead of the rasterized PNG images, and they’ll look lovely (images from Gas giant article mobile view, rendered on an iPod Touch, with high-res versions swapped in by this bookmarklet):
We’ll need to make sure we can do this with a good fallback to PNG however — while all major desktop and mobile browsers in their *latest* versions support SVG, there’s still a lot of Internet Explorer users and Android users who can’t view SVG. Some less capable mobile devices may also be unable to handle full SVG (Android is rare among smartphones; SVG support is missing on most Android phones today but is present in Android 3.x tablets and upcoming 4.x phones).
We also need to make sure that file sizes and rendering times are reasonable; large maps might be very expensive to transfer and render client-side when we really only need a small map. See my SVG-Open 2009 slides for some data on PNG vs SVG sizes and the need for work on shrinking files.
Other files are usually available in a size larger than they’re shown on default-density screens, so putting a 1.5-sized or double-sized thumbnail into the same screen space makes it match the screen’s actual density. This is particularly useful for diagrams that were created as raster images instead of SVGs, since they often contain fine lines and text which benefits from the full resolution:
SVG and PNG images used for icons and diagrams are probably the highest-priority for high-density images. Photographic images can also benefit, but usually scale up better than line drawings and text because they have fewer sharp edges to begin with.
For raster images of all types, doing dynamic replacement is extra work; CSS or JavaScript can be used in various circumstances but it can take work to make existing code using <img> tags “just work” without loading up extra versions of images, or loading higher resolutions than you need on other devices.
Math equations are another thing; currently we render most math equations to PNG images (via LaTeX); these also render poorly compared to other text on a high-density display. The best solution for this appears to be to migrate towards client-side math rendering based on the MathJax library; using MathML or HTML and CSS, this system is able to use the browser’s native text rendering much more effectively for math. Equations rendered this way look stunning at high resolution!
I’ve experimented with WebP thumbnails using the toolserver as rendering platform. WebP could deliver larger thumnails to Android (they support their own file format, surely?) with roughly the same size as the current, smaller PNG ones, which would be important on mobile devices, for speed if not for transfer cost. OTOH, that would mean Yet Another Thumbnail Cache for a not widely supported file format that’s still in flux…
The bad news on that front is that WebP support didn’t get added to Android until…… version 4, the same phone version that adds SVG. :P Still worth considering, though WebP may be easier to use as a JPEG supplement than a PNG supplement (transparency was apparently JUST ADDED like two weeks ago, so I’d be surprised if it’s supported anywhere yet: http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html )
One thing that needs to be remembered is that a lot of our SVGs were written/created with Wikimedia wikis in mind. That is to say, they were rewritten with the quirks of rsvg in mind… some are going to look awful when you switch back to native resolution.
(Or rather, perhaps the salient point is that many will look good either as PNG or SVG — but not both.)
Indeed we’ll want to find and fix those. :)