
HiDPI/Retina image upsizing by clients & servers, not javascript - skeltoac
https://github.com/skeltoac/HAIR
======
ianstallings
I really like this approach. Is there a plan in place to implement this on a
server and client? A simple node server with a hacked up moz might be a good
start for a prototype.

~~~
skeltoac
I hope to implement server support on WordPress.com if browser hackers are
interested. Our image serving architecture is mostly in PHP and has access to
originals, so this should not be terribly hard.

------
tpenzer
Why is this information put in the HTTP headers rather than the HTML for the
page in question? It just seems like a relatively obscure place to hide what's
bound to be a common bit of functionality; not the most noob-friendly
solution.

I submitted a different potential solution to whatwg forums and a few relevant
mailing lists, without much significant feedback, using meta tags to indicate
availability of 2x image assets. It does seem more practical to me from the
point of view of an author, but maybe I'm missing something important:

[http://forums.whatwg.org/bb3/viewtopic.php?f=3&t=4998](http://forums.whatwg.org/bb3/viewtopic.php?f=3&t=4998)

~~~
KrisJordan
Because your markup doesn't need to change to support HiDPI. The beauty of
this solution is that the browser can be DPI aware and use HTTP content-
negotiation behind the scenes to ask for higher resolution images. This is one
of the main, albeit underused, use cases of content-negotiation with Accept
headers. The main problem is that it requires both servers and browsers to add
support. Whereas with a markup based solution that pointed out how to find
hidpi assets existing servers can serve two files just fine.

~~~
tpenzer
It seems inflexible and potentially inefficient though. What if you have 2x
assets available for some images but not others? Will the client be making two
requests in all those cases? Or will it simply break?

~~~
KrisJordan
Server logic can figure it out just fine. For a familiar example check out
nginx's static gzip compression support [1]. This works today. Browsers can
say they support gzip compressed assets in a header. You don't have to add
markup to say "get the smaller version". When nginx gets a request it looks to
see "is gzip on the accept-encoding list"? If so, it looks to see if a
compressed version of the file is sitting on the server and serves that
directly. If not, it compresses on the fly.

Same story could apply here with a few different details.

[1]: <http://wiki.nginx.org/HttpGzipStaticModule>

~~~
tpenzer
I don't understand how that resolves the issue. Let's say you have two img
elements on your page, linking to their respective 1x image assets, and you
have a 2x version of the image available for the first but not the second. You
indicate 2x availability in your HTTP header, and a client which supports this
protocol wishes to display 2x images.

Does the client specifically request 2x image file paths for both images, and
when the second one fails, as no 2x version exists, the client makes another
request for the 1x version, or does it simply fail to load the image?

Or does the client request the 1x asset like usual, and when the server
determines that one is unavailable in 2x res, it sends the 1x transparently?
If that's the case, do we not care about the server using resources
determining availability of individual 2x assets because it's insignificant?
And could the client easily choose to request 1x assets rather than 2x in a
non-hackish way even if it does support 2x resolution (maybe it's concerned
about bandwidth)?

~~~
plorkyeran
_You indicate 2x availability in your HTTP header_

This part never happens. The client simply signals that it would like 2x
images if possible with every request, and the server sends the 2x images when
it is possible, and 1x images when not. This is the exact same thing as has
been done with gzip compression for years.

The client can choose to get 1x assets by just not sending the header
indicating that it wants 2x assets.

~~~
tpenzer
And what about the performance penalty for the server to determine 2x
availability for sites where only a fraction of images are available at 2x
res?

I'm also not sure I fully understand how we clue the server in on where to
look for the 2x version of a 1x asset. In the examples given, do the 2x
versions have the same filenames as the 1x versions, but they're in the
'image' directory rather than 'img'? Seems like a significant limitation to
force different assets to share the same filename, if that's what's going on
here.

------
dorianj
This is needlessly complex. I really don't see pixel ratios of anything more
than 2x being useful. Having two versions of assets is painful enough.

The apple convention, of having images with "@2x" appended, works quite well.
The server could look for a http header indicating DPI and serve accordingly.
This gives the developer to provide either one single HiDPI that's served to
all clients, or separate files for HiDPI and normal resolution.

~~~
WiseWeasel
It is short-sighted to assume that 2x will be the limit of high-resolution
images. If we're making browser developers add support for this, we might as
well have it be at least somewhat future-proof.

~~~
pornel
Meaning of "1x" has changed from 72dpi to 100-130dpi over time.

It's not unreasonable to assume that same will happen with "2x" as screen
densities gradually improve, and over time it will shift from 220dpi to
300dpi-400dpi (for desktop viewing distances).

Density doesn't need to improve indefinitely, it just needs to cross the
"retina" threshold (which arguably 2x does already).

------
zacman85
We actually talked to some Safari engineers about this and the response was
that image-sets were the way forward. I am not sure I agree. The key argument
was that the accepts header puts the burden entirely on the server and does
not account for multi-resolution environments, such as multiple monitor
setups. Content moving from one device/monitor to another could make use of
image-sets to load in the appropriate image for its display.

~~~
WiseWeasel
I wish image-set was more efficient to use. I'm way too lazy to maintain
explicit lists of every variant file path for every image if I can avoid it
(which should be possible if we take advantage of systematic file naming
conventions already commonly in place). I'd take this proposed solution over
image-set, simply because it avoids that extra work, not to mention being more
backwards-compatible; image-set would require you to list the path for the 1x
asset of an img element in both the 'src' attribute and the image-set
attribute in order to maintain backwards-compatibility.

------
tlb
It won't succeed. The closest parallel is the Accept-Language feature in the
HTTP headers, which never took off. By the time this could be implemented in
many browsers and servers, everyone will have already solved the problem with
javascript.

~~~
WiseWeasel
JavaScript is not a real solution to this problem, since it takes the control
away from the client and condemns web developers to maintaining those horrible
hacks forever as clients with unforeseen capabilities or expectations emerge.
We need _something_ that allows developers to add support for 2x images
without having the server make any assumptions about what the client wants. If
the client wants 1x images for whatever reason, it doesn't matter what their
screen resolution or pixel scaling factor is, or whatever your script is using
to determine support for 2x image display.

------
greggman
How would this effect sprite sheets and images used in with the canvas 2d API?

