I opened this matrix multiplication benchmarks and my browser (Firefox 7.0.1) froze until the benchmarks finished (I opened the page in an old Asus EeePC 1000H).
I heard that web workers were invented to separate processing from displaying the web pages. Is it possible to make use of the Web Workers API to make WebGL not stall the whole web browser ?
For the sake of clarity: the benchmark that you linked to does not use WebGL at all. (I should know, I wrote it.) And in the case of that particular benchmark you absolutely could run it in a Web Worker now and it would be perfectly fine.
(Fun fact - Web Workers didn't support TypedArrays when the benchmark was built, and since most of the matrix libraries rely on that it was impractical to run it in a Worker at that time. That has since been fixed.)
Anyway, to answer your original question: No, WebGL cannot run in a worker. The core blocker to this is that in order to get a WebGL context you need to call
getContext on a canvas element. Web Workers explicitly disallow DOM access (which is a good thing, BTW!) and as such you'll never be able to access WebGL from a worker.
But that's not as bad as you might think. For one, consider that most all 3D rendering is actually happening in a different thread anyway. Specifically, a whole bunch of threads running on your GPU. The only part the browser has in it is to tell your graphics driver "Hey! Start rendering some triangles using this data!" and then it moves on without waiting for the triangles to actually be rendered. As such, while the draw commands must be executed from the main process, the time it spends blocking that process is (usually) very little.
Of course, that's not what's going to eat up a bunch of your time if you were coding a realtime game. You've got animations, physics, AI, collision detection, pathfinding... there's a lot of non-graphical tasks involved that will eat your CPU alive if you let them. In some case (animation), it's usually just gobs and gobs of matrix math, just like the benchmark you linked to! Fortunately for us, however, that type of processing CAN be done in a Worker, and all we need to communicate back to the main thread is the data required to render the scene.
Yes, this introduces some challenges in terms of synchronization and data transfer, but on the whole it will be vastly preferable to locking up your browser while we try and simulate those 500 boxes colliding.