So I set up the new computer and tried my WebGL demo only to discover that Chrome is deactivating my timer when I'm not actively moving the mouse around! I thought at first that it was rendering really slowly but no, same FPS rate, and the time is correct in Firefox or when giving it mouse input. Must be some sort of browser-based optimisation against time-wasting scripts. Looks like I'll need a better timer...glad I spotted that one.
[FIXED] Update: 8 June. On closer inspection... the borrowed timer code turned that I was using turned out to be just a simple wrapper around JS' Date() function. I suspected the accuracy wasn't very high; giving me values of 0 when it was running on a faster computer. I just wrote a little safety catch around the timer, so that it never restarts until it collects 10ms or more. Fixed.
The frame rate seems to cap at 60Hz, which is odd considering that it was rendering fast enough to give me 0 time between frames. Perhaps there is an internal limit somewhere.
I don't think that ES 2 shaders let you do texture sampling in vertex shaders, so I'm not sure that morph animation can use rgb textures as xyz delta position maps for key-frames. Perhaps I actually need to use a different state-storing mechanism. Best idea is to reverse engineer some examples and gather some ideas. Another one here.
I might hold off on animation code for the minute, because I just saw this tutorial, which is complemented with some excellent sliders for affecting the WebGL demos. One of the great irritations of 3D programming in general is the difficulty to get good real-time user input and output (GUIs and buttons). I mostly give up for desktop programmes (especially Direct3D which also lacks the linux-like console), and just use settings and log files. But - web controls! Suddenly I see the enormous potential of HTML5 + WebGL. I have already used HTML fields for debug output (FPS counters etc.), but perhaps it is time to master using them for input as well.