Not so far, though this means they can experiment with that.
Part of the challenge of rendering maps quickly is simplifying features, clipping and filtering the data. E.g. you might have a layer containing really high resolution national boundaries. Most tiles won't even contain any part of it, and those who do will either contain a small subsection or a vastly simplified version. If you were to try client side rendering based on that, you're potentially looking at gigabytes of data to transfer to the client.
What they're doing is essentially doing all the steps apart from the final rasterisation, and then storing that vector data on a per tile basis, so that they can process only the relevant vector data - whether to serve it up as is, or rasterise it.
One major advantage is that things like styles (line widths, colours) can be modified without having to re-render the entire map data set. Instead you just have to on-the-fly rasterise the already prepared tiles, which you can do without totally killing performance.
Confusing indeed. No, the vector tiles are "just" small extracts of global data that then get rendered to standard png files again. Vector means vector geodata here.
Vector performance is still abysmal in browsers (apparently there's no vector benchmark used by the press to pressure vendors) so it's no wonder maps are served as prerendered images.
Even Google Maps WebGL implementation that only uses vectors for the streets is laggy as hell.
Yes, would be great to see a live example of client rendered tiles.
I believe their ProtoBuffer approach sounds promising and their position in the mapping / OSM community is strong enough to get this to some kind of standard.
Have seen a few client vector-based approaches before. 2 of the better ones:
MapDroyd - was a product of OneStepAhead - now seemingly part of Cloudmade ( http://wiki.openstreetmap.org/wiki/MapDroyd - still in Google Play with screenshots etc search for MapDroyd )
