Sucking at Retina | Hacker News Reader

Sucking at Retina

zachholman.com

63 pointsgeetarista73 comments

"And yet, the internet is still having a hard time adopting. Startups slave for months meticulously designing their new marketing site and are completely oblivious that, to people on a Retina display, it looks like a jumbled pixelated mess."

Or maybe they don't care enough about a tiny fraction of their market to create assets at dramatically higher resolution just to prevent customers from feeling a slight amount of buyer's remorse when they look at their display with a magnifying glass?

Maybe they'd rather have pages load faster for all their customers, instead of serving up needlessly huge image assets to every user? It's not like the WHATWG and W3C have solved this problem yet, they're still bickering over whatever the latest solution is (I don't even know whose fault that is at this point, what a mess)

I still find it incredibly hilarious that owners of Retina macs bitch at content creators because their content looks 'pixelated' when Apple is still too lazy to even run a bilinear filter when upscaling the framebuffer. What is this, 1993? Windows has been able to do this since desktop composition was introduced in Vista.

Totally agree.

Also, while we're at it, can we stop referring to these high-density displays by the idiotic marketing term, "Retina"?

This isn't just for those people running Retina MacBook Pros. iPhone 4 and up, iPad 3 and up and certain Android devices would benefit from Retina assets.

It's not a tiny fraction of the market.

Are you honestly suggesting that it's worth doubling the size of all your assets over the wire, making pages load even slower on mobile, just to make them look high-DPI for people on retina devices?

Again, if it were easy to feature-detect reliably and only serve the bigger assets up to people on retina devices, I might agree with you.

I've got a high-DPI device and I prefer fast-loading pages every day. If I want things to look incredibly crisp I'll zoom out. Text still looks great!

> Are you honestly suggesting that it's worth doubling the size of all your assets over the wire

a) it's nowhere near 4x unless you are using uncompressed images. With something like PNG compression most of the difference is negligible and there've been some interesting experiments showing that with JPEG trading resolution for quality is roughly break-even: see e.g. http://alidark.com/responsive-retina-image-mobile/

b) Even on mobile, latency is WAY more of a factor than bandwidth. If pages load slowly, it's almost always the case that reducing the number of CSS / JS files will help significantly more than reducing image sizes.

c) One of the approaches for dealing with DPI variance is to replace images with vector / webfont / CSS alternatives which don't require scaling. If you do that, you're also going to significantly reduce the total asset size for the page which is going to help everyone get a faster time to paint.

Loading a page with normal assets and then replacing them with double-resolution ones with JavaScript doesn't seem ridiculously bad to me.

Pages still load as they normally would, and then become progressively clearer. Set a cookie, and all subsequent loads can be sent with only retina quality images.

A little fragile, but it works.

That seems like it could work pretty well as long as you can reliably detect that a browser's display is high-DPI. Can you do that? The last time I checked, it's not possible to reliably detect a high-DPI display or force the page to render at a certain DPI level - Chrome used to have a meta viewport attribute for it, but it was removed.

I'd love to see a JavaScript library that does this; I've never run across one.

You can just read 'window.devicePixelRatio' using JavaScript. Retina devices will be more than one.

That's cool, I didn't realize you could use that in production yet but it looks like (other than some weird caveats) you can: http://www.quirksmode.org/blog/archives/2012/07/more_about_d...

Quadrupling, surely?

Probably somewhere in-between on the assumption that compression can do a better job on bigger images.

I think the best solution would be to only use CSS. You can do pretty much everything with CSS so that would be the best way to ensure the perfect resolution for everyone... but there will always be exceptions

Can you use CSS media queries to detect the display's DPI? I haven't seen any examples of that.

You can at least detect the 'device pixel ratio', which seems to be > 1.0 for Retina devices, so that's something:

http://stackoverflow.com/questions/11722442/is-there-a-way-t...

Not sure how well adopted it is, but Bourbon CSS's mixin for serving Hi-DPI assets includes DPI-based media queries:

    @media only screen and (-webkit-min-device-pixel-ratio: 1.5),
    only screen and (min--moz-device-pixel-ratio: 1.5),
    only screen and (-o-min-device-pixel-ratio: 1.5/1),
    only screen and (min-resolution: 144dpi),
    only screen and (min-resolution: 1.5dppx) {
      width: 260px;
    }

Device pixel ratio in CSS is how I've seen every website implement retina support. Definitely possible, and not at all uncommon.

Almost all the higher-end mobile devices have high-DPI displays now. All the flagship Android and Win 8 phones, and even many of the mid-range ones. Heck, even the Blackberry 9900 has a high-DPI display.

