Written by Antti Lankila in likeness of an old Amiga demo whose name I've long since forgotten. Requires Firefox, Opera or Safari, as it uses the new <canvas> element. (Google has written IE compatiblity layer, but the glue layer would have a huge impact for performance.)
What you are observing is a representation of a potential field made by two "navels", that is points. The potential field is formed around the distance function (sqrt(x² + y²)) to each center, producing two fields. This naturally produces a field which has circular symmetry around both navels and grows linearly with distance. This wouldn't look very interesting, but new fields can be formed through linear combinations of these two fields.
The first combined field is simply the summed distance to both navels. It has a constant value for all points on the line that connects the two navels, and begins to increase gradually as you move away from the line. The shapes formed are ellipses.
The second combined field is the difference field, calculated by substracting the potentials of the two fields. It changes most on the line between the two navels. Outside the line, it has fixed value along those curves where the distance to both navels grows at the same rate. These curves intersect the curves made by the first field perpendicularly, forming hyperbolas
To calculate the picture, the two fields are moduloed by 256, making the rate of change in both apparent. To eliminate discontinuity at the 255 to 0 transition, the part between 128 .. 255 is inverted so that the values from a colour bar, from 0 to 127 and back to 0 again. The fields are then summed, forming a single value in the 0 .. 255 range for each pixel.
The colour is chosen by observing the highest bit above the modulo on both fields and xoring them together.
The code is rather optimized by this point, and the above steps are difficult to decipher from the final routine.
Opera, IE, Safari: add support for the getImageData / putImageData methods. Future for JavaScript involves ever faster JIT-style execution engines and (hopefully) optional strong typing. The canvas tag is in best position for becoming the base for pixel-based effects like the one above.
"Pixels" can today be emulated with fillRect(), but it's slow as heck and is unlikely to scale. It is most likely that even one method call per pixel turns out to be too slow; yet I wouldn't mind having putPixel(x, y, color).
Color ought to be specified by true objects that are fast to handle internally. CSS color like 'rgb(12,23,34)' is a nice interface and should be supported, but for putPixel and like, a color object might be best for eliminating any string parsing on the hot path.