HiDPI/Retina image upsizing by clients & servers, not javascript

by skeltoac • 14 years ago

27 28 14 years ago

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.

skeltoac4• 14 years ago

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.

tpenzer6• 14 years ago

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

michaelbuckbee• 14 years ago

I think it's so that on the individual image requests the server could be 'smart' and decide whether to return a 2x image or not.

tpenzer6• 14 years ago

With the solution I propose, it seems like the server could be blissfully dumb, and the client could be smart and choose whether to request 2x images if the page author indicates they're available. I don't see the advantage in this regard.

KrisJordan2• 14 years ago

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.

tpenzer6• 14 years ago

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?

tlb• 14 years ago

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.

WiseWeasel4• 14 years ago

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.

dorianj• 14 years ago

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.

WiseWeasel4• 14 years ago

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• 14 years ago

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).

greggman2• 14 years ago

There are already ratios of 1.5, 1.33 and 2.25 in the wild.

See Android

WiseWeasel4• 14 years ago

Wait, are you saying there's a version of Android somewhere that ships with a web browser which actually specifies its device pixel ratio as a non-integer? I am dubious, since I assume that would force rough anti-aliasing on everything and look like crap.

skeltoac4• 14 years ago

I mistakenly included a great deal of peripheral detail in the first draft. It's not as complex as all that. It is sufficient to provide only 2 versions of each asset: the 1:1 default and a higher-res version, whether it's 2x or 15MP.

You mention an HTTP header indicating DPI. Sending device pixel ratio is already a major part of the HAIR proposal; see Example 2. If that's all that got added to browsers and servers, it would eliminate most of the app-level solutions out there.

greggman2• 14 years ago

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

zacman852• 14 years ago

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.

WiseWeasel4• 14 years ago

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.

HiDPI/Retina image upsizing by clients & servers, not javascript

Related Stories