I was wondering why not use SVG (or any other vector file format) files and render all the graphic on the device, instead of including tons of PNG at various resolutions.
[1]: but if you know of one, I'd love to use it!
... except now you need to do it on the device too, to make sure it renders identically there. Otherwise the same problem!
---
For very small images it doesn't matter / png may be smaller, but small images with that quality don't typically add up to hundreds of megabytes.
The HTML Canvas will drive the needs, as well as other W3C specifications related to accessibility, internationalization, matching user preferences. You cannot do the same thing with "stupid" bitmap graphics. In fact the birmap graphics will be internally converted to vector graphics for better rendering (this is already what printer drivers are doing to improve their results, you cannot do that only by subsampling, bicubic interpolations: you need geometric transforms, notably for adapting texts or symbolic designs such as maps): the individual "pixels" in bitmaps are really stupid objects that do not properly handle how they are geometrically linked to their surrounding pixels: there's a need to contextually hide or show some details, or improve some of them, vector fonts for Opentype are perfect examples of that need.
But that still means it's years away from widespread support, because large companies can't rely on it for large user-bases, and feature-sets are still pretty widely varying in my experience. Some support animations, some complex gradients and masking, and huge variance in text rendering (which is absolutely essential to finely crafted images) cripples some of the most-valuable use-cases (internationalized images without making dozens or hundreds of near-duplicates).
It's just not there yet. I hope it gets there, but there are significant hurdles that don't seem to be getting a lot of attention.
OTOH, people do vector stuff for many things, it's just they typically don't use SVG but something more efficient. XML parsing is not lightweight compared to a binary format or some sort of vector -> code translator speed wise.
Bitmaps will also never be able to adapt their content gracefully to user preferences and constraints. Bitmaps have no intelligence; they are only suitable for photography, but even in this case they lack information for proper rendering, so you will nver same twice the same bitmap across devices and rendering supports
Just compare what we had in the past with bitmap fonts (now almost abandoned except for text consoles) and how we appreciate now to have scalable vector fonts.
Bitmaps are extremely complicate to adapt to any layout, whereas SVG graphics can be now self-adaptative, to render only what is needed.
Webkit does a fine job with SVGs. You could draw it on a <canvas> element to get a rasterized view of the SVG in the desired size, and save the resulting image.
AFAIK, the majority of designs are created in photoshop or illustrator. No conversion nessecary. In any case, I would consider it a liability if I didn't have my designs in an editable format. What if tommorow I realized I wanted a variant in a different color? Or I decided I wanted to use a different background? If all I had was a bitmap logo, I would consider it worthwhile to have someone change it into a scalable format anyways, even if I wanted to transfer them as PNGs.
Also, numerous free tool exist to convert bitmaps to SVG. Using one of these, plus some manual smoothing and correction, I'm sure the conversion would take no more than half an hour.
It gets even worse once you realize how limited older mobile GPUs are or what are the incompatible subsets of features supported at decent performance.
Resolution independent formats are inherently anti-triangle and by the time you've hit triangles you already have a target resolution in mind.
Or put another way, GPUs really don't like vector graphics in general. That's not what they're built for or good at.
Once you've subdivided your curves and such into triangles/vertices/etc., the GPU ends up being a lot happier about its existence.
Specifically vector graphics typically includes curves, which GPUs just don't do at all.
Once you've tessellated a curve into triangles you've already baked in a desired resolution. You can't have resolution independent vector graphics in a GPU friendly way.
eg png is fine, but if a developer wants to include svg then let them.
For developers who do care about the clean, unblurred stroked at arbitrary pixel sizes this wouldn't impact them at all.
For the developers who care more about the space taken up, this would give them a potential useful option.
Ironically IMO I'm pretty sure this used to be one of the major selling points of vector graphics and svg :-)
SVG graphics are clean, result in NO blur at all. They don't even need any Truetype-style hinting. You've probably looked only at early non-conforming implementations using bad approximations. But precise rendering algorithms for SVG are specified and fully tested (this is not the case for bitmaps whose support is much more problementic: see what happens to photos and videos when editing them! Never twice the same result, and lot of losses and artefacts everywhere, including bad undesired effects, and notably the moiré effects which are much worse and do not reproduce what natural scaling would do in your eyes, that are not fitted to a perfect rectangular grid).
So no, it's perfectly possible to create a vector image that results in unblurred strokes at arbitrary pixel sizes. What you want is a geometric transform to exhibit more some details: it is in fact impossible to do that with bitmaps except by sending variants tuned for multiple resolutions: you do that for a limited number of resolution and assume it is enough, but this is not the case, so you add more, and finally you have enormous images that are widely redundant with each other, and better represented by converting their 2D model to 3D and an adaptive 3D-to2D projection. you'll do that easily with vector graphics, not with bitmaps (or their extensions called "mipmaps" which are only approximations not really scalable because they're still all based on discretely sampled planes).
The classic easiest to explain in words case is taking a capital letter O and turning it into more of an "elongated stop sign" shape at around 6 pixels of width. There is a tradeoff between remaining faithful to the original shape and creating high-contrast, readable shapes at low resolution. There is nothing impossible about scaling down the vector outlines of a TrueType font in a mathematically perfect way. You still need the hints to make the result more readable.
(I worked on the hinting software for 13 of Apple's System 7 font faces and about 3/4 of Windows 3.1 launch fonts.)
This huge wall of text but apparently you don't understand the subject matter all that deeply. Why wouldn't SVG need hinting? Truetype needs hinting and it's a vector format as well.
Hinting as done in TrueType is probably overkill for most purposes. But icons are often not displayed in arbitrary sizes, but rather in one of a few known-in-advance sizes. It's not hard to tweak the paths and shapes to fit to the pixel grid for all those. Also, as you approach higher pixel densities, it becomes much less important; basically you may just have to make sure that the smallest sizes fit on whole pixels and that's it.
Long ago I've automated asset generation in different sizes from SVG for an Android app I worked on and even without caring (much¹) about a pixel grid the results were good enough not to need tweaking.
_______________
¹ When hand-writing SVGs I tend to care about integer coordinates simply to not lose my mind.
The catch is that Xcode compiles all those PDFs to PNGs before bundling them into the .ipa, so in the end you have a bitmap either way...
In any case, I suspect something like lyon (https://github.com/nical/lyon) would be a better fit than pathfinder, which is both a) not super portable and b) very focused on rendering text, which it does very well.
From discussions with iOS colleagues it seems that Android has seen a way stronger push for vector assets. Probably because from day one the OS and SDK has been designed for unknown displays at compile time.
In that sense, the only reason there would be more fragmentation in SVG support on Android than iOS is that it can be harder to upgrade Android devices that did not come from Google.
Vectors don't have pixels.
SVG files are vector based.