1. 32

  2. 5

    I don’t really understand the rationale for storing a file’s icon in its inode. Most of the time the icon is based on the file type/extension, which is obviously shared by many files, so you can use an in-memory cache to avoid any disk I/O at all. The cache can contain pre-rendered pixmaps so you don’t have to waste time rendering either.

    For files with custom icons, almost always the icon is a thumbnail of the contents, which means a pixmap, not vectors. (Even a vector based document wouldn’t use a vector thumbnail, because the thumbnail would be just as complex as the entire document, only shrunk down, unless you did some complex post processing on it to remove details.)

    I do agree a vector format is great for storing the file-type icons, though. With retina displays, macOS icons are now recommended to go up to 512x512px, which is becoming ridiculous. As someone who programmed a Mac SE back in the day, I find the idea of my app’s icon not fitting on a floppy disk appalling.

    1. 5

      Most of the time the icon is based on the file type/extension…

      Yes, and the same is true on Haiku. Applications, which have their own icons, are the primary consumers of the “icons-in-inodes” feature.

    2. 2

      I found it hard to find much information about this format, but somebody wrote a library, with an SVG converter.

      1. 4

        The linked article did, I thought, do a good job getting into the format. This is actually one of a few pieces of Haiku that I badly wish would leak out; it’s so well suited for icons on the web.

        1. 3

          I was hoping the article would give (or link to) a complete spec.

          I agree that it’s well-suited for icons on the web. Also, I wish that a format like this would replace SVG as the dominant vector graphics format. SVG files are huge, & a markup format would make sense if humans were reading & writing these by hand, but most SVG files are made in graphical editors & can’t really be understood by a human reader so there’s no point in keeping the bloat. A packed binary format that represented everything that SVG represents but in a handful of bytes would be really great. (HVIF doesn’t seem to be quite as expressive as SVG unfortunately.)

          1. 2

            SVG is an XML schema, right? That explains why it’s so bulky. It makes some sense in a browser — a displayed SVG has its own DOM, which can be manipulated by JS — but it’s awful as a transfer format.

            Apple platforms tend to use PDF for vector graphics. I know PDF started out as a wrapper around PostScript, but I think it’s a more compact binary format.

            1. 3

              PDF is a fairly bulky & hard to implement format, unfortunately.

              Re: binary SVG – I think it’d be worthwhile to have a packed binary format that was exactly semantically equivalent to SVG, the way that BSON and msgpack are (almost-)exactly semantically equivalent to JSON. Then it can be inflated into a DOM without all the complex logic of parsing actual XML. (More achievable: have a binary format that only supports the whole of the subset of SVG supported by major vector graphics editing programs & SVG rendering libraries – and doesn’t represent the extra stuff that XML can have but will be ignored by every real implementation.) At work I’ve run into performance problems caused by sending large SVG files to users – for stuff like outlines, where even a naive binary format would shrink the file by at least two orders of magnitude. (You would get some but not all of these space savings from using conventional compression, but for the worst offender files, the window size would be too small.)

      Stories with similar links:

      1. 500 Byte Images: The Haiku Vector Icon Format via ehamberg 4 years ago | 30 points | 7 comments