Text on HUDs

This paragraph is a perfect summary of the whole reason we're having trouble communicating.

You are looking at a tool that can be used to solve a number of different problems, and want to just put that tool in the toolbox and have done with it. Once that tool is in the toolbox, the problem is solved for you. Even if actually using that tool to solve the problem is fairly complicated that's OK. It doesn't matter to you that if that tool is replaced with another one, some part of those dozen lines of code will have to be modified, so long as you can change the code to match the tool.

The problem with that approach is that a few years from now when they come up with OpenDirectPostscript, or whatever, you'll have to leave the Gecko engine in there because it turns out that several important scripts use AlignTextWithTableBorder and OpenDirectPostscript doesn't have a table object that allows AlignWithBorder, abd it's easier to leave it in than fix it.

And some years later you're doing things like checking the name of the program that's making a system call and returning a file descriptor in the error code field because someone mistook the error code for a file descriptor because the system call used to return error code 1 and it happened that file descriptor 1 was open when that error occurred.

That's a real example of something that Windows actually does, by the way.

The alternative approach, where you design a high level API and don't expose the way it;s implemented at all, so that the application doesn't know if it's calling ArgentRenderText to LindenRenderText and it doesn't care that font 1 is a true-type vector font in in the old implementation and an SVG font in the new one, so long as the letter forms are close enough.

1. We are talking about a performance difference on the order of a hundred thousand to one.
2. Scalability and security is on the side of a high level API like llrenderText as well:

OK, let's say that Lindel Labs comes up with a mechanism to specify the portions of a prim face can be rendered over... specifies a "live area" that rendering is restricted to. Then if you specified your text by crafting an HTML page or an SVG path, you would have to modify the HTML or SVG code to avoid the portions of the texture... because HTML and even more SVG is a position-precise mechanism. Since llRenderText doesn't specify that, the rendering engine is free to restrict the text without changing the API exposed to the application.

That is, llRenderText imposes fewer roadblocks in the implementation of a security mechanism than a more powerful and precise mechanism of specifying what is rendered.

The definition of llRenderText at no point specifies that the text is rasterized. Ever. The rasterization step that I described is an implementation technique for llRenderText, it is not exposed in the API or the definition of the process. If it turns out that deferring rasterization to the display frame time is the best mechanism, it can do that. If it turns out that rasterizing it early is faster or more secure, it can do that. The implementation of llRenderText can be changed without modifying any of the code that uses it. I have already pointed this out, so I have no idea why you keep bringing up "raster vs vector" over and over again, because it's not part of the definition of the call.

Go back to the beginning of the thread. The functionality that is being requested is the ability for a scripted HUD object to efficiently represent textual material to the user, under the control of the script.

That is not the title of the thread, but it is the topic of the thread. Being able to control the text from scripts is an absolute requirement.

Mono is an implementation technique for speeding up LSL. Any other capabilities of Mono are potential enhancements, but the primary goal of the Mono effort is to speed up the existing scripts in SL, all of which are in LSL. AFTER that goal is achieved, then things like allowing scripts in other languages will be addressed.

But more importantly, whether you write your script in LSL, SNOBOL, C#, or Polyforth, you are still faced with the same problem: the program that is rendering the text is not the program that is running the script. They're not even on the same computer. The text rendering is performed by the client, as a result of SL protocol messages that are passed to the client from the server as updates to the attributes of the prim.

The call that I'm talking about, llRenderText, does not execute on the server at all. neither does your HTML-on-a-prim or SVG textures. Whatever execution engine the code is using, once the call is made and the packet containing the update "this face of this prim has this information attached to it" leaves the sim, it's no longer relevant.

Whether this protocol change is implemented before or after the Mono transition the amount of work in the scripting side is exactly the same.

If that was adequate this conversation would not be taking place.

If it's low-level it's not an abstraction.

Besides some mistypes because of a headache I've had today, and the fact that I didn't have time to reread my message... I believe we have actually discussed many issues, clearly.



However, there is an assumption being made here that I don't quite follow. I have tried to peek and poke at your ideas to understand it more clearly. I believe we have discussed the depth of the implementation as needed. I have offered you to IM me, or you could use the mailist to discuss the implementation details more in greater depth than this thread.

The bottom line that I aim at is the use of open standards. W3C puts out many open standards. I would not say that they are the best and solve all problems. However, open standards published by W3C are widely agreed and debated greatly more so then by just us here, and that is what solves most major issues that we haven't even yet thought of yet.

A high-level API is best to take advantage of these open standards. However, we have LSL as it exists now and the issues of backwards and forward compatibility.



If we work with methods for abstraction (as you noted) and open standards, these problems, if they ever are really a problem, occur much more seldomly than with a more custom geared solution.



Magic controversy....? I hope not. I don't see how this relates. I can guess, but it is too vague for me to seriously debate it with you. Can you ellaborate, please?



Ok. That's Microsoft.



Perhaps, before you ellaborate, what I see here maybe is a comparison; that is a low-level API that Microsoft programmed being compared to high-level that we have discusses being one part already implemented and the other part theoritical.

We understand modern methods of abstraction and the past problems of BPIs.



My test of ubrowser was no where near that kind of slowness. It was actually much faster than expected. We don't have to use Gecko. We don't need all the features of NGLayout or HTML on a prim. We could settle just for a couple of optimized options based on a subset of open standards, and that would be acceptable.