I guess it depends on who your market is. Perhaps if you're github or something you might want to care.

If you're "Your Local Newspaper" where local is not in California or some other American tech mecca? I don't think you need to care yet...

By mid 2014, I expect Apple to sell retina versions of all of their laptops. It is still some ways off, but then when will you adapt your site for retina? When 20% of your market has retina laptops? By then, you have established to that 20% that you don't care about polish[1]. Especially for developers, they are that much less likely to recommend you to their friends.

You can find (someone else's) better argument along similar lines at [2].

[1] I'm exaggerating, a bit.

[2] http://www.red-sweater.com/blog/2568/target-the-forward-frin...

Trading page load time and bandwidth usage for crisper pixels is not exactly what I would call polish.

This author's insightful article is easily destroyed by his sheer arrogance and the tone at which he makes an inappropriate statement, attacking the majority of the users.

"The Retina MacBook Pro is still very much a luxury item, but we've had a Retina iPad for almost a year and the iPhone 4 for two and half years. And yet, the internet is still having a hard time adopting."

Because the rest of the internet aren't Apple fanboys and unfortunately, that's the massive majority.

The ideal solution - Don't give a shit about Retina displays, because these tiny fraction of Retina users are already 'used to' looking at normal websites in a pixelated fashion. They'll get used to your website too.

Until the retina resolution is adopted by the rest of the Internet, you have my zero fucks.

Heck, my $100 non-Apple phone has a ~330 ppi display, same as a "retina" iPhone. And high-res displays (especially from Korea) have plummeted in price. https://news.ycombinator.com/item?id=4292450 High-DPI won't be a niche for long.

Those two are not the same thing at all; a 27" 2560x1440 like the one you link to is ~108dpi.

According to Apple's math for "Retina", phones are held at 10" and you need 330ppi like an iPhone. But laptop screens are used at 16" and only need 220ppi like the new Retina MacBooks. So if you use a monitor at a distance of 30" (which is more likely if you use a huge 27" monitor) then you only need about 120ppi to have the same angular resolution. I've seen one of those Korean monitors, and they're definitely dense enough that you need to increase the size of elements on the display. That means pixelization unless you use high-res assets.

Good to know. Got schooled on angular resolution today :)

I got the impression that the author was trying to be funny by using exaggerated arrogance. However, that made the actual advice lose its impact because the author didn't seem serious about it. Or worse, it almost sounded like the author was giving the advice sarcastically and meant the opposite.

I was also deeply confused by the capitalisation of Progress in the first paragraph. I wondered briefly whether it was some kind of web/retina image framework.

Read the article. The author is claiming that it is worth being ahead of the curve, because Retina-esque displays are quickly becoming the norm. There was no implication that Retina-esque displays are currently the majority.

I hear targeting EGA saves you a lot on storage.

"Sucking at webdesign". Today we'll discuss how to turn on antialiasing, that is so glaringly missing from the authors blog:

http://i.imgur.com/d3tby.png

The interested reader will be glad to know that this is plain to see on a non-retina, 24" 1080p screen. The author might also want to stop messing with the font-weight, its hurting my eyes.

Looks fine (antialiased) on my browser. Firefox on Windows by the way.

Exactly! A really valid point there..

Serve retina assets to everyone indiscriminately? Sorry Zach, but if that's your professional advice then you suck at serving the 99% who do not have a fat pipe and a fat processor at their constant disposal on every device they use and in every location they frequent.

I actually thought this was a joke until about half way through. It said it great in the first four words: "It's been six months." You expect the entirety of the internet to transform in a matter of months to accommodate your latest gadget?

What baffles me a bit is how horrendously buggy some OS X apps are with Retina displays. I'm running an rMBP and Thunderbolt displays, and I've had no end of pain with Chrome; Flash videos fullscreen at 2x or 1/2x resolution (seems to be no logic as to which that will be), pages will randomly go white while the elements are still there with logic running, text will overrun controls (e.g. the "add comment" button on HN -- text is 2x bigger than the button), etc. It's generally not a dealbreaker, but it absolutely isn't a great user experience.

"Let's hinder 98% of our visitors to please the 2% with retina screen !"

Seriously, developing for multiple density is hard in the real world. Way harder then this article says.

It is unquestionably difficult, but the idea here is to improve the experience for that smaller percentage while not hindering the majority. Depending on your site, you can do this using CSS media queries so the browser can determine what asset to load. The only disadvantage is an increase in bandwidth utilization for the retina consumers.

Clearly that's not practical for many sites at this time, but the options are there and it's relatively easy to do if your site is built via the spritesheet style.

Right but that's not what the article advises.

