Vector Vs. Raster: The Fool's Game

I'd point out that SVG is not designed to be terse - if it were, they wouldn't have started from XML.

The big point about SVG is that it compresses *really* well, especially in combination with, say, gzip - and every SVG viewer/editor I'm aware of knows how to handle .svgz files, which *are* very compact.

True enough -- compression with gzip certainly takes a majority of the size away, usually by about 50% or more, and comes pretty healthily close to the size of the binary format I described.

On a high level, this indeed makese sense, but there are instances where vector in any format would surely make a larger file. For instance a pattern of small circles/grid (like in the OSX trash can). The number of points describing each "hole" would far exceed the number of pixels they represent. How would this be solved through a purely vector rendering?

In theory, the idea of being able to hint a vector icon to perform differently at different sizes would be nice. However, the geometry of given letter in a font is much less complex than the geometry of a vector icon.

In effect you're still creating altered states of the same vector icon, and you could argue that you could spend your time either hinting the vectors or creating custom bitmap resources.

The reality is a one-size-fits-all vector image for typical usage within an application is a pipe dream.

In regards to your suggestion that you could get 10,000 points in to 100k file... well, I'll be a believer when I see it.

Stephen, you make the case that "rendering vector icons ain't slow." You point out that one can stuff a lot of vector nodes into the same space as a 512x512 raster file.

Let's chat about the CandyBar icon. How many vector nodes do you think it would take to describe it accurately? And how much more processor cycles would it take to render all those nodes, compared to the bitmap?

I know you (or I) can't answer those questions precisely, but would you agree that it would be a *lot* of vectors, and that the difference in processor cycles required would be at least an order of magnitude, even if the bitmap were scaled on the fly?

I use SVG in an even more compact way then svgz. Try my Adobe plug-in example sites or if you have a copy of the nightly build of Webkit try this link;

http://deerring.com/gfonts.svg

Enjoy!

Core Image & Core Animation show that vector art (and filters) can be very fast and very exciting. Imagine an icon format based on Core Animation! All pulsating and shiny and blurry in cool places.

This is where Apple should be heading :-)

Have you heard of the new icon format for Haiku (an open-source BeOS clone in progress)? It's a vector format designed specifically for icons.

General introduction: http://haiku-os.org/node/280

How it works: http://haiku-os.org/node/282

This example of typography that you cite is more interesting than you suspect, I think. After all, one of the more persistent complaints of type nuts is that the one-size-fits-all type scaling has destroyed a lot of the integrity of fine typography.

I'm not sure I buy it, but the default scale of font sizes that computers use was standardized exactly because fonts shouldn't be exactly the same at different sizes. It's often more than just minor differences, too: Fonts designed specially for print often have a display weight for large uses, with thinner lines, larger ascenders and descenders, and a smaller X-height. And extremely specialized fonts (for instance, fonts for newspaper body or agate copy) will be designed for use only between, say, 8-10 points, or 5-7 points.

It may be that designing one icon for all possible scaled sizes is as insensitive to the design as one letter shape for all optical sizes.

You said: "[H]e draws the conclusion that vectorized icons require more space. Unfortunately, on this point he is dead wrong."

Then you said: "That means that the actual vector data consumes roughly 394,974 bytes. That's still almost four times the size of the 103,102 byte PNG file"

Four times the size of the PNG = requires more space = not dead wrong

I loaded the PDF of the Candybar icon and immediately noticed both how slow it drew, and how inefficiently it was constructed. There were massive gradients that were almost completely obscured by objects on higher layers, like the the drop shadow. These areas could easily have been created more simply, omitting areas that were not visible in the final rendered image, which would have required much less memory. So the file size could have been even smaller than your analysis indicates.

sambeaus observation about core image icons is interesting. We already have similar icons, you can put a playing QuickTime movie in the dock and the icon plays continuously. There is much untapped goodness in the current icon system.

Hm. Vector image format, more compact than SVG?

Sounds like Encapsulated PostScript to me.