There are absolute, relative, and percentage based values for positional content with SVG. Most of your concerns there are already addressed. The overall origin of the render may be moved about just like you specifiy a position in llRenderText(). However, that origin position is already implemented, as it is in the user interface on the edit prim texture dialog.



I believe this issue here, "raster vs vector" and its abstraction layer, has now been clearly discussed. There is no problem in communication here. However, our perception is obviously different, and that should not be a problem itself.



Blue does not say a script is mandatory to settle the feature request itself. As far as I am concerned, a basic "text on HUD" with all the features discussed here could be done with no new implementation within SL except for a script that uses XML-RPC that chats with an application that pops-up over your Second Life client.

However given the mode of the discussion, I also tried to inject some forward-looking thinking without any need of XML-RPC and where, as originally requested, it is all based on the face of a prim in the 3D view.

There are advantages to both designs.



We've proven it's optional.



The main goal is not speed. If speed was the main goal than LSL could be completely compiled instead of interpreted. LSO is made up of type based tokens after LSL is parsed. Further compilation is possible.

I am sure the gesture came along to completely compile LSL. Someone at LL must have had the bright idea to use CIL, an open standard, before LL rolled there own lower-level assembly and VM. With Mono available, they didn't have to roll there own VM. With CIL being an open-standard, they aren't stuck with Mono or their own custom lower-level LSO VM.

A fully compliant ECMA-CIL module provides verification of code, and that is steps towards security mesaures (not speed).

If interfaces will be exposed at a lower-level, these security steps are greatly needed. For now, LSL does not expose them at all.

CIL also gives the user the choice of there own higher program language. That is a step towards scalability.



I disagree it is a problem because it is possible if needed. Although, the priority here is practical solutions for modern technological capabilities.



If it is just text on a HUD, information that is really only seen by one client and not all, XML-RPC is a very practical solution right now.



With XML-RPC, no change in the internal code of SL is needed. You can have all the functionality of llRenderText() and much more far beyond that with your own developed application that runs along the side with the SL client. Just make it a pop-up that stays on top of the SL client. Walla...! "text on HUD"



Exactly. There will always be specific features out of general purpose implementations.

[/quote]If it's low-level it's not an abstraction.[/QUOTE]

I had a headache, but I surely didn't type "lowest-level," which at this time happens to be the theoretical quantum level. lol

I did mean to type "lower-level." I usually don't go much lower than the hardware abstraction layer - too many implementations to worry about.

Totally OT: With new virtualization techniques at the CPU-microcode level, Microsoft knows they're about the lose the big device driver rug underneath them... *ahem* the end of their magic carpet ride. Every step they have taken lately, even with the Novell deal and their "indirect" claims of patent infringements on Linux, is to control that hardware abstraction layer. It's obviously too many implementations for Microsoft to worry about, also. Next year, I plan to cut the head-off of Microsoft Windows and replace it with Linux. Hell, I already do that, but at a software level. In 2007, the hardware virtualization will formally hit the market at the desktop level. My Linux on Windows will transpose from a software method to a hardware level method. Excellent stuff...

Um, ladies, all we really need is more control over llSetText, ie the height it appears above prims (though that can be got around it would be easier to make buttons if you could lower it) and the ability for attachments to have more characters in their hover-text (ignored when rezzed in-world).

The problem that needs to be solved is that scripted objects can not display text efficiently and reliably. That is the bottom line.

What difference does it make whether llRenderText is implemented using the standard OpenGL interface, or with a shim going through SVG to OpenGL?

Technically "not performing an unnecessary intermediate step" is not "an open standard", but it's a good thing.

WE ARE NOT TALKING ABOUT A CHANGE TO LSL. WE ARE TALKING ABOUT A CHANGE TO THE CLIENT. LSL DOES NOT RUN ON THE CLIENT. The only "change to LSL" is adding a single entry point to the symbol table... and:

1. EVERY release of SL adds multiple such entries.
2. ANY solution to the problem will require adding at least one call to LSL.

How did you compare HTML on a prim with llRenderText, when llRenderText doesn't exist?

You didn't.

You can not figure out the overhead of uBrowser as compared to another mechanism to render text from a script by running uBrowser. The only way to do it is to compare the differences in the operations required for the two approaches.

llRenderText:

* Transmit the text string plus a dozen bytes of compressed data to the client.
* Depending on the implementation, the client either creates a 2d vector mask for the texture on that face of the prim, or creates a temporary texture using either vector or bitmap text. This can be done entirely in the GPU, no data other than the text needs to be transferred from the CPU to the GPU.

That's it.

Using HTML:

* The script creates a new document containing the modified text. This involves either creating a new asset (notecard, for example) or sending the string to a server outside LL and getting a URL back.
* The modified document, typically at least several hundred bytes, is downloaded to the client.
* A new instance of the HTML rendering engine is created. This is likely to take as much as a tenth of a second of CPU time even with a very good implementation.
* The HTML rendering engine creates a new bitmap in the CPU memory, typically half a megabyte of data.
* The HTML rendering engine parses and renders the document. If the background contains an image, that has to be downloaded. In the process of doing so, it performs the same rendering step as the direct approach.... but that step is now a tiny tiny part of the whole operation. And it does it in the CPU instead of the faster GPU.
* The bitmap is uploaded from the CPU to the GPU.

An overhead of several hundred thousand times in the latter case seems fairly conservative to me.

What are you talking about? Please site the comment you're referring to here, because it's all *about* scripting.

