HTML on a prim

For those who missed the announcement, we should be getting this HTML on a prim:

http://www.ubrowser.com/

any day now.

for 4 years

next

deletionnnnnnnnnnnnnn

They will get to this, they really will, you cynics.

They still have to work out a few bugs in the prims before they get the html thing going, though.

Whether this really means anything or not I don't know, but in Philip's SecondCast interview he said that this is supposed to be appearing in a preview in the next couple of weeks.

I guess we should check that in the pocast and the transcript to get the exact wording.

Well they did an open source request where they let residents and others who were interested try to fix it, and offered a free private SIM for a year. I can imagine we'll see it soon. Those open source guys are quick when they put their minds to it.

Maybe they'll give them a shot at Havok next.

And a few bugs in the clients.. bugs that have been in there as long as I've been playing the game. Soooo... does 'any day" now mean "not until 4 years have passed?"

cupple of weeks in linden time = 7 years

Fair call... It's just a little under half way through episode 11. I was off the mark a little with my first comment, and this is probably a bit out of context, but here ya go...

Oh, they got the transcript out now?

At the time I made my comment I was still joking about the lack of the transcript. And the podcast. And HTML on a prim. And llTeleportAgent

I tried to build something recently and when I copied by shift dragging ,the one that moves (the original, that most people would think is the copy) changed it's size. That is what ispired me to make the comment about needing to work out the bugs in the prims before applying HTML to them.

----- uhh, is that quote from a transcript of the townhall or is that from months ago?

Two laggy programs that go badly together: Second Life and Firefox. This will massively increase the minimum required hardware and reduce the frame rate even further.

HTML on a prim is a huge step backwards. LL needs to get an efficient text-on-a-prim-surface working, so we can use SL tools to efficiently create better content.

I have to respectfully disagree with you here Argent. If all that "html-on-a-prim" gave us was static text on a prim surface, I might be inclined to agree with you. But the ablity to have dynamic and interactive web pages within the world will provide countless new opportunties for content developers. I don't see any reason for LL to be reinventing the wheel here when there is an effective open-source engine avaliable. And I am not sure what you mean about FireFox being laggy ... I usually have several FireFox windows open when I am in world.

Efficient text on a prim would allow for a much more dynamic and interactive environment than HTML on a prim would, because it would be able to update faster at a lower cost in bandwidth and rendering time.

Imagine HTML on a prim in a mall. 20 stores in viewing range, each with four to six vendors, all using HTML-on-a-prim, reloading a web page every 30 seconds in attract mode. I don't care how good your computer is (and it's definitely better than mine if you can have multiple firefox windows all updating concurrently, as would be needed for HTML-on-a-prim running alongside SL without any lag) you're not going to be happy with the result.

Imagine efficient text on a prim in a mall. 100 prims updating text every 30 seconds. It'd be less overhead than a single XYtext scoreboard.

Argent, we mean 'normal conditions', not runtime killing malls. Granted. As a frequent fusker reader, I often have several windows loading ten megs of content each while running SL.

Of course, it's not very fast, but what browser would be?

I believe, but I am not entirely certain, that it was suggested that this feature might first be implemented in a manner similar to streaming media ... such that a single parcel would only support one web page. I may be entirely wrong about this though.

google ad's placed mwaha lol. mad hits

Mono should've been in SL since a year or so... It's still nowhere.
SpeedTree code was licensed (??) from their creators, to be included in the SL client 'real soon'. This was last spring.

When Lindens say 'any day now' they mean 'you can thank God if you happen to live that long a life to see it'.

Sorry, I was wrong about SpeedTree. It's only about 4 months late (so far

As a HUD developer, I agree. HTML on prim is pretty but we've been asking for text on prim since forever. They should give us hooks into libGD and let us do all that nifty stuff, it would be perfect. I honestly don't see inworld browsing as being nearly as useful. Certainly not useless, but I already have the ability to run Firefox in a flat pane... just outside of SL.

Surely it would not be impossible, given the ability to display HTML on a prim, to have an LSL function that would be something like llSetTexture2HtmlString( "<i>This is italic.</i>"'

From previous posts about this my understanding is that each user will see the HTML page that you've specified to display, but they'd each be able to interact with it independantly. So if you click a link on the page the person next to you would still see the first page if they didn't also click the link themselves. I wanted this sort of abilty you're hinting at to use it as a complex display (although I was imaging the page to be on some other server and I'd update it remotely), but from what I've heard I really don't think it's going to support this kind of thing very well... if at all.

The problem with the funtion you've suggested is that you'd still the all the resources for a complete browser to display that one basic string. That would miss the point of having a function purely to display basic text. The point being that a simple text display function should use very few resources if it's implemeted correctly.

I agree with Argent. Text-on-a-prim yes yes yes WHY IS IT NOT HERE ALREADY. Browser-on-a-prim no, not until we're all running multi-terahertz machines with gigabit bandwidth, or until it's way more efficient than I can imagine it being. (Dillo-on-a-prim might be okay, or Lynx-on-a-prim.)

Why yes, you could do that.

You could also buy a new car every week when it runs out of gas.

llSetTextureText(params):

1. Compress the parameters to internal format - 10-20 mathematical operations.
   
2. Compare with the current prim parameters - 1 string comparison.
   
3. Send an update to the client - 1 UDP packet, 15-20 bytes.
   
4. Replace the current prim parameters - 1 copy.
   
5. Client creates an alpha texture containing the text - 1 render string call.
   
6. If the texture has changed, client requests a copy of the texture.
   
7. Client bakes the combined texture and stores it in its cache - 1 BitBlt operation and 1 disk write.
   
8. Client transfers baked texture to graphics card - 1 copy over the AGP bus.
   
9. Next time the prim comes into view, client fetches the baked texture from the cache.
   

llSetTexture2HtmlString(params):

1. Create an "sl:://UUID-of-texture.jpg" URL containing the texture for the client to fetch.
   
2. Create a mini web page combining the HTML string and the texture as separate layers.
   
3. Transmit this web page to the client. It's using layers, so it's at least a couple hundred bytes.
   
4. Store the web page in the prim's properties. Another couple of hundred bytes for that prim.
   
5. Client runs the Firefox renderer, "gecko", passing it the web page. This takes anything from half a second to a minute, depending on whether the client's rendered something using gecko recently. It also requires at least a couple of hundred megabytes of virtual memory.
   
6. Gecko requests the texture from the client.
   
7. Gecko renders the web page.
   
8. Client converts the web page to a texture.
   
9. Client transfers the texture to the video card.
   
10. Next time the prim comes into view, since the client doesn't understand HTML directly, it calls Gecko again to re-render the web page because it doesn't know whether it's static or not.
    

We're talking about something like a million times as much code being executed to generate the same result. Speaking relatively, abandoning your car when it runs out of gas is more efficient.