WebGL in Web Workers
blog.mozilla.org
blog.mozilla.org
In a browser environment (and other event driven platforms like iOS or Android) it is usually a bad idea to block the main thread (aka UI/browser/event thread) for more then a couple dozen milliseconds because the application would feel unresponsive. If the blocking goes on for seconds, the application will be terminated by the operating system or browser. For a game this means that the game 'cannot own the game loop' like on game consoles or Windows, instead all execution must happen in small per-frame-slices.
As a workaround it is a good idea to move the actual game loop into a thread, and keep the main/UI/browser thread free for UI/input event handling, and other stuff that needs to happen on the app's main thread (varies by platform, in the browser, calls to WebGL currently must happen on the main thread).
In emscripten this was difficult to implement because WebWorkers have a different threading model then traditional 'pthreads' (or may be it was always possible but no-one dared going there). Alon's work may show that it is feasable also in JS+WebGL to move the main loop into a worker thread (I haven't read the code yet whether the worker can actually run completely decoupled from the main thread).
Before Google Native Client was able to call GL from threads I implemented something similar (wrap all GL function calls and write them to a command buffer, and then on the main thread read the command buffer and issue the calls to GL). It worked but I wasn't very happy with it because: all GL calls which return a result would stall the producer thread, and GL is very chatty/verbose, lots of very small calls (e.g. glVertexAttribPointer, glUniform...), and each call now had some tiny additional overhead. In the end I wrote an engine-specific message protocol which was more abstract, thus reducing the number of commands drastically (by 10x or so). But the latency problem is still there (for instance in Chrome, all WebGL calls are encoded again into a command buffer, and decoded in another process), so in my current experimental/minimalistic 3D engine I'm back to not doing any threading at all (good for latency, bad for making use of available CPU resources).
However, it is still possible to post binary data to a worker and back again without making a copy of it, by using Transferable Objects [1].
You simply have to provide an array of the arraybuffers to move as the second paramter to postMessage(). The caveat is that the data is no longer available to the posting thread after the postMessage call (TypedArray length will be zero).
[1] http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
It's seriously like the web folks are discovering all of the sad mistakes we ran into in native graphics like a decade ago.
Threading in OpenGL is subgood--you have to be fairly clever (and lucky with drivers) to do anything useful.
Having a dedicated thread for rendering isn't bad, but using the (already likely overloaded) main event thread for a website instead of being able to spawn a dedicated WebGL thread is bad--being unable to easily handle image loading and shader compilation and whatnot is worse.
Also, WebGL could've finally fixed the broken shader compilation model on GL, but didn't--why do we still have to compile shaders every time?
As for the shader compilation, I guess there's just as many argument for as against a DirectX-style byte code model, and the situation in the GL world is more complicated because GPU vendors have more freedom (to introduce their own GLSL extensions for instance). GL implementations already do a lot of under-the-hood magic to hide the parsing and compilation overhead, like caching compiled shaders, deferring shader compilation, and compiling shaders in a separate thread (not necessarily WebGL implementations, but they're free to). I'm not saying this is perfect, or preferable over a byte code model, but it's not 'broken'.
The WebGL standard is supported in all major browsers, including Internet Explorer, Safari on iOS, and Chrome and Firefox on Android.
Only a few selected mobile devices are able to run WebGL. Those that do, have a tendency to drain the battery quite fast.
http://caniuse.com/webgl
I, and a few others, use it for leading edge instructional design. http://www.vizitsolutions.com/portfolio/gausslaw/
Most users stick to their system browsers.
Chrome still hides WebGL behind flags in devices that don't have any problem doing OpenGL ES 3.0.
> i0S 8 comes into the fold support will be pretty widespread.
In countries where the average income is above 400€.
WebGL is an implementation layer for creating your own content delivery system in the same way that OpenGL is for desktop apps. OpenGL's approach has worked in practice for over 20 years.
WebGL has done a good job of maintaining parity with iPads. As in, you can expect top-of-the-line iPad games to run at parity on decent PCs with decent WebGL implementations.