I'm sorry, but that's completely absurd. You're coming up with more and more insanely complicated mechanisms that will have to be independantly implemented for every separate application and every platform.

Look at what you're demanding people have to do! Let's say I'm writing a flight script, attached to a HUD, and I want to display air speed in that HUD. Currently, I call "llSetText()". For me, that works... but for other people with more complex user interfaces they need something more powerful... but not a *lot* more powerful. Other people want to use marquees on non-HUD objects in-world. These are all aspects of the same problem.

I'm suggesting they have the ability to render a simple text string on a prim surface. This can be implemented efficiently by LL in such a way that it is chaper and faster than creating a texture with fixed strings on it and sliding it around, which is the most efficient solution that people have come up with so far and which is still not efficient enough for display arbitrary text. XYText is an example of this, and it's unusable for things like flight scripts because it requires a prim for every 3-5 characters displayed, and border crossings force enough of these prims to reload to make it useless. A single-prim solution is needed.

Instead, you're suggesting that for someone to render a text string on a HUD they:

(1) Write a client-side application to "float" over the SL window for Windows, Mac OS X, and Linux.
(2) Come up with a completely separate mechanism for their customers who run SL full screen.
(3) Require their customers to download and install an application.
(4) Support these three versions of the application outside SL.

Do you really think this is reasonable? Sane?

We are all agreed on three things:
1. We are all agreed that text in SL is not available and that it is desparately needed.
2. We are concerned that the function developed is useable and efficient.
3. We want to make it easy for Linden to say yes.

I have read Argents arguments. To the best of my understanding they are:
1. We need a function that will be useful in the long term.
2. llRenderText heavy lifting will all be done on the client OpenGL graphics card.
3. The fonts for llRenderText can be standard fonts that are on the user's machine.
(Probably Arial, Times & Courier would be sufficient for now).
4. XHTML would be a higher order function that would still rely on the functions
of llRenderText to actually render it's text.

It seems to me that SVG as proposed by Dzonatas Sol is an entirely separate thread of discussion. I quote:

Since this has nothing to do with LSL or scripting it really belongs in a different thread. I opened this thread to talk about scripted text so that dynamic applications that can change text any which way they want can be implemented. So this thread is strictly about an LSL function. Please stick to it.

I also respectfully request that replies are kept short so we can read them. Please don't talk off topic. Ideas need to be evaluated on the strength of argument directly relevant to the topic on hand and not based on anything else.

Some comments before I reply later:

1. Implementation issues are not really part of this thread. Rather it be use of HTML, SVG, Argent's rasterization suggestion, and even the speed of it are all implementation issues.
   
2. However, anything is better than the speed of xyText().
   
3. Also, the ability to position text where ever is desired, but may cause a security risk.
   
4. Lindens Labs already has many of these implementations in place even if they are not exposed yet to LSL.
   
5. I'm not in support of HTML on a prim right now. I don't know why that keeps being brought up.
   
6. All "1000 to 1" and likewise performance values are hypothetical, as Argent pointed out that llRenderText() does not exist.
   
7. Not everybody speaks in a language supported by Unicode - people conform if they can. LSL is limited to Unicode.
   
8. Future support of llRenderText() may depercate it due to its design not being robust enough. That will cause issues for forward and backward compatibility. Solution: use a more general purpose, hence robust, design. Avoid the deprecation step and the unnesscary support.
   
9. I'm making suggestion and presenting ideas. I don't mind long detailed debates, as its been my job. If you can't convince me of your ideas with just the facts and suggestions, there is a problem. I hate seeing proposals pushed through because of "boiler room" style debates.
   
10. I do want text on a prim and also much more. There is no need have more LSL functions to do this. The LSL language, being flat as it is, has already started to become bloated. The more bloated it is the harder it will be to support forwards and backwards compatibility.
    
11. Because of these reasons, I'll continue to encourage people to vote no on llRenderText() or like functions that are not robust enough.
    

Argent, I can accept that you disagree and that you simply state that you disagree and why. However, you didn't just state you disagreed. You went beyond that. *sigh*

I don't understand this comment at all. The implementation may not be robust enough, but changing the implementation doesn't change the API.

The API might not be powerful enough, and it may need to be extended. The API might be too implementation specific and it may need to be replaced with a more general one. But there's nothing that can require a general API to be obsoleted because the implementation isn't robust.

Also, the use of Unicode in LSL has nothing to do with the implementation of llRenderText. Going back to my original example of printf, the original system this was implemented on didn't even support Latin-1. The layers beneath printf were extended to support Latin-1, then Unicode, and on many systems UTF-8 encoding of full 32-bit ISO 10646 internationalized text... transparently to the programmer and most of the layers between printf and the outside world. The reasons that this works is that character encoding is completely outside the scope of printf. Well, that's also true for the existing calls to transmit text from LSL. SL currently uses Unicode, but there's nothing in the exposed API in LSL that restricts it from transitioning from 16- to 32-bit character sets without changing the code.

If you can convince me that it's somehow "not robust" (whatever you mean by that) I'll be voting against it too. But arguing that it's not necessary... and then describing an incredibly complex mechanism to get a tiny fraction of the same capability by writing an external application that can only work with HUDs, that requires a minimum of three versions to be implemented, that requires ongoing maintainance, and can't be used full screen...?

I honestly don't see that as being anything but trolling. Well, I took your bait and called it absurd. Because it is. If you really weren't trying to hook me, then I simply can't imagine what else you thought that suggestion would do.

