Now that I've begun to test the boundaries of the text variable belonging to all atoms, I find myself unnecessarily restricted.

The problem is that when the client receives a transmission from the server, it must download the entire string. For example, a blinking red and green light consists of:

text = "<font color=#FF0000 bgcolor=#336699>O<font color=#0000FF bgcolor=#336699>O"

...which is a *lot* of bytes.

What I would prefer is something like the following:

text = "OO"
text_color = "#FF0000,#0000FF"
text_bgcolor = "#336699"

That way, at least the number of bytes being sent to the client is being restricted.

(Under the proposed syntax, if the length of the colour doesn't match up with the length of the text, then one of two things occurs -- if the text is longer than the colours, then the final colour is used for the remainder of the text animation. If the colours are longer than the text, the colours afterward are ignored and the current colour is set to the first colour when the text animation loops over.


My main reason for suggesting this involves my "Matrix" concept demo (which, sadly, displays the "invalid" ASCII characters problem all too well), which can drag anyone's uploadwidth to a halt. This is because every tick, it must re-send a brand new giant text variable. All I would ordinarily have to change is the text_color and the text variables, thereby saving myself at least a couple dozen bytes at each transmission for each object, thereby exponentially reducing the bandwidth used (on a typical 11x11 screen, for example, there are 121 objects being updated simultaneously).

The Matrix demo is just a concept demo, but it's almost painful to see just how bandwidth-intensive it really is when such bandwidth just isn't necessary. After only a few minutes, the program ate fifteen megabytes of my uploadwidth.