Warning: If you know nothing about Second Life or nothing about programming, parts of this will probably make no sense to you. If you don't know anything about either, the whole thing will probably be pretty confusing! I'll try to provide definitions for terms that may be unfamiliar if you don't play SL.
The drawing board, a screenshot* of which you can see to the right, is composed of a number of primitives — 93, to be precise (the maximum number in a linked set is 255 prims, or 31 prims for physical objects).
So, here is a rough breakdown of how the whole thing works.
The image is 8×8, so there are 64 pixels. Each of these 64 pixels contains a script that does two things: changes color on touch and listens for messages from other members of the linked set. There are three kinds of messages pixels listen for: set next color, return current color, and clear (set color to white).
When one of the color palette colors is touched, it sends a "set next color" message to the rest of the object. The pixels listen for these and set their next color accordingly, and change to the next color when touched. The RGB arrows work in basically the same way, incrementing or decrementing the red, green or blue component of the color by a small amount.
This simply says a few instructions to the user on the chat channel.
When touched, it tells the other objects in the linked set to clear. Only pixels listen for this, so only pixels actually react to it.
The submit button, when touched, sends link messages to each of the pixels in order, requesting their colors. LSL is entirely asynchronous, however, so it is not possible to query the pixels and get their response in one step. The message is sent to each pixel, and then the each of the pixels sends another link message back, each of which is handled separately by the submit button. Each pixel knows its position in the image and transmits this in the link message, as well as the color. The submit button places the color from each pixel in a list. The submit button keeps track of how many pixels have responded, and once all 64 have responded, it generates a plain-format PPM and emails it to me, where it is handled by a special script invoked from procmail that processes the email and generates the image from it.
Like the simstats backend script, it was written in Ruby. The email is piped directly from procmail into the image-generating script. It's parsed using TMail. LSL scripts can't send attachments, so the image data is simply dropped straight into the body. The four lines that llEmail() adds to the top of the message body are stripped off, then the image data is written to a temporary file† and parsed by RMagick, scaled up to 64×64 and written to a PNG in ~/public_html/phatbits. The index page is a PHP script that reads the directory listing and embeds an img tag for each phatBits image.
In conclusion, this would be a lot easier if LSL had more features, such as the ability to query another object's properties directly‡, and if it were capable of doing things synchronously. Of course, if it had been easier, I probably wouldn't have done it. Funny how that works.
* The screenshot is slightly out of date — I've since added textures to the help (white), clear (red) and submit (green) buttons, and I intend to add some more buttons later, but I'm probably not going to bother to update the screenshot!
† Yeah, I know, version 1.9.0 of RMagick has a read_inline method in the Image class that would obviate the temporary file step, but Debian, ever on the leading edge, only has version 1.6.0 and I'm too lazy to build it from source.
‡ Adam Zaius suggested llGetLinkColor, but unfortunately, such a thing does not exist. Alas.
This document validates as XHTML 1.0 Transitional.