By the looks of it, SVG seems like the 2D doppleganger of COLLADA:

-They both have XML-based DOMs

-They're both quite complex interim formats

-Both seem to be open formats aimed for wider support application support than other formats of their kind

How suitable is SVG for animation? I've read that it's mainly for static images, but then I've also seen information that could be for animation manipulation for SVG 1.1, but I'm not quite sure. I'm on a vendetta for finding an open, vector-based solution for generating computer graphics for 2D games since rasterized graphics, although have their advantages over vector graphics, are just too memory-instense for my purposes.

I tested the nVidida extension demos some months ago. Even on my rather modest 650Ti it's super fast, drawing and transforming SVG images such as "the tiger" as if they were textures. With transparency and all, freely scalable, and antialiased. Super awesome.

The only thing that sucks about it is that it's not supported on any other vendor, and nVidia actually added way too much, so it likely will not ever make it into ARB or even core.

The extension supports not only rendering SVG paths, but also outline text, and some PostScript-like custom format, and it's directly programmable via a special API, too.

It would be cool if they'd just scratch 90% of that and keep SVG path rendering (or alternatively the custom format, which you can trivially generate from SVG), and it was made a core feature. But as it is, it's pretty useless, since you must implement your own SVG drawing anyway to account for other vendors. And since you have to do that, you don't need the extension.

I don't think SVG is very good for anything realtime. It seems to be designed more with the artist in mind, then with performance or ease of implementation.

It also seems to try to be one of those über-formats that tries to support everything and then some.

That usually leads to specification monsters, and pretty much no implementations that support it to 100%.

If you don't have to write the renderer for it yourself, I think it might be useful as a storage format though, specially if you want to support many different screen sizes without the distributable grow too big.

Then I think SVG could be useful, but you wouldn't draw it in realtime, just render up the graphics to bitmaps in the resolution you want, and use the bitmaps.

If you want to animate some paths, lines etc, its probably a lot easier to just implement drawing some paths and lines, and make an engine tailor made for this, and ignore the full SVG specification.

Then I think SVG could be useful, but you wouldn't draw it in realtime, just render up the graphics to bitmaps in the resolution you want, and use the bitmaps.

But then you'd loose one of the nice points of vector graphics, which is resolution independence.

Especially on Android, where you have to deal with some 320x240 low end screens up to 2560x1600, having your SVG rather triangulated than pixelated might be of an advantage.

Not so, you render your SVG to a bitmap when the program starts up, once, and in a suitable size. And then you use the cached bitmap, which will work well for the device's resolution, no matter what it is.

That way you have the best of two worlds: acceptable performance, and resolution independence. It isn't even a speed/memory tradeoff, since if you were to use bitmaps in the first place, you'd need the same memory to store these, too.

If you're interested in SVG, Mikko's NanoSVG is pretty handy.

An interesting alternative is to use a font if you already have font loading & rendering. You can make fonts from multiple SVG files using various tools, and then load then using and render them using whatever GUI or Font system you use, scaling to the appropriate size for your screen resolution.