4 ms·
The blog seems to contain other similar misunderstandings: for example the parallel article against using SVG images doesn't consider scaling the images freely
by HelloNurse 10mo ago
The blog seems to contain other similar misunderstandings: for example the parallel article against using SVG images doesn't consider scaling the images freely a benefit of vector formats.
- chrismorgan 10mo agohttps://aloisdeniel.com/blog/i-changed-my-mind-about-vector-graphics https://aloisdeniel.com/blog/i-changed-my-mind-about-vector-... seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. (I still feel the article is misguided and that the benefit of runtime-determined scaling should have been mentioned, and see no benchmarks supporting its performance theses, and I’d be surprised if the difference was anything but negligible; vector graphic pipelines are getting increasingly good, and the best ones do not work in the way described, and could in fact be more efficient than raster images at least for simpler icons like those shown.)
- eviks 10mo agoAre there display pipelines that cache the generated-for-my-device-resolution svgs instead of doing all the slower parsing etc from scratch every time, achieving benefits of both worlds? And you can still have runtime-defined scaling by "just" rebuilding the cache?
- chrismorgan 10mo agoIncreasingly I think you’ll find that the efficient format for simple icons like this actually isn’t raster, due to (simplifying aggressively) hardware acceleration. We definitely haven’t reached that stage in wide deployment yet, but multiple C++ and Rust projects exist where I strongly suspect it’s already the case, at least on some hardware.
- HelloNurse 10mo agoThe best place for such a cache is a GPU texture, and in a shader that does simple texture mapping instead of rasterizing shapes it would cost more memory reads in exchange for less calculations.
- IIsi50MHz 10mo agoHaiku (OS) caches the vector icons rendered from HVIF[1][2] files which are used extensively for UI. I didn't find details of the caching design. Possibly it was mentioned to me by waddlesplash on IRC[3]. [1] 500 Byte Images: The Haiku Vector Icon Format (2016) http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html http://blog.leahhanson.us/post/recursecenter2016/haiku_icons... [2] Why Haiku Vector Icons are So Small | Haiku Project (2006) https://www.haiku-os.org/articles/2006-11-13_why_haiku_vector_icons_are_so_small/ https://www.haiku-os.org/articles/2006-11-13_why_haiku_vecto... [3] irc://irc.oftc.net/haiku
- eviks 10mo ago> The drawback to using vector images is that it can take longer to render a vector image than a bitmap; you basically need to turn the vector image into a bitmap at the size you want to display on the screen. Indeed, would be nice if one of these blogs explained the caching solution to tackle the drawback. Another issue, I think, especially at smaller sizes, is the pixel snapping might be imperfect and require "hints" like in fonts? Wonder if these icons suffer from these/address it
- cosmotic 10mo agoIcons are no longer fixed sizes. They're are numerous dpi/scaling settings even if the "size" doesn't change.
- chrismorgan 10mo agoThe article goes into that, it’s making a sprite map of at least the expected scaling factors.
- rerdavies 10mo agoThere are no "expected" scaling factors anymore.
- HelloNurse 10mo ago> seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. That's the point: obliviousness to different concerns and their importance. Among mature people, the main reason to use SVG is scaling vector graphics (in different contexts, including resolution-elastic final rendering, automatically exporting bitmap images from easy to maintain vector sources, altering the images programmatically like in many icon collections); worrying about file sizes and rendering speed is a luxury for situations that allow switching to bitmap images without serious cost or friction.