Stop being careless with your users' bandwidth. Assuming that every client should get the highest-resolution (and thus highest-bandwidth and highest-memory-cost) assets is just lazy.
Use Javascript. Something like https://github.com/scottjehl/picturefill works beautifully and results in only one request per asset, with a noscript fallback. It's more markup, which is kind of a pain in the ass, but it means that the right clients get the right assets and you don't end up destroying your poor EDGE and 3G customers because you decided they needed a 2400x1200 splash image. Let's not forget that a "retina" image imposes a 4x memory cost on the client - image data has to be decompressed to be displayed. So, your user on their mobile phone with 512mb of RAM is going to have a terrible experience when your website is using 4x more of their precious RAM on images that don't actually provide them with any visual benefit.
Double-pixel displays are still, by a massive margin, the exception. Unless you're specifically serving a Retina Macbook-targeted audience, you're going to incur a lot of overhead for no appreciable benefit for the majority of your audience.
Not to mention, using high resolution graphics when only displaying at a lower resolution increases battery usage and lowers performance of the webpage.
Don't retinafy at all. You should not assume your user has LTE speeds on his shiny iPad. As long as webdevs won't have a better navigator.connection, retinafying should be avoided.
> for bitmapped images, go high-resolution and let the browser scale down
Wait, I should use more bandwidth than I need, and impose a client-side performance hit? What is wrong with a little CSS to serve the right assets to 1x, 1.5x and 2x pixel ratio devices?
[+] [-] cheald|13 years ago|reply
Stop being careless with your users' bandwidth. Assuming that every client should get the highest-resolution (and thus highest-bandwidth and highest-memory-cost) assets is just lazy.
Use Javascript. Something like https://github.com/scottjehl/picturefill works beautifully and results in only one request per asset, with a noscript fallback. It's more markup, which is kind of a pain in the ass, but it means that the right clients get the right assets and you don't end up destroying your poor EDGE and 3G customers because you decided they needed a 2400x1200 splash image. Let's not forget that a "retina" image imposes a 4x memory cost on the client - image data has to be decompressed to be displayed. So, your user on their mobile phone with 512mb of RAM is going to have a terrible experience when your website is using 4x more of their precious RAM on images that don't actually provide them with any visual benefit.
Double-pixel displays are still, by a massive margin, the exception. Unless you're specifically serving a Retina Macbook-targeted audience, you're going to incur a lot of overhead for no appreciable benefit for the majority of your audience.
[+] [-] basicxman|13 years ago|reply
[+] [-] mddw|13 years ago|reply
On the web, loading times trump beauty.
[+] [-] madrobby|13 years ago|reply
[+] [-] sratner|13 years ago|reply
Wait, I should use more bandwidth than I need, and impose a client-side performance hit? What is wrong with a little CSS to serve the right assets to 1x, 1.5x and 2x pixel ratio devices?
[+] [-] kaolinite|13 years ago|reply
[+] [-] madrobby|13 years ago|reply
But you shouldn't make it the default go-to.