3 ms·

> The goal of the Haiku Vector Icon Format (HVIF) is to make vector icon files as small as possible. This allows Haiku to display icons as several sizes while s

by dahart 7y ago

> The goal of the Haiku Vector Icon Format (HVIF) is to make vector icon files as small as possible. This allows Haiku to display icons as several sizes while still keeping the files small enough to fit into an inode (i.e., inside a file’s metadata). The goal of keeping the icons in the metadata is to reduce the disk reads needed to display a folder – it allows each file to only require one disk read to display. This is a great goal, a very cool file format, and a very nice article! That said, my main worry with this approach is that it might not be comparing or addressing the most common production workflows, which typically pack many icons into a single compressed file, and only unpack them in memory. When you pack multiple icons, you amortize all of the file reads into a single one. It’s extremely common in games, web, and even desktop apps, to also pack the images or other assets that icons represent into compressed files. If you do pack your assets into zip files on disk, then it’s possible to lose disk space by converting to a binary icon format that might be less compressible, with no real gain in terms of disk reads or disk seeks -- and if you separate files instead of packing them so that you get icons in your inodes, you might be increasing the number of disk seeks & reads considerably.

waddlesplash 7y ago
Storing the icons in inode attributes is just one use of icons on Haiku; plenty of applications embed them as resources (i.e. in a data section of the binary), which is more or less what you are describing here.
- dahart 7y ago
  Sure, I understand you aren't forced to store them in inodes, just pointing out (since it's part of the sales pitch here) that doing so might have unintended consequences since people don't usually load small icons from many separate files or web requests. It seems like a savings if you assume using single separate files, but if you store your assets in a zip file, then switching to keeping them in inodes might actually slow down the app. All the production games and web apps I've ever seen and/or worked on personally store many assets packed into single file. It is worth thinking carefully about the tradeoff here. You are taking a functionality hit compared to SVG, and adding a new indirection and more tool dependencies to your pipeline in order to use HVF files. Ideally the payoff should be worth the effort, but if you zip all your SVG icons, how often is the compressed data averaging considerably more than 500 bytes per file? I just checked Google, and the first hit for free SVG sets is Feather, a 132kb zip file containing 282 icons, which clocks in at 480 bytes per icon on average. Regarding storing icons in the data section of the binary, that is certainly one way to pack assets, but not one I would use or recommend personally. That locks you into shipping a binary if you want to update assets, it doesn't apply to web dev, or scripting languages, and it's pretty OS/platform specific. Typically what I've seen in production really is some kind of zip-like container file that is compressed and loaded separately from the application.

by dahart 7y ago

waddlesplash 7y ago

Storing the icons in inode attributes is just one use of icons on Haiku; plenty of applications embed them as resources (i.e. in a data section of the binary), which is more or less what you are describing here.

dahart 7y ago
Sure, I understand you aren't forced to store them in inodes, just pointing out (since it's part of the sales pitch here) that doing so might have unintended consequences since people don't usually load small icons from many separate files or web requests. It seems like a savings if you assume using single separate files, but if you store your assets in a zip file, then switching to keeping them in inodes might actually slow down the app. All the production games and web apps I've ever seen and/or worked on personally store many assets packed into single file. It is worth thinking carefully about the tradeoff here. You are taking a functionality hit compared to SVG, and adding a new indirection and more tool dependencies to your pipeline in order to use HVF files. Ideally the payoff should be worth the effort, but if you zip all your SVG icons, how often is the compressed data averaging considerably more than 500 bytes per file? I just checked Google, and the first hit for free SVG sets is Feather, a 132kb zip file containing 282 icons, which clocks in at 480 bytes per icon on average. Regarding storing icons in the data section of the binary, that is certainly one way to pack assets, but not one I would use or recommend personally. That locks you into shipping a binary if you want to update assets, it doesn't apply to web dev, or scripting languages, and it's pretty OS/platform specific. Typically what I've seen in production really is some kind of zip-like container file that is compressed and loaded separately from the application.