Scaling artifacts occur because at smaller sizes the quantitization of the unit pixel overwhelms the details of the image. When I was a system programmer at the Image Processing Institute at USC (you know the source of that Lena picture :-) this was characterized as the frequency response of the display. So if you were to take a horizontal line across the pixels, and then plot their intensity vertically along a line (so x becomes the position in the line, and y is the intensity of the pixel at position x) then you can then do an FFT across those pixels and see the distortion in the visual signal from the source material to the displayed material.

Now the part that gets confounded in articles like this one is that the UX designer doesn't really want a 16 pixel icon, what they want is an icon that has a certain size with respect to the whole screen. Working backwards, lets say the icon ended up being 16 x 16 on a 1024 x 600 screen which had 72 pixels per inch. The icon is about 1/4" on a side (.22" but you get the picture). Now on a screen that that has 240 pixels per inch, that icon at 16 x 16 pixels is only .06" or nearly impossible to see, but if you keep it at 1/4" you get 60 x 60 pixels to work with.

So lets bring two things together, you do 'hinting' because the artifacts that are created by the quantitizing effect of pixelation cause you to lose information. As screen resolutions get denser the information lost goes down (less quantization, or more signal bandwidth is available) so once your signal loss from a straight mathematical shrink is acceptable in all required sizes your done.

Bottom line is that this won't be an issue when the minimum icon size is being rendered into a field of 128 x 128 pixels or more. Might take one more generation of screens.

The second thing is that while a designer can poke pixels to get an icon that looks good, so can the computer. One of the things you can do is compute the frequency 'footprint' of the image, then change the render until the render foot print is as close as you can get to the original. HP did this for their ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could almost exaustively search it on a modern machine.

If you read the closing paragraphs of the article, you will see that I do talk about the physical size of the final representation of the pixel-based icon. However, just because you can use more pixels on higher-resolution displays, it does not mean that you can just take a highly detailed vector artwork and display it.

Being able to display very intricate details for each icon is not necessarily the end goal. The end goal is to preserve the clarity, which is why smaller icons (physically, not pixelwise) should have smaller amount of detail compared to larger ones.

In your example, a 128x128px icon that occupies the same physical size on an extra-high DPI screen as a 16x16px icon on a lower-end screen can (mathematically) have 8 times as much detail along each axis. Just because this is possible to do without losing the signal quality on the level of individual pixels, does not mean that it is desirable from the UX / UI perspective.

So when you go from thinking about pixel size to thinking about physical size, you're going in the right direction, but you're not going far enough. The relevant metric is more like "the angle subtended at the user's eyes", kinda like how the "CSS pixel" unit works.

Now, given that it's almost impossible for software on the device to know how far away the user is, trying to design up front for that metric (angle subtended by the icon) is also almost impossible.

And even if you did know both the pixel density and the distance to the display, that still doesn't take into account the fact that users will vary in their visual acuity. The right design choice for a 20-year-old user holding the display close to their face is going to be dramatically different from the right choice for a 70-year-old holding the display at arms length.

You can't really design well for all those possibilities up front. The right answer has to involve allowing the user to adjust the "zoom level" to their liking. And that level of flexibility means that automated approaches (possibly something like freetype's autohinting, extended to work in color) are probably going to be a better approach than manual pixel tweaking.

There are two problems you are conflating. One is that low-resolution icons have visual artifacts, and therefore manual pixel hinting is valuable. In general though, this problem only crops up for very small icons, say smaller than 32x32. But as screen resolutions increase, this problem will get easier.

The other problem is that at small sizes, we want icons to be less detailed and therefore more recognizable. A quarter-inch icon two feet from the eyes should have very little detail. This is a problem that vector graphics are very suited for. One can specify a low-detail icon that should be used when the real size of the icon is below some threshold, no matter whether that screen space is 64x64 or 20x20. In a world where the screen resolution of an icon that size can vary by more than a factor of two, using pixels is the wrong approach.

Cool! Do you have a link/paper/book?

http://www.stanford.edu/~slansel/tutorial/Papers/Donoho/Imag...

Are exemplar uses of the FFT to analyze the signature and content of an image. Since a lot of work on this was done in the 80's I would expect some good summaries in the current texts on image processing.