4 ms·

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),

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.

4 ms·

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),

by waddlesplash 7y ago

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.