Individual parts of an API may become deprecated, which doesn't imply the implementation itself because the implementation may still be used with a successor interface.



Here, your suggestion is based on a text input being limited to a Unicoded parameter. Even if the internal message is UTF-8, the only supported input method of that parameter is Unicoded. This is an editor program limitation - not language.

A more robust interface would allow for a dynamic parameter. Just for demostration purposes only, here is some psuedo code to get a visual on it:

[phpcode]
define someFunction()
{}
[/phpcode]

Here the first parameter is more dynamic typed because it wants a precursorial type "Text". Here we assign "t" a derived type of "Text". Now "t" refers to a unicoded text object. llRenderText() would internally use an interface of "Text" to obtain the needed value.

LSL doesn't do this kind of object-orientation. The demonstration code could be automated by the parser, but that still would require a parser change and new compilation steps.

If the feature of such demonstrated code was possible, llRenderText() could support, by its first parameter, any kind of value that will properly structure into a derived type of "Text." You could then replace "Unicode.text()" with "Ascii.text()", or "UTF8.text()", or "UTF16.text()", or "EBCDIC.text(), or "TolkienElvish.text()", and so on.

Practical? Yes, it's been done. It's nothing new.

It is not currently practical within LSL, but it is within many other languages.



I just demonstrated how it is not robust enough.



Your description is mixed between a worst-case situation and an exaggeration.

But even when you put it that way....

In constrast, consider the total amount of scripts that exist in the entire SL world. Would a million be too small of a figure, you think? I heard there is over 3000 servers and an average of 2000 active scripts per server, so a million is at least way under the total amount of active scripts at any given time.

Any change to LSL will affect those million scripts. Any change to an external program will only affect those, as you state, three versions. That is a major difference in level of support.

Would you rather worry about the compatibility of a million scripts or the compatibility of one program with three versions? (given that three versions exist to actually make one program more compatible, anyways 1,000,000 to 1)

Finally, I don't agree it is as complex as you stated.




There is no hook. There is only a debate of ideas. A simple disagreement would have been sufficient here. However, you called my idea absurd and insane. Argent, why would anybody not be offended by such comment?

In general the opposite is the common case: changes to a general purpose (abstract) API come from changes in requirements... changes in features. Parts of an API that become deprecated become deprecated most often because they are dependant on or tied to a specific implementation. Onthe other hand, the implementation beneath an API is frequently changed, often radically.



No. I never suggested that text input be limited to Unicode.

All of that is outside the scope of llRenderText. That's all implementation. It doesn't have to be exposed to the programmer, anywhere.


Nope. You demonstrated how a *lower level* interface wouldn't be.

I'm not suggesting a change to LSL. You are.

This is never true with a dynamic compiler. LSL does not have a dynamic compiler. Radical changes can occur in a language with a dynamic compiler without a change to any API; however, similar changes in LSL force a change in API.

If your "common case" is supported by the use of popular languages, that is actually a popular problem. In fact, it is a popular problem with most strictly typed program languages. This fact is supported by the many instances where the design of an abstract interface uses less-than abstract parameter types.



Of course, not. However, this is one example where llRenderText() uses a less-than abstract parameter type.



In the demonstrative psuedo code, there is nothing of weight about implementation.

What I did was to demonstrate an abstract object called "Text" that could be used to make a parameter of llRenderText() more abstract; thus, it would become more robust.

The dependence on type "string" makes the interface of llRenderText() not robust. Type "string" is a general purpose dataype for a sequence of values from a predetermined set. Type "string" does not describe textual content; however, its set of values have usually supported a range of characters for textual content. Therefore, the textual content is limited to a predetermined set.

In order to expand the domain of textual content outside the range of the set supported by type string, one would have to either make a change to type string or to the interface of llRenderText(). A change to type string would affect every script in SL. A change to llRenderText() would affect every script that uses llRenderText().

To avoid this, don't use type string and use a more abstract parameter.

I wrote my first compiler in 1979, I wrote my first dynamically compiled language in 1983. You're not telling me anything I don't know. The problem isn't that I don't understand what you're talking about, the problem is that I do understand what you're talking about.

