Pgup, Pgdn to control. No sweat - it took 30mins to get this running from scratch.
Yesterday, I had a play with the intro code on http://learningwebgl.com/. I made this: (click image to run).
Pgup/pgdn turns out to be not the best keys to use in a browser for interacting with the thing. Some things were surprising:
Firstly, loading meshes and texture data looks like it could be problematic and/or slow. Many mesh-loader demos don't work properly. Most wrappers seem to load Wavefront (.obj format) data but then convert it to JSON using a Python script before reading into Javascript.
Secondly, I doubt that Javascript, which is interpreted, can handle any real simulation processing. Perhaps threads are feasible. In this case, it might be necessary to use WebGL as a client-side rendering service only (which is okay), but still use a server-based or locally compiled simulation for doing any grunt work. There is still the problem of sending large chunks of texture and geometry data to the client and/or updating the data regularly, so there is a new bus/pipe that could be a weak link in a real-time rendering chain. This might even be an ideal arrangement for large scientific or medical simulation; terminals with a GPU connected to a big processing farm, but is it reasonable to do this for games and entertainment? Certainly, it would be great for platform-independence of software. This Quake 3 demo works (and fast), but nothing happens on the CPU - it's just a level viewer really. But then this is good: http://playwebgl.com/games/quake-2-webgl/.
Thirdly, I don't know how debugging and profiling will work with Javascript. I have been profiling my C OpenGL programmes and discovered that a huge amount of time is sucked up when uniform variables are frequently sent to the GPU. I've redesigned my programmes to only send uniform updates when a value has actually changed. All the WebGL samples that I've seen so far have got this completely backwards. This could be because it's still web-developer hobbyists making most of the demos, or because not a lot of processing is done in Javascript compared to their shader programmes, but I suspect it might be that the profiling tools aren't great or just aren't as readily accessible as people prefer to code JS in a text editor. Will try.
Some of the recent criticisms of the most popular WebGL wrappers is that they either don't have a proper shader class, or that you are forced to use the same set of per-vertex attributes for every renderable - more like the last decade's computer graphics. So it looks like a good start will be: