Text Prims? No, Text Textures

The media streaming technology in 1.6 looks very cool. It's a great trick too, swapping out a designated texture for a quicktime movie. And it gets me thinking about other possibilites...

Text display is way too hard in SL now. Gee, think people would ever want to read anything in SL? How about enabling a prim to render text as a texture on one or more of its faces?

llSetTextTexture(key textUID) - Designate a texture for text display on the prim containing the script. Use llSetTexture or the build tools to put that texture on one or more faces of the prim, orient, scale, etc.

llRenderText(string text) - Display plain text on the texture. This could use a set of defaults for things like font, size, page dimensions, etc. Clearly inadequate for anything but the most basic text display. Probably don't even want to bother with it.

llRenderMarkup(string markup) - Render XML markup on the texture. Style information included in the markup would specify font, size, page dimensions, colors, etc. Should support alpha for transparency.

llRenderMarkupStyled(string markup, key notecardUID) - Same as llRenderMarkup, but style data is fetched from a notecard. This allows style data to be cached in the client and reused without repeated downloads.

This is mostly off the top of my head and certainly not exactly right, but it does sketch out some (IMO) intruiging possibilities. We would probably also need calls to measure text to figure out where lines and pages break. Perhaps there should be some way to do tickers that are effectively infinitely long but scroll as a texture anim...

The XML-based rendering in the client would probably be the biggest chunk of code, but that's a fairly well beaten down problem now and there are even good open source solutions. The part where things get really vague for me is whether the calls should work for one texture on a prim, one texture on any prim, many textures on many prims, or what have you; I'm sure some Linden or LSL Elite can set me straight.

The cool thing about this, besides working at all, is that the bandwidth cost for sending the text/markup is way less than the rendered texture. Suddenly signage, scoreboards and other printed matter become cheap.

(Yes, I've been spending too much time thinking about how to respond to Hamlet's book challenge.)