I’m going to try and keep this update short so that I actually finish editing it and it can be published. I’ve also been inspired by David Humphrey’s recent posts about his work to expose <audio> data in Firefox (and his efforts to get his students contributing to open source projects. and his baking.); as long as I’m thinking these things to myself, I might as well write them down. All benchmark times listed below are on my old 2 GHz Core Duo and should be treated as only coarsely measured.
Interestingly, drawing the scene to a Canvas in Chrome takes just as long as a physics simulation step (math in V8 is fast). If the UI hangs and the Canvas object doesn’t update, you just lose a frame of animation. The problem comes when simulation steps are delayed; this causes the world to play out in slow motion as a shorter time period is simulated than actually passes. Meanwhile, in Firefox, long (40ms) calculation times cause the rest of the interface (including that of the browser) to feel sluggish. Finally, the culprit in all of this is a script that never touches the DOM or the Window, except to update a small set of object positions. This all adds up to a perfect use case for Worker scripts.
There are a few implementations using Workers or something like them in GWT, notably GALGWT, utilizing the WorkerPool in Google Gears, and the newly released Speed Tracer. I’ve adapted code from Speed Tracer and GWT’s default single-script linker to compile the gwtBox2d library to a Worker, using JSON to pass transformation data (per simulated body) back and forth. It runs just a touch slower in Chrome, but this is made up for by the fact that the interface and the simulation are now decoupled. However, even in the latest Firefox, 3.6b5, the old SpiderMonkey problems are showing up again! The calculation time per step quickly balloons to over 600ms. What really cements the fact that this is the same problem is that, when the Script panel of Firebug is enabled (thereby disabling tracing and JIT compilation in SpiderMonkey), calculation times drop to about 80ms, only twice the time of a step computed in the main thread. From this we can also deduce that a) pure math is fast, even in “interpreted” mode and b) the main-thread time of 40ms is probably “slow,” i.e. my code is already exiting traces like crazy anyway, it just isn’t exploding the tracer in the process.
You can see (almost) all the code over at the (otherwise threadbare) gwt-ns library on Google Code.