The rise of high resolution displays has put Dribbble in a unique position. As a site that constrains its image uploads to fixed pixel dimensions, how should we handle images that appear on HiDPI (e.g. Retina) devices? Many Dribbblers are designing (and have been for quite some time) @2x for iOS apps. Others are creating @2x assets for the recently-released Retina Macbook Pro. And still more are concerned about making their work look as sharp as possible for devices that support HiDPI now and in the future. Apple has led the way with Retina displays, but other device makers are following suit. Soon, HiDPI displays will be the norm, blurring all of our lovingly-crafted 72dpi images.
To get a leg up on all of this and make it simpler for folks uploading @2x work they’re sharing on Dribbble, we’re pleased to announce that starting today, ALL Players have the ability to upload 800×600 shots in addition to the normal 400×300.
How it works
On HiDPI displays, we show an 800×600 shot in 400×300 reference pixels for twice the resolution (yes, this makes our heads hurt, too). In normal displays, we’ll show a downsized 400x300 version. In either type of display, you’ll be able to see @2x shots at 800×600 by toggling the @2x link.
We’ve also made some other HiDPI enhancements leading up to this release: crisper icons, @2x thumbnail shots (for screens that support them), etc. The caliber of work shared by the Dribbble community continues to be a source of joy and awe for us, so we’re thrilled that it can now appear @2x sharper.
Under the hood
For the curious developers out there, we’re using Scott Jehl’s brilliant Picturefill script to conditionally serve shot images at 800×600 or 400×300 depending on the device’s display. Scott’s script polyfills the proposed <picture> element which would standardize the rendering of multi-size images for various viewports and display resolutions.
How will this affect the API?
Anywhere in the API where a shot is returned, the shot object has always had an image_url attribute pointing to the full shot image. That continues to be the case, though with @2x shots, it’s now possible for a shot to be greater than 400x300. Additionally, there is now an image_400_url attribute, only present for @2x shots, that points to a resized 400x300 version (potentially useful for @2x teaser views or for apps that can’t support the larger images yet).
So there are two ways to determine that a shot is @2x — the presence of the image_400_url attribute and the fact that its width and height attributes are greater than 400 and 300, respectively. Also — please note that we don’t attempt to resize animated gifs from 800x600 to 400x300. In the case of an 800x600 animated gif, the image_400_url simply points to a resized image of the first frame of the animated gif.
We plan to make much bigger additions to the API down the road a bit, but wanted to provide basic support for @2x shots at this time so existing clients can make use of them right away.