Dynamically typed languages (which is what you're referring to, and which I first had the opportunity to work with on a Xerox Dorado running Smalltalk in 1982) can be implemented with a bytecode compiler (Smalltalk), by compiling to machine code (Objective C), and it's even possible to have multiple implementations of a a dynamically typed language using completely different techniques (ECMAscript).

The API has nothing to do with how the language is implemented. An API is a contract between separate agencies. In this case, the contract would (like all the other prim attributes like llSetText, llParticleSystem, and so on) be between the SL client application and the server.

The term you are using, "abstract parameter type", is not related to the term I was using, "abstraction". Your "abstract interface" is not "abstraction", it's "indirection".

This call takes a "text string". If the implementation of the compiler (be it LSL, C#, or Ritchies original C compiler) permits Unicode or ISO10646 or only 7-bit US-ASCII is irrelevant. The implementation of llRenderText isn't even running in the same computer... so how the single new call in LSL (a single call, mind you, not a "modification of the language" is implemented is irrelevant. If C# requires the type of the string to be known, then the C# interface to llRenderText would need to specify it. The LSL interface doesn't. BOTH work, because it is a high level interface... the implementation (running in the client, remember) doesn't need to be exposed to the script.

There is no such dependence.

Since SL does not expose the encoding of the glyphs in type "string" within LSL, a change to type "string" would require no changes in any LSL program, because the type "string" is an "abstraction" (not a mis-named "abstract type" - there's no defined operation you can perform within an LSL program to determine whether a string is 7-bit USASCII, 8-bit ISO 8859.1, 16-bit Unicode, 32-bit ISO10646, and whether it's unencoded, encoded in 8-bit UTF-8, or 16-bit UCS-2. IF Linden Labs were to switch from Unicode to ISO10646 no existing LSL program would need to be recompiled, but all strings in newly compiled programs would permit additional glyphs.

That's because the string is an *abstraction*. Not a mislabelled indirect data type.

To avoid this, use an abstraction and don't get misled by jargon.

Abstract oriented design is very useful; however, the terminology that typically follows does tend to confuse people too much. I don't care to claim a published essay I wrote years ago for such reason. It's a popular concept, but it doesn't describe the structures well. It leaves people's perception too random. There are better concepts.



Your stated experience does nothing to help assert a perception over a concept. I don't know what 1979 has to do with "Text on Huds."

What I do know is your perception is different, and I accept that.



A dynamic compiler and a dynamically typed language is two totally different concepts. A dynamic compiler does not have a predefined language. A dynamically typed language is a predefined language. You gave me examples of dynamically typed languages.



An abstract parameter type refers to an object that is already abstract. An abstraction refers to the process to make an object abstract. An indirection is the process of an object to result in a reference to another object, which gets confused with redirection.

The string datatype is derived from a formal string in discrete math. It is commonly implemented in a general purpose form for a language to use. Given that it is a general purpose datatype, it has a system. The system of a formal string is also expressed mathematically, Σ.

What you seem to desire is the ability to call llRenderText() an abstract function. In math, an abstract function is easier to do since mathematical functions are abstract by definition. However, we know in computers it isn't that easy. In computer science we refer to an abstract function to mean its interface is abstract.

Not all interfaces are abstract. Before we call things an "indirection" or whatever, lets just simply state what makes an interface not abstract.

An interface exists between two or more systems. An interface is abstract when it is not specific to any system.

An abstract interface does not exist when you define a parameter of that interface with a system itself. Here, the use of the string datatype prevents any function to be noted as abstract. The string datatype defines that a specific system must exist for the interface to function correctly. Therefore, the interface is dependant on the string and it cannot become abstract. No abstraction is possible on the interface with a required string datatype.

Further, since the string carries a system, it is also known as a hidden implementation.

Here is the confusion.

Let's say an interface exists between two systems. For this interface to be completely abstract, the two systems are completely external from one another. However in the case where the string datatype exists in the interface, the two system are not completely external. They share the string system internally, so both systems are internal to each other. We could call this kind of interface between two or more internal systems an indirection, but we also have called it a subroutine.

What you have asked LL to do is to make another built-in subroutine.

Subroutines become complex to support over time as the entire program changes.

Could you suggest an abstraction of your llRenderText()?

Abstraction is not "a process to make an object abstract".

Abstraction is the process of deriving or defining an interface or set of interfaces that isolate the implementation of a process or system from the functionality exposed by the interfaces. Indirection is the process of deriving or defining an interface or a set of interfaces that expose the implementation details in a way that allows the functionality exposed by the interface to change without changing the interface itself.

The character set provided by the implementation of llRenderText is an implementation detail. The character set provided by the language that you are calling llRenderText from is an implementation detail. If you are calling llRenderText from LSL, then you will pass it a string in whatever character set LSL provides. If you are calling it from a language that allows for multiple string types, then the interface exposed to the language would need to support that, but that is not because llRenderText requires that information to be provided, it's because the language requires that information to be specified when defining or using a string. The type of string is not part of the abstraction.

The abstraction that I'm referring to does not require any specific string data type. The "string data type" does not exist in the interface. At no point in the description of llRenderText have I specified what the encoding of the string is.

Nope. The function call llRenderText is simply the interface to LSL for a very tiny part of the whole package. How it would be called from CIL might be completely different, and since the actual implementation is going to be in C or C++ on the client it's basically irrelevant.

What I have asked LL to do is to implement a mechanism to apply text to the face of a prim as if it were rendered onto a temporary texture on that face of the prim. The mechanism would involve attaching a compact list of parameters describing the text to the prim's data structure, so that when the prim is rendered the client can perform whatever operations are necessary to render that text to the prim. The part of it that is exposed as llRenderText() and runs in the simulator is nothing more than a shim that tajkes the provided parameters and marshalls them into the form that is stored in the database and transmitted to the client. Just like llSetText() and llParticleSystem().

I have suggested that since the number of parameters necessary is small, that the API exposed to LSL be similar to llSetText, which has a fixed set of parameters, rather than similar to llParticleSystem, where a list of parameters is provided. One reason for this is that the more complex the API the harder it is to keep the design abstract... a simple API reduces the opportunities for changes in the implementation to change the API.

Which is why I'm bemused that you're focussing on implementation details not exposed in the API (and that, for LSL, can not be exposed in the API) to question the "robustness" of the design.

I also like how it is stated on wikipedia: "In philosophical terminology, abstraction is the thought process wherein ideas are distanced from objects."



It's known as a hidden implementation. The simple use of the string datatype exposes implementation from Σ. The hidden implementation here is the character set provided. It is generally exposed by direct use of it.

It is possible to completely remove or to completely replace the character set provided by the hidden implementation of Σ. However here for now, we are limited to the inherit set of LSL.



Exactly. It is inherit from the program environment.



You just described a subroutine.



What you have asked LL to do is to implement this mechanism by a predefined prototype:

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



I already put my earlier proposals aside as requested. Now, I have *simply* tried to ask you for an abstraction of your prototype.

But only in the API exposed to LSL.

Only in such a broad sense that one could equally well say the same of an object method.

That's because I believe that for LSL that is the best compromise between exposing too much of the mechanism to LSL (and making it insufficiently abstract) and exposing too little (which is the problem with llSetText).

The API exposed to LSL is not the mechanism, it's simply an API exposed to LSL. The API exposed to other languages would not be restricted by the limitations of LSL. I can describe the API in terms of other languages or pseudolanguages, but since LL has not provided us with the bindings they're using for other APIs in CIL it would be completely premature to propose one.

Why don't you propose your suggested definition for all the mechanisms behind all the other LSL calls that interface to the same kind of mechanism that attaches a set of attributes to a prim for the client to use in rendering the prim, such as llSetText, llSetColor, llSetLinkColor, llParticleSystem, and so on?

I see this is not so simple. There are others that believe in principles when they program, also.

Given that there is the option for web on a prim, it is possible it is someone's belief to hold of until subsets of such capability is approved for mass use. Something like llRenderText() would seem like an interim solution except for the fact that once llRenderText() is installed that people will use it and it'll break content to replace it.

It is easy to create further abstraction of llRenderText(), but I asked if you could further make one from what you proposed so far. I put all my other proposals aside just to further progress with llRenderText() that you proposed, and the response I get is this:



*sigh*

I'm sorry I asked for your help.

HTML on a prim inherently has too much overhead to be used for the kinds of things people are talking about. According to Kelly Linden it's very likely that no more than one texture per parcel will be able to display HTML on its face, because of this very overhead. At the most a fairly small number will be allowed. Your belief that HTML on a prim can possibly serve the purposes of text rendering on a prim doesn't seem well grounded in reality.

Even for "text on a HUD"... even if a small number greater than 1 were allowed... that's no good. Your HUD would be likely to switch on and off as you passed from one parcel to another. For the kinds of things people are expecting from HTML-on-a-prim - like replacing XYtext in marquees and vendors, it's completely out of the question.

Then perhaps you could provide me suitable examples of the *kind* of thing you're talking about, for the existing calls. Because in the absence of that it's not meaningful to talk about 'creating an abstraction' for something that's already an abstraction. You seem to be asking for some specific pseudocode or the definition of an interface for some specific language other than LSL.

OK.

renderText:face:font:colorcale:

"renderText: attach text to the surface of a prim for rendering"

self hasFace: face ifFalse [ self error: 'Face out of range'].
font canRender: text ifFalse [ self error: ('Text can not be rendered in',font asString)].

" .. code to marshall the parameters and update the prim's database entry goes here .. "

There is an API to set and retrieve prim parameters that would be helpful, and it has fairly abstract method calls:

1. llSetPrimitiveParams( list rules )
   
2. list llGetPrimitiveParams(list params )
   

The implementation has been known to change over time, and some of the deprecated options have been phased out completely.

We could propose a new rule, like:

[ PRIM_UCSTEXTOVERLAY , integer face , string text , vector color , float alpha , vector offset , vector scale ]

Specific names are preferred by many, so the "UCSTEXTOVERLAY" describes a textual overlay that is in the Unicode Character Set. Fonts type are generally not independant to a platform, so I didn't include an option for the font type. However, I suppose we could propose that, also. We should allow for this one without the font option and then also propose other rules for some time later when web on prim is more publically available:

[ PRIM_OVERLAY , integer face , vector offset , vector scale , float alpha , list overlayrules ]

Here, "overlayrules" is an extension to decribe the content of the overlay. It could be UCS, XHTML, SVG, XML, or whatever else comes available.

A few examples to embed content:

[ OVERLAY_UCS , string text ]
[ OVERLAY_XHTML , string text ]
[ OVERLAY_SVG , string text ]

And an example to include content from outside the script:

[ OVERLAY_URI , string uri ]

Given that "overlayrules" here only has 2 parameters for each case so far, I'm not sure if it needs to be nested into another list as shown. It could be grouped in the PRIM_OVERLAY rule.

We need more feedback these things.

I believe that was in a discussion about parcel media and what could replace it.

From the the concerns posted already this is simple to solve for a single object. In the discussion noted above, it was suggest that the parcel media would be used. However, for media on a prim, it doesn't have to look at the parcel media entry. It could be a prim parameter. To solve the concern, simple make it so that if you rez it on the ground the media doesn't display; however, if it is rez'd on the HUD, the media displays.

That way, only the viewer is affected and not everybody.

Err. That's just an alternate interface to the same abstraction. There's many calls that have llSetPrimitiveParamsversions.

There is no difference in the "abstractness" of (for example)

llSetPos(vec);

and

llSetPrimitiveParams([PRIM_POSITION,vec]);

These two calls are semantically identical. If Linden Labs needed to change the meaning of PRIM_POSITION... say, to add a "wakalix" parameter, they would have to create a new PRIM_POSITION_AND_WAKALIX. The only cases where they have changed the elements of llSetPrimitiveParams they have created new types or sub-types to match. Semantically this is no different from creating a new call.

OK, friend, what say the call be changed from

llRenderText()

to:

llRenderUCSText

??? Is that all you're complaining about?

The problem is that this is now less abstract, because if (for some reason) Linden Labs upgraded LSL to support ISO10646 instead of UCS (since ISO10646 is a superset of Unicode), it will be able to leave every other call that uses text alone... but now people will have to remember whether they need to call llRenderUCSText (or PRIM_UCSTEXTOVERLAY) or the new calls that don't enforce UCS text.

I specifically specified that the font be described as a small integer rather than a name so that it would be an abstract specification of a font, such as FONT_SERIF, FONT_SAN_SERIF, FONT_FIXED_WIDTH, and so on. This makes the interface independant of the fonts available on the client that's displaying the prim.

Not possible, LSL doesn't support nested lists. This would however be possible using the "procedure-like" interface:

llRenderTextOverlay(string text, integer face, integer font, vector color, vector scale, list params);

The llSetPrimitiveParams interface, however, would be much more complex. It would be more practical to extend it this way:

llRenderText(text,face,font,color,scale); (or [PARAM_TEXT_OVERLAY,text,face,font,color,scale])

Plus, say,

llSetTextFont(integer font_id,string font_name); (or [PARAM_TEXT_FONT,font_id,font_name])

to permit specification of client-specific fonts IF that turns out desirable.

For HTML or SVG, it's not clear to me that this kind of API is appropriate for LSL. Your original comments on the desirability of specifying these simply as textures is fairly compelling... I wasn't objecting to that design, just suggesting that since it doesn't have any bearing on the original problem it's not realy relevant to this thread.



The performance overhead of HTML as a text rendering mechanism is the reason why HTML would have to be limited. I've since discussed this in IM with Kelly and he agrees that a lightweight mechanism is needed for the general case of rendering text. I also suggested to Kelly that HUD's be considered their own "parcel" for the specific case of this limitation, which would be a much better approach than having the overlay needlessly restricted to HUDs.

Alright. We have something we don't have to agree to disagree about. It's easier to meddle with llSetPrimParams() and later make a shortcut function if needed.

If you have noticed, all the options available through llSetPrimParams() is also available directly in the UI. What I suggested are options that also can be made available to the UI.



Except the syntax changes the meaning by type strictness. We need not worry about this when we can perfect the abstraction with llSetPrimParams().



OMG!

My programs never had a problem with the millennium bug or likewise. One thing I bugged my professors about is when they tried to teach there is a difference between arrays and ints. After several looks of them about to say something... and jiggling their hand at me like their about to say something... they decided to move on with the next bit to teach about.

LMAO. No. It is not a complaint. It is something that ought to be considered.



Something like that will work.



Doesn't matter. I considered your suggestions and revised the suggstions.



That is too much of a hack. Consider the UI and the complexity goes away.

One thing to remember is to group parameters at least in a style like 3rd normal form. The same gotchas that exist in database structures also exist in APIs.

Revised:

[ PRIM_OVERLAY , integer face , vector offset , vector scale , float alpha , boolean on ]

Notice this has no nested list "overlayrules" now. We have "on", instead, to set if the overlay mode is on or off no matter what kind of content is in the overlay. The UI for this can look very similar to the Texture tab in the Edit dialog; it could be an extra tab.

To display text like you want:

[ PRIM_OVERLAY_CONTENT , CONTENT_UCS , integer face , string text , integer fontstyle ]

To display a notecard on a prim (notecard must be in inventory and readable):

[ PRIM_OVERLAY_CONTENT , CONTENT_NOTECARD , integer face , string iventory_item ]

To display an embedded SVG image or HTML:

[ PRIM_OVERLAY_CONTENT , CONTENT_SVG , integer face , string svg_text ]

[ PRIM_OVERLAY_CONTENT , CONTENT_XHTML , integer face , string xhtml_text ]

To display content from a URI:

[ PRIM_OVERLAY_CONTENT , CONTENT_URI , integer face , string uri ]


Example call:

llSetPrimitiveParams( [
I'll allow you to propose shortcut functions to this but remember this allows you to set and retrieve values, so you would need two shortcut functions for every option stylized above. However, we'll get what we both desire.



We could extend this option if desired:

[ PRIM_OVERLAY_CONTENT , CONTENT_UCS , integer face , string text , integer fontstyle , string font ]

Where fontstyle could be the enums you selected plus FONT_LOCAL. If FONT_LOCAL is selected, than "font" describes a string the local client will parse.



Being able to provide the UI alternative will make it lightweight compared to the extra resouces needed used to run a LSL script that then calls these functions. (It could be like... no state.)



Indeed. However, why allow one parcel for the entire HUD which would get into the complexity of each HUD object controlling the same media resource. I'm pretty sure we'll eventually see the HUD in its own "sim".

I'm looking into help the verifier project of Mono... how about you? Well, I know you mentioned something about a full screen mode not allowing an overlay. I mean... "don' chaou wish your HUD overlay was a sim like mine. don' chaou.... don' chaou" hehe thier song was playing is in stuck in my head... anyways..

I don't see that it's easier to meddle with llSetPrimitiveParams than to add a function. The functions and the parameters to llSetPrimitiveParameters are in the same namespace. They're not separate entities, they're just different interfaces to the same code. The only difference is that the arguments to a parameter can not include a list, but the arguments to a function can.


That's orthogonal to the original point.

Actually, type strictness is a bigger problem with llSetPrimitiveParams. If you change a parameter from a "float" to a new "bigint" type, existing code using function calls will continue working because the compiler will coerce the type, but the code using lists will need to be rewritten.

A couple of years ago I found a C program I had written in 1981 in an online archive of source code. I took that program and compiled it, and it ran. The only bug it has was a timing one that was caused by the fact that no computers in 1981 were fast enough to make that kind of timing an issue.

If the program had to deal with the kinds of abstractions you want to expose in the API - things like word size and character set - it wouldn't have been able to work until I brought it up to date. But because all the interfaces it used were abstractions (in the broad sense of the term), those things were simply not an issue.

Your proposed API doesn't make sense to me. You don't need to create a new API or interface to map HTML or SVG 'textures' onto a prim surface, you simply allow notecards containing HTML or SVG to be specified as textures, either in the existing user interface or as names or asset keys in the existing API. That works because the abstraction "texture" covers all the cases except where the application needs to modify the content on the fly. Textures can be identified by keys or by text strings, and text strings can be names of objects in the prim's inventory, or URIs.

My proposal also uses the "texture" abstraction, the parameters are applied relative to the texture on that face, not the face's own coordinate system, so a new interface object - an "overlay" - isn't needed. Leaving that layer out has a lot of advantages:

1. It allows you to perform operations on the displayed material efficiently without rewriting it, using the existing texture calls.
2. It also means you could replace existing scrolling textures with SVG textures without change.
3. It means one fewer bundles of data to be associated with a prim, making prims smaller in storage and bandwidth.

I still object to tying the encoding of the text to the name of the parameter, for the same reason you objected to putting names of fonts in. This is an LSL interface to the API, and LS doesn't have a "UCS" type, it has a "string" type that happens to be implemented as UCS... but there is no reason to assume that it will continue to be implemented as UCS in the future. If LSL's native encoding changes you'll have to deprecate CONTENT_UCS, and if it doesn't you have no need for CONTENT_UCS.

Your other parameters also expose too much implementation. The name of a texture is an opaque string, and there's no reason to hardcode the type of the object referred to by that string into the API. If you leave it unspecified you can replace a bitmap texture with an SVG texture in a prim without having access to the source code of any scripts that reference that texture by name. This means that (for example) you could drop an SVG 'logo' texture into a no-mod plane that lets you display a bitmap texture on its wing, and your SVG texture would show up instead.

The UI issue is orthogonal, and in any case you're actually causing more UI problems by trying to combine a new texture type (SVG) with a completely unrelated API. Just allowing SVG notecards to be used as textures would automatically give you what you're looking for AND a whole lot more.

That's a mark of a good abstraction, by the way.

I don't care all that much about Mono. It doesn't address my needs very much at all.

After the initial read of your text, what I sense is that you prefer to force compliance by limitations in interfaces. Where the other method, which I prefer, is to detect proper data structures on input and output and error if incorrect.

The issue is our perspective, and you'll have to understand that difference. Until you do, I'm sure I'll continue to see assumptions made by you that are utterly wrong in my intention.

Here, it is obvious the system that I have suggested is more of a run-time and compile-time format where what you have suggested is limited to a compile-time format.

I do understand your points based on a compile-time only format. If a system uses what is only available at compile-time, it'll continue to work. However, just because LSL exists does not mean that SL will be limited structures in that compile-time format.



llxxxPrimitiveParams() is already implemented in LSL script, and the orthogonal features are also already implemented in the UI. The network protocol section that carries such data would only need to be expanded at worst. A entire new section would not need to be implemented.



"arguments to a parameter"... ...

Oh, like nested lists? Nested lists can be done; it is not easy to script. Because it is not obvious it doesn't matter. This is kind of like that arrays and ints comparison.



Not sure if you meant it in parallel or prependicular. Before I make an assumption, I'll just say it is silly to restrict such text on HUD features to only LSL script.



This is one hint about the compile-time only view. No such problem exists with run-time events unless the run-time doesn't implement any such detection. There is no need to only rely on compile-time limitations.



That was a common bug found with programmers that relied on jiffies for time events.

Here, I see the hint that you re-compiled it. That shows a reliance on compile-time features. One would ask if it could still even run without a re-compilation.

We can't demand that LSL scripts to re-compile because it would essentially lose its stack that is so heavily relied upon. It would break content to recompile them.

Before you assume that I'm trying to bait you, do compare it against a system that would not need a recompilation. As features change, the run-time would need to be able to handle the differences.

For example, in a dynamic compiler, the run-time is always available. There is no subsequent events like compile-time then run-time as popular languages involve. There is the run-time, and what was the compile-time has become a nested implementation within the run-time.



You haven't repeated to me, idea wise, what I wanted exposed in the API. I don't know where you got this idea. With run-time detection, none of that needs to be exposed like how you seem concerned.



SVG, HTML... same as the text (text on HUD) itself.

Ya, just display the notecard on a prim instead of on the HUD like it does now. Maybe that would be a good start.



An LSL script can't change the contents of a notecard, however.



It would be nice to have options available to allow everybody the ability to settle their needs, and that is not easy. Maybe if people cared a little more about how much time and work goes into design to give people that option they would understand how it feels to be treated and rudely called some "poor programmer" or likewise.

Programming is different from using real oil paints to paint a picture on a real life canvas. When the painter is done, you can see the work. Programming is like being blind. You can hear the painter work, but you don't see it -- or do you?

You could try a dictionary.
or·thog·o·nal (ôr-thŏg'ə-nəl)
adj.

1. Relating to or composed of right angles.