[HN Gopher] 500 Byte Images: The Haiku Vector Icon Format (2016)
       ___________________________________________________________________
        
       500 Byte Images: The Haiku Vector Icon Format (2016)
        
       Author : smartmic
       Score  : 25 points
       Date   : 2024-04-29 09:37 UTC (13 hours ago)
        
 (HTM) web link (blog.leahhanson.us)
 (TXT) w3m dump (blog.leahhanson.us)
        
       | pimlottc wrote:
       | This is great and all but how do they look? The only good example
       | is the tape recorder which imho looks less and less like a real
       | tape deck at larger sizes; the shape of the tape is noticeably
       | distorted and the curves in the shape of the body are
       | unrealistic.
       | 
       | Saving space is well and good but for icons it's secondary to how
       | clear and usable the images themselves are.
        
         | tdeck wrote:
         | I found a repo of the Haiku icons in various formats:
         | https://github.com/darealshinji/haiku-icons
         | 
         | Typically how they look is up to the designer, they can decide
         | how many small details they want to put in to make the icon
         | look better at a larger scale. Haiku seems to have gone with a
         | kind 3d clipart style that isn't highly detailed.
        
         | zamalek wrote:
         | Haiku has an extensive UX and design guidelines document -
         | including meticulous rules for icon design. The tape recorder
         | looks that way because it adheres to those guidelines, not
         | because of a file format.
        
       | tedunangst wrote:
       | Previously: https://news.ycombinator.com/item?id=22373422 And:
       | https://news.ycombinator.com/item?id=12420763
        
       | tdeck wrote:
       | > If you use the standard bitmap icon formats, you'll probably
       | store them in their own files, separate from the files that use
       | them. In order to display each file in a folder, the operating
       | system will need to read the metadata for the file (including its
       | name and file type) and then read the icon file for that file
       | type. If the icon file were so small that you could store it in
       | the same place as the file metadata, then you could save a read
       | from the hard drive - you could get the metadata and the icon all
       | in one read.
       | 
       | > ... it could be a significant performance gain to halve the
       | number of disk reads even if rendering a vector image takes
       | longer than rendering a bitmap.
       | 
       | Surely another option would be to cache all the filetype icons in
       | memory and thereby only read them once? You could still use this
       | cool vector format and get the best of both worlds, so each icon
       | would be small and would be read only once, and you wouldn't have
       | duplicate icon data all over the disk. And then if you wanted to
       | change the icon associated with a particular filetype, you
       | wouldn't need to update every single inode for files of that
       | type.
        
       | zamalek wrote:
       | 24x24 and below still require special treatment because pixel
       | grid alignment becomes really important. The tape recorder image
       | demonstrates this well: the raster 16x16 looks way better than
       | the vector. I wonder if it would generally be better to store
       | these tiny sizes as bitmaps in the container.
        
       ___________________________________________________________________
       (page generated 2024-04-29 23:01 UTC)