Submitted by The Haiku Project recently introduced a new and more efficient scalable vector-based icon format, the Haiku Vector Icon Format, or HVIF for short. HVIF uses a special vector storage format specifically designed to store icons that is so efficient, that icons in Haiku take a meager 500 – 700 bytes on average. Following the introduction of this new icon format, the Haiku developer behind this new icon format, Stephan Assmus (Stippi), has published two articles, one introducing some interesting facts about HVIF, and another giving some details of why Haiku vector icons are so small.
That maybe this format will make vector graphics ubuquitious. There are still way too much resolution dependent icons everywhere.
Sort of like how GNOME (or was it KDE) is using SVG, a standard vector graphics format?
I fail to see the need for an “optimized” non-standard format (optimized for what, disk space is cheap), I think SVG would’ve been a much better choice.
– chrish
Read the linked articles. It is explained pretty well.
“I think SVG would’ve been a much better choice. ”
The backseat drivers have spoken.
It’s not about diskspace but speed of loading the icons from disk, these small icons can fit into an inode or something and thus just one call is sufficient to represent the file with it’s icon (and possibly all other 2 million BeOS attributes?) in a file manager.
Well better read the article.
Am I the only one who read “Everything You Wanted to Know Aboutr HIV” ?
More on topic :
Im glad that the Haiku Project is seemingly getting along quite nicely .
Icon formats with low size are of course not only great on Hailu but also any other OS – especially with icons getting fancier & fancier and well .. eating more & more rescources .
Okay they are “just” icons but there are quite a few of them .
It actually is a real issue for me in GNOME on SuSE because they are not preloaded as in KDE it seems – resulting in laoding lag on every submenu .
BTW comment : Are there any animated icons in Vista or OSX or some other Linux ?
Enlightenment yes – but rest ?
RE “A New Hope” : I doubt it will get rid of Vector-cons .IMO Vector is the future for the desktop because it should not I guess eat rescources as much as pixel based stuff – especially when the icons get bigger – which the Haiku icons still seem to be & vector can be manipulated on the fly as its created that way AFAIK .
Edited 2006-11-14 19:31
I read it as HIV too for a second.
How about just typing Haiku Vector Icon Format in the headline instead of the an acronym no one is familiar with ?
I read that Haiku is the new name for OpenBeOS.
Sounds like a project to watch.
yeah… Not very new though. ‘Haiku’ has been around for like 4 + years now.
Not very new though. ‘Haiku’ has been around for like 4 + years now.
Technically, the “Haiku” name was revealed at Waltercon 1 – which was a little over 2 years ago… so mjones is only a couple years out of date
oh ok
thanks for the correction.
Helf helf helf, get your data right before jumping down someone’s throat!
i wasnt jumping down his throat
Who said bigger is better? Not the Haiku developers. Those guys are quite extraordinary in what they bring to their OS.
I am more and more convinced that if you take care of the details in code, the rest of the system falls into place quite well..
Think about it, here on Haiku we’re concerned about _bytes_, which directly impacts the _speed_ of the system, which directly impacts how users feel about the system, and how they react to it’s ability to react.
Then you’ve got Windows, Linux, and every other OS that’s been steadily bloating itself worse than the waistlines of fat americans binge eating fast food.
…that the Haiku developers spend time on the realy important matters.
As any mac fanboy will tell you, while some things are more important than others…Sometimes it’s all in the details.
I just ask myself wether it is really worth it to define a completely new format.
First, good and established file standards are very important to the open source world, having to get over closed “industry” standards. If the open source world itself can’t settle on these standards, it can only lose. What’s so wrong with SVG for icons?
Next, the format’s biggest benefit comes from it’s biggest problem: It is very limited. For example, you have a very limited set of coordinates (127). It won’t be easy to convert an SVG to this format, as this limitations can simply kill the original image/drawing. Also it could also make it more complicated to get an icon done for an artist, because he sometimes sure has to try out several possibilities to “overcome” these limitations.
Let’s have a look at the main feature of this format: file size. It’s really impressive, yes. But I really ask, is the file size factor not a little bit overestimated for _vector_ icons? Sure, RGB 128×128 icons get big (50 kb each!), but vector drawings don’t get that big in first place. So if you compare to SVG, you will see the benefit is small.
Someone here pointed out that Gnome has problems drawing icons fast enough. First, one has to consider wether this is really loading speed or drawing speed. Loading data from a disk which is smaller than 1 MB surely has it’s main cost in the seek time, not the time that is needed to actually read the data itself. Here a solution could be to pack a load of icons into one single file, but not to reduce the size from some kb to some 500 bytes.
And when it comes to vector icons, I think, drawing them is the more costy operation. I don’t think this format makes it faster, but it perhaps could just due to the fact, that the artists don’t have the possibility to do too complex things in their icons
I liked the idea very much that just a PNG or a SVN can be used as an icon, and you don’t have to bother about a special format for it, like .ICO. Or in this case, this fancy new format. I can draw an icon with every graphics app I like, let it be Gimp or Sodipodi. I guess this will be hard for the new format.
cu
Ford Prefect
Edited 2006-11-14 20:18
Edit time was up, so before my last paragraph insert this one:
Sure, the author addresses this as he tells Icons now fit into file attributes on BeFS and therefor the extra seek for an icon file isn’t needed. So, assigning an icon to a file would copy it into it’s attributes? I don’t know, if I like this, but it sounds interesting. It won’t help on any other FS, though, and it sounds a little bit hackish. I would be interested, if this part is really implemented or only a suggestion.
What’s different and interesting is that OBFS equates one inode to a file, instead of packing multiple file headers in. That is both good and bad. Good because it is simple, easy to understand, you don’t have to move blocks around on rename, etc. Bad because it is not maximally disk efficient. It makes ls, for example, take longer because the FS has to look at more blocks.
The relevance here is that there is space in the inode once the filename, first datablock, etc are stored. That is used for attributes. We store the icon as an attribute. The advantage is that opening up a Tracker view means that one block is read for the name, date and icon. That is a very good thing.
SVG is XML based. XML is very verbose and wordy. There are ways around that, but they are not really all that great, either. If we used SVG, the icons would exceed the space for an inode. That would be bad. We invented our own format (well, I say we, but Stippi, really) because there was no format out there that fit the specific need. Much the same reason that PNG was invented instead of using one of the dozens of other gfx formats out there (jpg, gif, bmp, ilbm)…
Edited 2006-11-14 20:55
I just ask myself wether it is really worth it to define a completely new format.
Yes. Just read the article behind the second link.
Reason 1: they’re now so small they can be stored next to the inode, which means instead of seeking the inode, then seeking the place where the file is stored then read, it’s just a seek of the inode+read. That will matter in terms of loading speed when the icons of a lot of icons need to be loaded at the same time.
Reason 2: instead of normal SVG icons, these can be rendered in a single pass instead of multiple, saving CPU cycles, thus enhancing desktop responsiveness.
The only reasons against it, would seem to be the extra effort involved in implementing it (and apparently it was simple), and inter-operability. The latter which seems like a non-issue, since we’re talking about custom Haiku-icons, and Haiku supports other formats as well
I hate to be that sort of guy, but…
I just ask myself wether it is really worth it to define a completely new format.
Yes, reasoning on the first article. And it’s not as if this format is extremely complicated anyway; the format is very succint and Stippi’s articles double as great documentation for it.
First, good and established file standards are very important to the open source world, having to get over closed “industry” standards. If the open source world itself can’t settle on these standards, it can only lose. What’s so wrong with SVG for icons?
Whereas I agree that established file standards are really important, you can’t just take a standard as the hammer to which everything else become nails. People have made this mistake with XML when it was but hype; common sense is finally settling in.
SVG, being XML, is a verbose format. It simply won’t fit the requirements of Haiku, which are making the common case fast, keeping backwards API compatibility with legacy bitmapped icons, and not breaking those legacy icons.
Other formats weren’t banned, you see; alternative vector formats could be included as special cases, but that would require additional APIs. That’s a R2 task.
And — and this is important! — SVG icons can be imported into Icon-O-Matic. Most of them look absolutely fine after importing; some will require extra tweaks. Don’t you think gorgeous icons deserve some little tweaking when necessary? It’s not like it would cost you an arm and a leg
Next, the format’s biggest benefit comes from it’s biggest problem: It is very limited. For example, you have a very limited set of coordinates (127). It won’t be easy to convert an SVG to this format, as this limitations can simply kill the original image/drawing. Also it could also make it more complicated to get an icon done for an artist, because he sometimes sure has to try out several possibilities to “overcome” these limitations.
I guess you only skimmed over the article. The coordinates are abstracted to 64 points, with some room for out-of-scale points; totalling 127 points then. It’s an ABSTRACT coordinate; with the alternative 2-byte representation, you have subpoint precision with the first byte keeping its meaning and the second byte holding the fraction.
Let’s have a look at the main feature of this format: file size. It’s really impressive, yes. But I really ask, is the file size factor not a little bit overestimated for _vector_ icons? Sure, RGB 128×128 icons get big (50 kb each!), but vector drawings don’t get that big in first place. So if you compare to SVG, you will see the benefit is small.
Take ANY significant SVG (by that I mean anything that resembles the least complex icon of Stippi’s set) icon and try to have it fit 1280 bytes. ANY.
Someone here pointed out that Gnome has problems drawing icons fast enough. First, one has to consider wether this is really loading speed or drawing speed. Loading data from a disk which is smaller than 1 MB surely has it’s main cost in the seek time, not the time that is needed to actually read the data itself. Here a solution could be to pack a load of icons into one single file, but not to reduce the size from some kb to some 500 bytes.
That works better for library icons — i.e.; those that come with the DE theme of your choice –, not custom icons that 3rd party apps will bear. And it would break API compatibility.
And when it comes to vector icons, I think, drawing them is the more costy operation. I don’t think this format makes it faster, but it perhaps could just due to the fact, that the artists don’t have the possibility to do too complex things in their icons
As mentioned before, HVIF allows for single-pass rendering. Because of that, combined with the small size and clever primitive operations, drawing is orders of magnitude cheaper than the time it takes to read the icon from disk. I mean it; if you’re going to display any information regarding a file, you’ve already read its inode anyway, and look, there’s where icon data resides! Pretty clever, huh?
I liked the idea very much that just a PNG or a SVN can be used as an icon, and you don’t have to bother about a special format for it, like .ICO. Or in this case, this fancy new format. I can draw an icon with every graphics app I like, let it be Gimp or Sodipodi. I guess this will be hard for the new format.
So… What’s there not to be liked, then?
Remember: any sizeable API changes must wait until R2; the development resources are too scarse to allow such changes in R1 time. The SVG icons were stippi’s own pet project, his implementation is superb AND it kept API compatibility.
Edited 2006-11-14 23:26
I just ask myself wether it is really worth it to define a completely new format.
IMO yes. In fact I would go as far as to say I encourage those working on Haiku to go ahead and do things their own way when they think it is better than the “standard” way of doing it.
I find that this is one area where Open Source in general suffers compared to traditional for-profit software, and I would like to see Haiku be different. Innovation runs rampant in the FOSS world, but it only goes so far. Once something is good enough no one cares about it anymore and it becomes a “standard”. Once something becomes a standard, it takes an act of God to change it.
Standards are a two-edged sword. Standards are great in principle. They save time on coding (don’t have to re-invent the wheel). You get better interoperability, lower defect rate, etc. etc. But what inevitably ends up happening is that they make people stop thinking. If you need to store some kind of hierarchical data, you just say to yourself “use XML” and no further thought goes into it.
This guy actually _thought_ about it and reasoned out a better way (at least for a particular usage). The latency improvement due to the small space savings might not be much when considered alone, but little things like this are WHY people are still so enamored with beOS (and now Haiku). Hundreds or thousands of these types of little improvements are what makes people describe it as small, fast, lite, nimble, snappy, etc. I want Haiku to be special, not just another big and bloated alternate OS.
What a whiny bitch.
Did someone piss in your Cheerios? No.
Someone developed a better format for a specific case. It’s called using a proper tool for the job, or creating a new tool to handle someone everyone else (all other vector icon OSs) have overlooked.
The performance implications and benefits of this are huge. They far outweigh any whiny bitch XML / SVG fan-boi bullshit.
Grow a pair of balls and swallow your pride, or go write an SVG whiny-bitch approved icon format that’s faster than HVIF.
I had to mod that one up – it made me chuckle!
I find it somewhat ironic that people come out of the wood work to spout off why they think performance is unnecessary, etc. – and Haiku should follow the crowd (their preferred OS that is)…
They are the very same who bitch and complain about performance when it affects THEM… as in, 6 months after they bought their $3000 gaming PC. They complain about performance of the latest-and-greatest POS bloatware that hits the shelf because their machine is “out-dated” (read: doesn’t have the newest mega-dollar video card).
They can’t appreciate the beauty and simplicity of well-written code and algorithms, and instead just want everything their way.
Reinventing the wheel is not always a bad thing – especially when that wheel doesn’t fit in the first place – or is made out of the wrong materials…
Fine, so you think everybody just putting things in question is a $3000 gaming PC guy?
And you think getting personal in comments you not agree is a good thing? It’s funny to bash people who just have another point of view?
The poster you modded up just should grow up. I don’t know exactly about you, but perhaps you can at least tell me which part of _my_ comment led you to your glorious conclusions abut what kind of “people com[ing] out of the wood” I am?!
I have to agree with Ford Prefect and also point out something that is related to my experience, all talented artists I know really don’t want to expend their time tuning for something other than the beauty of their creations. It means they want to create their stuff on very capable programs (like Photoshop, Illustrator, CorelDRAW), many times mixing the best effects of them. They also usually gets irritate when the scaled results are subpar. All of them just want to create in one size, but its is just not feasible because of technical/biological reasons.
And what I would like to see solved is icons compositioning. Just look how many icons we have that could be generated on the fly by just stacking 2 to three others together! We need an icon library format for that but the saving space would be really huge.
I concur on the compositing notion. It’s actually already used in Linux, OSX, and Windows in various places (think shortcuts in Windows, or compressed files in KDE). What’s really missing there is a formalization of that. For example, a file icon.composite that’s a list of icons to stack atop each other:
#targz.composite
tar
gzipped
I really would like to see the impact of this on a real test scenario. There are many, many episodes on which optimizations went little to nothing after big efforts that I suggest them to benchmark the gains. If the promises payout I am sure they will get a lot of interest/cooperation.
PS. I know that the size of the icons could be a benefit for the cache too.
There is a version of OpenTracker with vanilla SVG support. yellowTab used it for Zeta. Performance was acceptable, but not ‘BeOS’ worthy. The latency is during disk reads, especially for larger directories. Once read, the icon is rendered from memory, so the only speed hit is the disk read operation. The new HVIF eliminates the additional disk seek and read. For a directory with several dozen files or more, this is quite noticable.
Heck, Haiku under emulation (Qemu, VMWare) reads and renders icons faster than Zeta native. Stippis work is amazing, old school at its best, where every bit counted for something. Add all these bits up, and you have the difference between MacSlowX and Haiku.
Actually, Zeta’s implementation of SVG was pretty much a real world proof that SVG icons wouldn’t fit in the inode’s attribute space. It really makes a huge difference.
helf – Haiku (the name) was revealed at WalterCon 2004. 🙂
It’s all amazing, I just hope every can just select the SVG icon they want and the system will make the conversion behind the doors… There’s no point in making the users make the conversion them selfs or make icon designers ship their icons in yet another format…
…but still, amazing work! =]
That was a lot of fun to read, and it sounds like a really good idea. Even if it’s not a real standard, screw “standards”… that idea is just plain cool. Having it be small enough to put with the file metadata is badass.
I’m still curious about how they do single-pass rendering though, that sounds like an interesting concept.
It seems strange to me that so many of the objections seem to be that Haiku is doing something different from everyone else.
Too many times in the past I have seen BeOS referred to as a version of UNIX/Linux. It is not! It is it’s own OS, it does run some Posix code, but it is no more Linux than my AmigaDOS was Linux.
The people writing Haiku have a vision that does not include having to do things the same as everyone else, and it seem odd to me that the very people who proclaim that users should switch away from the Microsoft standard (a standard for 90% of the world’s microcomputer users) should be objecting that Haiku does not follow their standard instead.
Since Haiku is an open source project, I’m not in a position to critize it. Nevertheless, I wonder whether it would not be a good idea to focus on more essential stuff than the icon format…
By looking to my Windows desktop and to the desktops of my colleagues, I estimate that they are at most 50 large icons visible (on the desktop), and at most 100 small icons (on the taskbar, in the start menu,…). The large icons have a resolution of 32×32, the small icons are 16×16. Even if I would double the resolution (i.e., 64×64 for the large icons and 32×32 for the small ones), the icons would only occupy ~1 MByte in the icon cache.
Obviously, RAM and disk size are not the problem here. The two linked articles mainly emphasize that the new format eliminates additional disk seeks. Is this really important? Most of the icons (desktop, taskbar,…) are only loaded once at system startup or when the user accesses the start menu (whatever it is called in BeOS) for the first time after a reboot.
To summarize: storage size is not a problem, loading time is not a problem. Has the Haiku project so many man power that it can afford to update the system routines, write icon creation tools, etc. for a new icon format?
Obviously, RAM and disk size are not the problem here. The two linked articles mainly emphasize that the new format eliminates additional disk seeks. Is this really important?
To summarize: storage size is not a problem, loading time is not a problem.
Depends, if you want to write an OS with low system resources then both RAM and disc size are both problems that need to be considered.
If you wanted to boot off flash and run on a system with very limited memory a system like this is going to have a distinct advantage.
If you don’t consider things like this you end up with systems which consume lots of RAM and run slowly – like most modern desktop OSs.
Has the Haiku project so many man power that it can afford to update the system routines, write icon creation tools, etc. for a new icon format?
It’s an open source project so it’s not strictly planned, the man power does whatever it choses!
The loading time is important. Those 100 icons you mention will not always be the same icons – every time you open a new Tracker (Explorer) window, you get dozens of new icons.
> every time you open a new Tracker (Explorer) window, you get dozens of new icons.
Really? The overwhelming part of the users I know always use the same set of (at most) twenty applications and games (usually placed in the start menu or on the desktop). They only open an explorer (Tracker) window to browse directories containing document files (docs, mp3, …). Of course, all the mp3 files share the same icon… In KDE, the icons of the document files show a preview of the contents but HVIF won’t help much since the icons are created dynamically.
It’s obvious that HVIF improves the loading time of an icon but does this have any measurable effect in daily usage? Has anybody thought about this question *before* coding the required routines? For example, by recording and analysing some typical user sessions? (slightly off topic. better to ask this in the Haiku forum)
(Sorry if this sounds too harsh. I’m a resource and performance planning specialist and usually paid to aks questions like this 🙂
Edited 2006-11-15 10:25
In Haiku, and in BeOS (+ classic MacOS before it, and others, I’m sure), every file and folder *can* be given a unique icon, thanks to the extended attributes of the filesystem (BFS, AKA BeFS).
This means that when a folder is opened in Tracker (the desktop/filemanager) *every* file and subfolder *must* be checked for an icon. (Not by opening every file or folder, though – the info is in the inode.)
*This* is the difference between classic Windows/Linux and BeOS/Haiku. Per-file icons are not that common in BeOS, however. Primarily applications and image thumbnails.
The kernel keeps a disk cache. If a file’s inode, which holds its filesystem entry metadata, is currently cached, and the icon fits in the inode’s small data area, which can hold some or all of the extended attributes of the file, then the icon is already in memory, and no further disk access is needed.
This is good for folders with lots of files/subfolders, and great for folders with lots of files or subfolders with unique icons.
Granted, if you discount the case of thumbnail icons for photo files, which don’t fit the new HVIF at all – in BeOS these are static, stored as icons instead of in a per-folder thumbnail.db – the most common case for a unique, static icon is that of applications, most commonly accessed through the Be/Haiku menu, and most likely already cached. So I’m not sure the performance gain will be huge, but it probably helps overall performance.
Photo thumbnails could still be stored as extended attributes, a set of them if necessary, at resolution presets. These attributes would stay with a file if you move it around. (Unlike the solutions of some other OS and applications.)
In closing, extended attributes are great when used wisely. BeOS and Haiku are tied to B(e)FS. To understand the design choices in this area: icons in Haiku, you have to understand BeOS/Haiku, it’s API, the internals of Tracker and the implementation of the Be Filesystem. If you still disagree with the design decisions, join the project and tell them why.
Edited 2006-11-15 15:00
Wow! Forgot all about thumbnails of photo’s! Having experienced how horrible the thumbnailer worked in Zeta 1.1 I’m keeping my fingers tightly crossed that it will be adressed in Haiku as well!
Why? Test it! Try opening a folder with lot’s of files, I do it every time I want to browse my music collection. Try it on Zeta and on Haiku. I stopped using Zeta because it was so slow f-that and yes it uses SVG
windows uses an icon cache to speed up icon drawing: iconcache.db
not that it always works that great, though. but the icons that are used most often will be cached.
scalable (vector) and fast icons would be a big improvement, so i applaud this development.
Haiku is about choice. The new icons don’t prevent the usage of SVG or Bitmap Icons. They are a 3rd option. And a good one at that. They will help increase Tracker performance.
My take on the decisions take by the Haiku Team: Haiku is on its way to take over the world. 🙂
I couldn’t resist adding a comment… seeing it is my baby. 🙂
1) There is a lot of unnecessary repeating of the inode stuff.
2) Some arguments are based on the assumption that HVIF is simple and basic. Where did that come from? What makes you think that most SVG can not be expressed with HVIF and not the other way around? I’m just asking.
3) Converting from SVG is supported (although preliminary, but planned to be extended), why should you (as a user or designer even) care that icons are actually stored in a more suitable format on disk?
4) Some people don’t seem to mind the time it takes to post uninformed comments instead of actually reading the bloody articles! Sorry if that sounded harsh, I deserve being flamed for that… 🙂
Best regards,
-Stephan