[sldev] [VWR] What about Dillo

[Argent Stonecutter]

On 07-Nov-2007, at 00:14, Lawson English wrote:
> Could there be an LOD for SVG on a prim? Seems to me that if its a  
> hard-coded texture, a lot of the utility of SVG gets lost, but I  
> could see a need to limit the revectorization to only a few  
> possible distances. Certainly, you wouldnt' want close-up vectors  
> and text to be pixilated.

That's the kind of thing I was getting at in my message recently  
about the different approaches to rendering text onto a prim. If you  
already have a texture on the prim, you've presumably picked a  
texture with a resolution appropriate to the situation. Baking a new  
texture by compositing the SVG onto that texture, client side,  
completely avoids the issue of deciding how high a resolution to use.  
It's not a hard-coded texture, it's generated statically in the  
client and can be reloaded by a script, it can be cached in the  
client and only regenerated if the SVG changes, but it doesn't get  
downloaded as a high-resolution bitmap. It also opens up the  
possibility of having LSL-generated or LSL-modified sculpt textures  
and particles.

You might want to have another look at my SVG message with that in mind.

That's also why I don't think the shortcomings of Dillo really matter  
for this application. If it can be used to render high-quality  
antialiased text onto a surface it doesn't matter whether it even  
implements more than HTML 3.

What I'd really want would be llRenderText:

llRenderText(integer face, integer font, vector offset_size, vector  
color, string text);

or:

llSetPrimitiveParams([PARAM_RENDERED_TEXT, integer face, integer  
font, vector offset_size, vector color, string text]);

This would attach and download to the client a compact chunk of data  
that could be rendered using whatever's cheapest. It's high level,  
not tied to the client. The offset_size parameter would use x and y  
for locating the text, z for scaling. The font could be abstract  
(FONT_SAN_SERIF, FONT_SERIF, FONT_TYPEWRITER, ...) or specific  
(FONT_ARIAL_BOLD, FONT_COURIER, FONT_TIMES_ROMAN, ...). Since the max  
texture size is 1024 the offset_size could fit in 30 bits, face in 4,  
font in 6, color in 24, packed format would be 64 bits overhead.

Going to SVG or HTML or anything specific like that would limit the  
implementation. The client could generate SVG or HTML from this if  
that's efficient, or use lower level OpenGL calls directly. That's an  
implementation detail.

Using open standards doesn't mean exposing them everywhere.

But going back to SVG or HTML, how much of the XML spam is really  
necessary for a valid SVG document? When you're generating something  
like this from LSL...

llRenderSVG(0, "<svg width=1m height=1m viewbox='0 0 256 256'><text  
x=2 y=10 font-family=Courier font-size=22 fill=black>Hello World</ 
text></svg>");

Adding all the doctype stuff would more than double the size, and LSL  
strings are limited length.

llRenderHTML(0, "<div style='font:22pt Courier;color:black;text- 
align:center'>Hello World</div>");

HTML is a more compact representation for text, and less specific  
data needs to be specified. Should the SVG viewbox be an actual  
section of the texture, or the width and height be absolute, or  
should they be mapped to the whole texture or prim face respectively,  
allowing you to generate SVG independent of the size of the prim or  
texture? Assuming mapping, you could implement llRenderText either  
way...

render_text_html(integer face, string font, float size, string color,  
string text)
{
   string html="<div style='font:"+(string)size+"pt "+font 
+";color:"+color+"text-align:center'>"+text+"</div>";
   llRenderHTML(face, html);
}

render_text_svg(integer face, string font, float size, string color,  
string text)
{
   string svg="<svg viewbox='0 0 256 256'><text x="+(string)(size/10) 
+" y="+(string)(size/4)+" font-family="+font+" font-size="+(string) 
size+" fill="+color+">"+text+"</text></svg>";
   llRenderSVG(face, svg);
}

Either would work, as you can see they're both pretty simple even in  
LSL, the client could take the text from an llRenderText call and  
chuck it on a prim the same way.