I have a little retina less mixin I use (when using bootstrap mostly) that I modified from the retina.js solution. It's the same solution with additional parameters. I've found it to be useful when doing retina projects.

I put it up on github here: https://github.com/erikflowers/retina-mixin

I don't have a retina device, so I wonder: are they not capable of rendering normal resolutions? I would have assumed that they simply render a "classic pixel" as four retina pixels? So classic web sites should still work?

Apple renders a classic pixel as four retina pixels, but they don't apply any filtering, so it makes graphics (particularly text with subpixel antialiasing enabled) look rather awful. If they did filtering it'd look much better, but you can probably imagine the economic incentives not to do that.

Not economic - runtime performance.

The rMBP actually has 5 scaled resolution modes with 2:1 being the 'ideal' 'retina' mode that the laptop defaults to. In 2:1 mode, no filtering is done. Occasionally to get a bit more desktop space I'll shift mine into one of the modes with non-integer scaling to make the desktop bigger, and in those modes filtering is applied. There are two non-integer modes where the scaling is N:1 where N>2 as well. Switch into any of these non-integer scaling modes, though, and screen rendering is slightly but noticeably affected - scrolling windows in particular is much choppier in any of the filtered modes. This is the runtime cost of touching that many pixels in such a large display buffer in order to oversample and filter.

As for why 2:1 mode looks so blurry, I'm guessing that its a combination of pixel glow in low resolution displays smoothing edges and comparison to the relative sharpness of the rest of the OSX UI.

Runtime performance is exactly what I'm referring to by economic incentives. Any adequate desktop (or even mobile) GPU made in the last few years has the bandwidth to spare to do bilinear filtering (if not bicubic or better) when upscaling a framebuffer to fit a display; you won't see modern video games ship with filtering turned off because literally every decent piece of hardware has the bandwidth and cycles to spare to filter.

Unfortunately, Apple puts tremendously underpowered Intel GPUs into their Retina macbooks - GPUs that struggle to drive even low-DPI displays or run games at native resolution - and then expects them to drive displays containing 4x the pixels. It's no wonder that scrolling performance is choppy.

One could argue that the choice of terrible Intel GPUs is actually to improve battery life, not to save money; that might be true. But in that case, why not include their (rather well implemented) GPU-switching technology in all Retina macbooks? Why only the 15"?

Are you seriously advocating that Apple use a desktop GPU in their laptops?

None of this is true. First, the 15" retina mbp has a nvidia GT650M along with an intel gpu. And it's still not enough. Remember that a game running at 2880x1800 using filtering can use memory-bandwidth saving tricks like quincunx which can't be used in a desktop environment. Moreover, in the 'scaled-up' 1920x1200 mode the rMBP supports, the rMBP is essentially super-sampling a much larger pre-display buffer than 2880x1800

Have a read:

http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-w...

At the default setting, either Intel’s HD 4000 or NVIDIA’s GeForce GT 650M already have to render and display far more pixels than either GPU was ever intended to. At the 1680 and 1920 settings however the GPUs are doing more work than even their high-end desktop counterparts are used to. In writing this article it finally dawned on me exactly what has been happening at Intel over the past few years.

...

To be quite honest, the hardware in the rMBP isn’t enough to deliver a consistently smooth experience across all applications. At 2880 x 1800 most interactions are smooth but things like zooming windows or scrolling on certain web pages is clearly sub-30fps. At the higher scaled resolutions, since the GPU has to render as much as 9.2MP, even UI performance can be sluggish. There’s simply nothing that can be done at this point - Apple is pushing the limits of the hardware we have available today, far beyond what any other OEM has done. Future iterations of the Retina Display MacBook Pro will have faster hardware with embedded DRAM that will help mitigate this problem. But there are other limitations: many elements of screen drawing are still done on the CPU, and as largely serial architectures their ability to scale performance with dramatically higher resolutions is limited.

It has a bigger battery.

I'm advocating that Apple doesn't ship displays that can't be driven by the graphics hardware in their devices. Whether they solve that by shipping better GPUs, larger batteries, or lower resolution screens, I don't particularly care, but I think the current situation is ridiculous.

I applaud their attempts to push the limits of hardware, deliver new and innovative experiences, etc etc etc but ultimately at the end of the day you shouldn't ship optional features that won't work in basic usage scenarios. I think 'being able to scroll a webpage at 60fps' is a pretty basic usage scenario.

I don't understand the claim that a GeForce GT 650m running at 1920x1200 is doing 'more work than even their high-end desktop counterparts are used to' though. That's blatantly false. Furthermore the claim that rendering is largely serial is blatantly, tremendously false - modern GPU architectures are embarassingly parallel and even the kind of rendering Apple does for their UIs can be parallelized to a large extent. Perhaps the intent here is to describe how the workloads that suffer (like scrolling webpages) can't be parallelized?

