Retina.js: Retina graphics for your website

Post by beagle3 » Fri, Apr 20, 2012, 7:50 PM UTC

scott_s wrote: post #73

beagle3 wrote: post #64

Earlier quoted context omitted.

Storage is too cheap to care these days. When $110 buys you 2TB (this morning on Newegg), then doing it on the fly and caching the result has about 100x better ROI than trying to solve it with a smart format. Remember, we're speaking about still photos here, where high retina quality ones rarely take more than 500k each, so 2TB buys you room for 4,000,000 photos (and since you'll be caching the lower res 200K images,…

I don't think archgrove's point was about storage, but about the extra friction of tracking N files instead of 1.

    lower_res {
      Request /lowres/*.jpg
      Provide /highres/$1.jpg
      Downscale 50%,50%
      Cached_on /mnt/cheapdisk_that_can_go_away_at_any_time
    }

Post by drcube » Fri, Apr 20, 2012, 9:06 PM UTC

goblin89 wrote: post #48

ned wrote: post #26

Earlier quoted context omitted.

No, the distinction of device pixels vs. CSS pixels predates the first "Retina" iPhone. The distinction existed in all browsers supporting full page zoom, including the Safari on the first iPhone, and in Opera for years before that. "Retina" is just a marketing term for "pixels so small your eye can't distinguish them at a normal distance anymore".

The distinction is also in CSS specs[0] since version 2.1: “The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. 1px thus corresponds to about 0.26 mm (1/96 inch).” [0] http://www.w3.org/TR/CSS21/syndata.html#length-units See also http://inamidst.com/stuff/notes/csspx (been featured on HN some time ago)

Post by rio517 » Fri, Apr 20, 2012, 10:17 PM UTC

orofino wrote: post #6

rb2k_ wrote: post #3

Wouldn't that mean that the device will first try to download all of the low res images and when the script finished loading and is running, the device would then start to load all of the high res images. How's the user experience with all of those additional requests and traffic? (especially via GSM/CDMA)

Indeed it would. Certainly less than ideal, but this provides an avenue to easily implement higher DPI graphics. Right now, it seems like the easiest method to get a site upgraded without having to make a ton of changes. Ideally, we'd have something that would deliver only the correct image to the correct device, the first time. I haven't seen a clean method for achieving that yet.

Post by kennu » Fri, Apr 20, 2012, 11:42 PM UTC

ajross wrote: post #49

kennu wrote: post #39

Earlier quoted context omitted.

This becomes about semantics, then. If somebody writes an article about "retina displays", I immediately assume it's about this particular way of implementing resolution independence in the browser and in the OS (by doubling/quadrupling the physical resolution while keeping the virtual resolution the same). So as such it serves me better than a generic term that requires additional explanation.

Uh... of course it's about semantics. What josteink was complaining about was the use of a proprietary marketing term to refer to something technical. Your interpretation is a fine one, but it's not the one that everyone shares. Specifically, it's not the sense that Apple uses the term either. Take a look at Apple's marketing page for the retina display and see if you can find anything about "resolution independence"…

Post by tedunangst » Sat, Apr 21, 2012, 12:15 AM UTC

ajross wrote: post #84

baddox wrote: post #72

Earlier quoted context omitted.

I fail to see your point. All companies give trademarked names to their products, and to specific features of their products (especially the features that are used heavily in marketing).

Apple is welcome to give any name they want to their product. But when they confuse users to the extent that otherwise-smart web developers start producing "retina.js" to manage resolution independent images (hardly an Apple-specific problem!) then the practice has gone too far.