About those vector icons (2011)
pushing-pixels.org
pushing-pixels.org
HVIF supports only basic shapes with integer coordinates (by default) and detail reduction. Each shape is tagged with a minimum and maximum scale³--computed from a base icon size of 64x64--at which it should be visible. Rounding and hinting bring those shapes within tossing distance of custom-drawn icons at small scales.
¹ Leah Hanson's post is quite illuminating, though it focuses more on the small on-disk size of HVIF data; http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...
² https://web.archive.org/web/20070111153750/http://haiku-os.o...
³ "stippi"'s original announcement: https://www.freelists.org/post/haiku/Icon-Artwork
I’ll also highlight the concept of designing for the medium; it might make more sense to create a design that does seamlessly scale without manual involvement than to do the designer’s first idea and then manually tweak that to work in every possible variation.
Given that much of the time svg is perfectly reasonable, I wish platforms had better support - I’ve found Xamarin.Forms, UWP, WPF, and native iOS all wanting. Web seems to be about the only place it works seamlessly nowadays.
Also, if anyone in the Windows desktop team is here, please support SVG desktop backgrounds. Often my desktop is vector art and I’d like to skip the jpg middle man and get something that scales to all my monitors well by default. You were somehow weirdly on the right track with the Windows 8 start backgrounds fwiw.
I think it still applies. In my experience, as we’ve gone far away from skeuomorphic design (hey, it’s 2011 in the title, we can use that word), having those nice razor sharp minimalistic icons at 20pt/dp or smaller sizes means you do want to draw them with care. You can notice the slop when something doesn’t fall on a nice integer position.
Especially as we still are not in a fully HiDPI world. I came across this the other day when I was trying to create an icon for a 5×5 matrix. Looked great on my MacBook Pro screen. And then I dragged it to my external display that I keep for testing. And oh. Yikes. I needed to tighten things up.
When I walk into a hardware store planning to appropriate some part for a different purpose than intended, my first question is "who has this problem?"
I've been exploring mind-mapping software. It's astonishing how primitive the namespace handling can be. Shades of the flat file system from a 1984 Macintosh (mine had an early serial number). Same question: Who understands this issue? Programming language designers. Everyone else is just guessing.
Fonts change design at different scales.
And it seems like a solution to excessive aliasing (in the sense of a dark thin line rendering as a not-so-dark double-wide line) could be to round the desired size down to the nearest known-good size and pad the edges with negative space.
A single good SVG can obviate your small raster images and the 2x and 3x versions you might need for HiDPI screens. You can also get automatic handling of dark mode with no changes to your page's CSS.
There's work involved but the flexibility is pretty awesome.
In addition, vector-effect="non-scaling-stroke" allows you do declare that a line is [eg] 1px thick, regardless of the image size.
Snapping to sizes would be possible, but not straightforward, until CSS supports calc(round()) https://www.w3.org/TR/css-values-4/#round-func
It feels surprising to see such a limitation on my Modern apple devices, for example, when I change scale and everything violently snaps to refit.
The tradeoff between a little bit or human touch and effort upfront vs higher energy and CO2 expenditure overall is not something I find personally compelling
You'd need more powerful video cards, sure, but for typical 2D graphics, the difference is on the order of 5-10W, which isn't exactly going to boil the oceans...
Even on high-res displays, small versions of icons would benefit from separately made versions that leaves out some detail.
More pixels only addresses the blurriness caused by a display's low resolution. The other side of the problem is the limitations and quirks of human vision, which require a different set of adjustments to increase legibility at small sizes. And arguably, increasing resolution can make everything smaller (esp. if there isn't a 'High DPI' setting, and so makes the size problem even more urgent.
The design adjustments needed by icons at small sizes are closely related to optical sizing in fonts (increasing x-height, lower contrast, heavier weight, large terminals and serifs are shrunk, small ones enlarged, etc.), except that an icon's topology ofyen needs to change as well.
A simple example is that if a large icon features a 3x4 grid as a design element, at small sizes it may need to be a 2x3 grid instead, the point being that the grid-ness of the design element is the important part, not the specific number of rows and columns.
Other design elements may just need to be removed entirely (such as digits or division markers on a clock face).
These sorts of 'optical icon adjustments' (I'm not aware of any other term for them) are really important for icons, perhaps more important than optical adjustments to fonts, since icons are less familiar and so are harder to recognize.
In summary, increasing the resolution of the display only solves half the problem (and often makes the other half harder).