Thanks for the explanation on the 15", that makes sense - I didn't realize that you could only get a larger battery for the 15".

They do still work and classic pixels are scaled up to 4 retina pixels. Its just that those blocky 4 retina pixels in scaled-up bitmaps on websites look very bad next to the website's razor-sharp rendered text.

"classic" web sites work fine, but bitmapped elements are scaled and end up looking blurry (especially compared to vector elements like text, SVG)

Hmm, I'd probably lay the blame at Apple here more than at web developers.

If you're going to go out there and create a premium end product you might want to think about what 80% of the web is going to look like on it. Perhaps Apple assumed that web designers would be all over this and rolling it out everywhere from day 1?

I don't optimise stuff for retina, mainly because I don't have a retina device so it's partly a case of "out of sight, out of mind" and also without the device to test on it would become difficult to assume anything about how good my retina icons really look.

One particularly large issue that I've had with making retina compatible websites is Mobile Safari. It renders SVG a little strangely at times, and even the simplest of the can reliably crash the browser when zoomed in on.

This is a huge problem, which is the poor handling of SVG by even 'current' browsers. I keep hoping the 'retina revolution' will force this issue for browser makers.

It's really not that hard to do a decent job with Retina.

For LESS, I like "retina.less" from http://retinajs.com/

  #logo {
    .at2x('/images/my_image.png', 200px, 100px);
  }

Could easily be adopted for SASS I'm sure.