The only downside to EPS is that on Mac OS X, EPS support is implemented by converting to PDF, which is a *very* slow process (I don't know if this is by nature or if it simply has not received much optimization attention).

I'd like to see Apple add native support for EPS, as well as SVG and maybe even HVIF, to the ImageIO framework. And I'd like to see them extend Icon Services to support obtaining any icon size from such a file.

Peter, the other downside is that EPS does not support transparency information. True transparent drop shadows and blurs are not possible with EPS.

The Haiku project just adressed this by making their own custom vector format: haiku-os.org You might want to look at this, the sizes are incredibly small around 1KB or less. Max icon size 64x64

I don't see the point in caring about the small size icons. Even if you hand-position every pixel, as displays sizes grow and dot-pitches shrink, the detail will be lost on the user all the same.

The Haiku icons are a great, but good luck convincing Apple to convert all their icons to a simplified style. And I doubt you'll find any of those icons on any product packaging either. If you are developing for a major OS, then you pretty much have to have a complex icon.

Great comments, all.

Jordan, you're absolutely right that for very detailed work vectors can result in larger files. Each point takes up the equivalent of 8 rasterized pixels, so if the image is sufficiently small, the vector art would consume more than the rasterized art.

Josh, it's not difficult to produce a compressed SVG with 10,000 points that consumes around 100KB, and that's still bigger than what a specialized binary format would provide.

Splashman, the CandyBar icon isn't that much more complicated than the Firefox icon. The Firefox icon contains just under 500 points, plus perhaps 120 more for gradient targets. I'd say that 1000 points is probably a reasonable upper limit to the number of points that would be stored in an icon.

Rendering this amount of data really doesn't take very long, and as I said, the resulting raster image could be cached to make future drawing faster.

James, I couldn't get your SVG example to work -- I had problems getting my WebKit nightly to load its nightly version of the framework. Looking at the source, I see what you're doing -- a customized font that contains the artwork for each shape. Interesting approach! I do note that the font had to be encoded to fit into ASCII though, which expands its size.

Wes, I totally agree that a 'one size fits all' approach is foolish. It would take much longer to massage each point of an icon for a smaller image than it would take to manually retouch the raster version, and the result would still be inferior to a rasterized version. A hybrid approach would probably be best, with sizes above a certain point being rendered from the vectors.

Charles, it probably isn't worth it to cut out the parts that can't be seen -- it might actually add to the total number of points, and it might cause display issues when dealing with partial transparency. Plus, having all of the layers in there allows for more manipulation, either by an artist or by a developer -- imagine if the trial version of CandyBar slowly wrapped or unwrapped its icon to indicate how much time you had left in the trial!

Ultimately, any format is going to have positive and negative aspects to it, either with size, speed of rendering, quality, or ease of use. It all comes down to finding a balance of features that allows artists, developers, and users to all get things done.

The haiku icon format looks interesting; is it really limited to a maximum icon size of 64x64? That seems foolish to me in these recent days.

First, let me begin by saying that I've enjoyed reading all of these comments, even if some are a bit inflamatory -- I'm always open to constructive criticism :-)

I'd like to address all of the people who are saying, "Let's use something besides PDF!"

In the world I live in, that's not an option -- PDF is the only vector format supported by Mac OS X. Arguments in favor of SVG or specialized icon file formats are pie-in-the-sky wishes -- while you're at it, please wish for 3D holographic displays and 2400 DPI ePaper (I'd love a Mac with those technologies.)

I feel like I should address some of the comments about speed, as well.

I agree that rasterizing a vector is fast -- as long as it's simple. It's true that font outlines controlled by Bezier paths display quickly. But you must also realize that fonts don't have multiple colors, gradients, shadows, layers or any other kind of complexity. Comparing fonts to illustrations isn't fair.

Although I'm no expert with regard to the Mac OS X graphics rendering pipeline, all the information I've seen indicates that it's based on bitmaps, not vectors. There's a reason why you have Core Image and not Core Vector. If you think about it for more than 30 seconds, you'll realize that there would be a lot of branching if vectors made it into that pipeline (imagine a backing store containing a mixture of bitmaps and vectors and you'll start to cry.)

That's also the reason why the OS renders PDF graphics into bitmaps at the size it needs when you specify it as a part of your UI. Of course this bitmap is cached so you're not paying a penalty for its use, the hit will occur whenever it has to be sized to the display DPI. But don't count on that happening infrequently -- changing your display DPI may be as easy as holding down the control key and using your scroll wheel (similar to what's in Tiger today.)

As far as the size of vector icons is concerned, I'll be posting a follow-up tomorrow (11/17/2006).

-ch

IRIX has vector-icons. Seems to work flawlessly even on "old" hardware, by todays standards.

sgi have been there, done it and got the t-shirt, so it has been possible using vector-based icons for years on IRIX, why should it suddenly be not workable??

Craig, two things:

(1) But you can't use PDF for icons on OS X today, not application (Finder) icons. It is possible to design an efficient vector format with gaussian blur, et cetra. It is also possible for Adobe to add them to PDF. The CandyBar icon should not be that huge in vector form. You can certainly represent complex gradients as vectors. Adobe should add the support you need to the format if it isn't there today (I know that simple gradients are available in PDF and supported by the PDF rendering engine in OS X, don't know how complex the support currently might be).

(2) The rendering pipeline -- sort of. OpenGL is entirely based on vectors, and it underlies the window server. Window backing stores in OS X are usually bitmaps today; they're sent as textures mapped on top of vectors (to simplify the terminology). But when you enable Quartz 2D Extreme/QuartzGL, this changes. Data (line drawing, etc) is actually sent to the GPU as vector data.

Steve, the Haiku format doesn't even support for alpha. It is a colossal waste of time on somebody's part.

"Haiku format doesn't even support for alpha"

That is not correct. It does actually support alpha.

The implementation of the icon format in haiku is actually very clever. A lot of emphasis has been placed on making it small and fast. I'm interested in seeing it running and looking at how the icons actually render.

"You can certainly represent complex gradients as vectors"

Simply not true. There's so many things that vectors can't do. I'm not suggesting I'm an Illustrator guru, but I have been using it professionally since version 3. Some things are just not possible, or so incredibly complex that they're not easily achievable (plus, the results are a technical nightmare).

I don't think some of you realise the other issues associated with vector artwork when used like this. There's so many issues and so little benefit. I really don't see the need.

I've posted some other comments here:

http://islayer.com/blog/?p=87

What are you talking about? Is this a code for cursing or something I dont know about???????