SVG the map! :)

The map is supposed to be easily integrated with the web, and SL is going to have a builtin firefox browser Real Soon Now, which supports SVG natively in version 1.5
SVG is an open standard, takes up less space than JPG, resizes a lot faster than downloading a bunch of new textures and can be scaled strictly on the client side.
You already have geometry data, a simple projection will make it 2D, and Vector -> Vector makes more sense to me than Vector -> Raster.

Seconded. And btw, "SVG on a prim" would make SO MUCH MORE SENSE than "HTML on a prim" (shaking head in despair at how "text on a prim" ever became "integrate mozilla inside the renderer".

Not too sure that this would work as expected. When you try representing something as detailed as the SL map (even at it's highest zoom level) there are too many discrete "blobs" (discrete contigous regions of a colour) for SVG to encode efficently. Once you hit a certain level of detail, SVG becomes larger than JPG quite rapidly.

Also, (strict) client-side scaling only works after you have already downloaded sufficiently-rich data - which is why even those GIS web services that do use SVG still need to continue sending additional data as you zoom in or pan. The SVG file(s) for the complete map at full zoom would be massive.

Agreed. The idea of dragging the Mozilla source tree into SL makes me feel ill, and HTML is not only overkill but it's badly suited to fixed-sized objects: unless you use absolute layers (which make a joke of the whole HTML layout model in the first place) getting objects positioned right is a nightmare.

So you'd rather they invented a custom solution .... sure start out as rich text with Linden specific tags, then people would want basic layout ... pretty quickly they find they're reinventing Gecko which is incredibly fast, scalable and flexible and once Cairo support lands will also be able to render directly to GL. I don't think anybody will be putting regular web pages on a prim except to play with, but HTML can be used for more than just web pages.

Yes to the first part, no to the second part.

Before you start looking into things like rich text, go back to basics and look at what's actually been done. Give us llPaintText(string text, string font, integer size, vector color, vector coords);, with coordinates in <x, y, face>. XYText without the overhead and gluing-prims-together pain and complexity.

But HTML is a really really expensive way to put a few chunks of fairly large text at fixed offsets on a prim... which is about all you can usefully do in an environment like Second Life.

If it turned out to be too detailed you could simply LOD it. It's not like LL is new at gradually streaming in objects
I wasn't talking about downloading the entire map for all sims at once, I just think it could be faster and more seamless to dump the blurry JPG textures that take forever to load in favor of SVG... plus, I could then parse and transform that SVG data

Mack, SVG wouldn't be a completely new solution. It's a concise and expressive standard that covers text and vector graphics, usually streamed compressed, that also accomodates morphing and animations. It's viewport oriented out of the box, contrary to whatever Mozilla renders (I don't dare call that HTML or anything recognizable ).

Several compact virtual machine renderers are alrady on the market and it is used in mobile phone graphic applications. It's supported by Adobe (Illustrator being the most sophisticated SVG editor out there) and even by Microsft (Visio has a very good SVG export - not sure it'll stay there once XAML arrives though ).