This avoids the typical double-image downloading (like on Apple's website).

https://github.com/imulus/retinajs/blob/master/src/retina.le...

And if I'm rendering an image JavaScript and want to choose a resolution (like for Gravatar), can detect like this:

    app.isRetina = function(){
        var mediaQuery = "(-webkit-min-device-pixel-ratio: 1.5),\
                (min--moz-device-pixel-ratio: 1.5),\
                (-o-min-device-pixel-ratio: 3/2),\
                (min-resolution: 1.5dppx)";
        if (window.devicePixelRatio > 1)
            return true;
        if (window.matchMedia && window.matchMedia(mediaQuery).matches)
            return true;
        return false;
    }();

Supporting a high density display is not just about making images 2x as big. A responsive design, use of icon fonts and careful use of images and you can do it pretty painlessly.

Clearly my personal blog is not a bastion of high design, but it looks pretty decent on every screen I've viewed it on just by following these small prescriptions and testing it during construction on both high and low density displays. It's really not that hard. http://jeffbail.com if you're interested.

That said, since its my personal site, I can do whatever I want and I appreciate fully that is not usually the case at some/most corporations. These folks usually need more than 6 months to make these types of changes, get approval from higher ups, etc...

There's a bunch of people in this thread making the case that developers shouldn't bother supporting retina devices because they represent such a small section of the market. Ordinarily I'd agree with that sentiment. I don't spend a whole lot of time making sure my work renders well in Internet Explorer 6, because IE6 represents less than a half of one percent of the traffic I receive.

But here's the thing - IE6 market share is shrinking, and retina display market share is growing. It seems inevitable that given enough time all Apple devices (and potentially many devices from other manufacturers) will come with retina displays. Which is why it makes sense to get out ahead of this trend before retina displays become popular.

The author may want to fix his menu-bar before complaining about others. It's a tiny, blurry mess on my 27" Thunderbolt-Display. On a smaller retina screen it probably looks more like a smudge than text.

Pretty awesome solution to this is the browser based page compilation for GWT:

http://retina.teknonsys.com/

Works really well and non-retina clients don't even have to load extra css or javascript for retina images, and retina clients don't have to load the small-version images. Fairly perfect solution... provided you use GWT, I guess, which is rare...

I don't own any Retina devices, and won't for the immediate future, as a not-yet-employed student.

How can I test how my webpages will look on a Retina display, without hardware? I haven't found an answer (admittedly, with only a little searching) that doesn't involve me taking the bus to the local Apple store each revision.

If you have a Mac, you can use Quartz Debug to enable HiDPI mode on a non-retina screen. I wouldn't attempt that if you have anything but an iMac or large external monitor though.

Alternately, get an iPhone 4 or one of the older retina iPod touch models. I picked one up for $80 to do some testing on.

Well, i don't know.. i have a very slow internet connection and a very standard 1366x768 resolution (which i guess is by far the most common nowadays on laptops!). I wouldn't want to wait like 4 times as much to view webpages! I can understand his arguments though. Everyone wants nice and crispy graphics.

And here is the real solution that fixes resolution and bandwith problems once and for all, atleast for icons and most of the stuff a webpage is made of (which he doesn't even mention once!): SVG. Can we please move on and ship vector graphics (for all non-photo content)?

P.S.: Yes, bad browser support, yada yada yada.. Still, what he proposes is by no means a solution for the real problem. What happens with the next generation displays?!

I think the main obstacle is that most companies are uber focused on mobile, and adding high resolution assets is going against that initiative. I don't know of any companies that have a Retina initiative.

I understand that there's ways to serve lower res assets to mobile devices, but many of these architectures are already set and updating them to take advantage of media queries is not high on the list of to-dos.

In what way are HDPI assets going against mobile initiatives? The vast majority of Retina display are on mobile devices.

Mobile devices quite frequently find themselves on low-bandwidth networks. (Edit: and many mobile users have low transfer caps on their data plans)

quoting anil dash (https://twitter.com/anildash/status/221353763842174976):

"Rather than optimizing your website for Retina displays, invest your budget on the 30x as many people who have visual/sight challenges."

In the long run, the OP is probably right and we're going to have to deal with retina.

I don't understand why exactly, but an image saved at 2x pixels isn't necessarily 2x the bytes.

Take 20 minutes and at least redo your logo and key images.

Here's my take on how (short-form of author's post): http://telecuda.tumblr.com/post/26032269612/optimize-blurry-...

At least in the case of 24bit PNGs, you (always) end up with 4x the pixels (2x width and 2x height) and (generally) end up with about 1.8x the size due to more efficient compression.

It's 4x the pixels and usually works out at about 1.5-2x the bytes.

Weird, the very first thing I noticed was how pixely the g+ twitter and rss icons look at the top in my non retina desktop

Wow. Either a lot of web site developers posting here really don't give two hoots about the quality of their website's appearance, or a lot of the people posting here are posers that don't develop websites but feel entitled to an opinion about it. Either way, not a great indicator of the direction the HN community is headed.

It seems like all the current hi res solutions are somewhat hacky. I recently did a project with foresight.js (https://github.com/adamdbradley/foresight.js) I like how it tries to estimate the connection speed before serving up a 2x image.

Facebook, Apple, and GitHub are the only sites I've seen that seem to support the retina display with their images. Even then, Facebook misses some images.

Sure lets 4x the requirements for download and rendering for a fraction of a % of the user-base.

Im all for advancement but doing it blindly and you will trip and fall.

Slightly off topic, but anyone know if anything is happening in terms of Linux/X11 and HiDPI? Or will we need to wait a few years?

The article (and so far the comments here on HN) are all talking about "double resolution" but in reality it's quadruple for actual retina aseets.

a 120x90 image becomes a 240x180 and that's not 2x the pixels, that's 4x the pixels (and bytes.) It's not insignificant. There's great reasons not to bother right now:

1) On phones and tablets people are either going to be zoomed out where they can't appreciate the hi res images, or zoomed in on some text and not really looking at the image most of the time.

2) While I have an rMBP, most people don't. They're starting to get around but for now it's fine. Certainly I agree with the author's advisement to figure out a solution this year, but I disagree with his admonishing of people still putting it off right now.

3) Lots of people who DO have rMBP do NOT run the machine in pure Retina 4:1 resolution. That includes me, I run it in 1920x1200 mode. Most people don't go seem to go that high but even at 1650x1290 "bad" images are much less bad.

Basically, my point is, this isn't as big of a deal as some people make it out to be. I think it's most important for large hero areas and other images that are going to be focus points of your page. But as long as you get on it some time this year you should be fine before a significant portion of your users are thinking your site looks ghetto.

> that's 4x the pixels (and bytes.)

In my experience the 4x pixels works out to something less than 4x bytes assuming jpg or 24bit PNGs because the compression gets more efficient. For instance quadrupling the number of pixels generally doesn't increase the color table by 4x.

I just calculated the difference for about 100 retina files on my sites/apps, and the average size increase is 1.8x.

> that's 4x the pixels (and bytes.)

I don't think this is true -- I don't think the compressed size tends to scale linearly with the raw # of pixels. I did a few tests and saw that using the same compression settings on the larger image typically resulted in an image 3x the size.

There was a post I saw that showed up on HN a while ago claiming you might be better off just using highly-compressed high resolution images for both high-DPI and normal-DPI displays: http://blog.netvlies.nl/design-interactie/retina-revolution/

And the previous HN discussion, since there was a fair bit of disagreement: http://news.ycombinator.com/item?id=4623160

Reply on news.ycombinator.com