In practice a HiDpi image of 2000x1600 pixels (1000x800) is indistinguishable from a normal 2000x1600 image. Should we detect the browser's dpi to deliver the best image size?
No, way too complicated. I think the answer is simpler than that. There really is no such thing as a "HiDPI image." It's just an image that's twice the size. So how does that work? Simple. jAlbum just
lies to the HTML about how large it is.
A simple HTML skin doesn't ask the JPG how large it is. It asks
jAlbum, and then does something like this:
<img src="${imagePath}" height="${imageHeight}" width="${imageWidth}">
So, the lie works, and the browser shows the image in a space that's actually half the size of the image. For a retina display, that's great, and for a normal display it's undetectable, other than having to do some quick browser resizing.
In a scripted skin like Matrix or Tiger, that's a problem, since the script normally isn't asking jAlbum what the image dimensions are. The script is just looking at the JPG itself, and not enlarging it beyond its actual dimensions. So the lie doesn't work.
I'm not sure how, but Turtle is currently doing this correctly. If you tell it to "shrink only," and give it a HiDPI image that's actually 2000x1600, it never shows it larger than 1000x800. Apparently, Turtle is paying attention to the phony
imageWidth and
imageHeight numbers that jAlbum is cranking out. So it does what's intended - it shows the image in half the space of its actual dimensions. Good for retina, with its higher pixel density, no problem for regular displays.
So what's the answer? Somewhere in your script in Tiger, if the choice is never to enlarge the image beyond its real dimensions, the script needs to say, "don't make this bigger than
imageWidth x imageHeight, regardless of the JPG's actual dimensions."
