I undertook the project to learn about Processing.js, a browser-friendly javascript+canvas port of the popular Processing Java animation system. In theory, this should have been a pretty straightforward task, but as it was a completely new system for me (and it's only just been released itself) I bumped into a few problems.
Problems encountered in Processing.js
- There's probably some trick to debugging Processing.js scripts, but by default you are not informed of the presence or location of errors, syntax or otherwise.
- Processing.js runs in the browser, so you'd expect online samples to run fine from a local copy. However, some, such as background image, silently fail. To work around this I served them from a local web server.
- Operations on a large canvas, such as the 800x600 I required, were unbearably slow. I compensated by reducing the frame rate and reducing redraws. However, what I was animating was remarkably simple, so this slowness was unexpected.
- Related to the above comment, reading the colour of a single pixel using
myImage.get(a,b)in a large canvas was cpu-intensively, mind-numbingly slow, and triggered Firefox's Script Not Responding dialog. To get around this I copied the part of the canvas I needed to read to a much smaller offscreen pixel buffer, and read from that. - In reloading my chart numerous times whilst debugging I found that Firefox would take up more and more memory. Eventually I had to completely restart the browser. I'm not sure where the memory leak occurred, but I don't think I caused it!
My final view is that Processing.js is an interesting experiment, but that it's too slow and debugging is too hard for general development use. Even though I won't be rushing to use it again I look forward to improvements in browser canvas support which will no doubt make Processing.js more usable in the future.
Further curiosities
In my attempt to add an interactive element to my existing weather charts I wanted to make as little change to the weather chart code as possible. However, I needed the weather chart to pass information about temperate extremes and chart date to the Processing.js code. I achieved this through the use of steganography, by encoding that information as pixels within the chart itself. If you view the source of the interactive chart page then you can see where that data is decoded - see function DecodeImage().
To encode the date within the chart I needed to get JPGraph, the PHP charting library, to plot pixels. Although it doesn't allow you to do this directly you can get the handle to the GD image itself. From there it was a simple matter of using PHP's GD functions to plot the necessary pixels, and outputting the GD image. This doesn't fill JPGraph's cache, though, which is something I'm looking to rectify.
Final thoughts
For really simple image manipulation within the browser using the DOM may be fast, but it's not always easy. Using an API such as Processing.js promises to make such programming easier and more productive.
Updated 14-Feb-2009: Changed all links to point to main weather chart, because the interactive and standard versions have been merged.