
WebGL in Web Workers - devongovett
https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/
======
flohofwoe
Some more background info why this project might be an important proof of
concept, because it may allow to move a game's main loop into a web worker:

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).

------
leeoniya
what would also be nice is shared read-only Canvas, etc. available in Web
Workers so image processing (specifically analysis steps) can be paralellized
without copying the entire canvas (or parts of it) through message passing.

~~~
satori99
If you use Web Workers, you are going to have to use message passing. There is
no other way to communicate with a Worker. There are no truly shared objects
between js threads.

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...](http://updates.html5rocks.com/2011/12/Transferable-Objects-
Lightning-Fast)

~~~
leeoniya
i'm aware of transferable objects, but it really defeats the purpose of
parallelizing analysis of the same thing if that thing becomes unavailable to
read after transfer. it would be great to just tell a worker to read a
specific bounding box from an existing canvas without having to give up the
canvas entirely or copying the bounding box contents into it.

~~~
satori99
Yeah, that would be awesome. Probably not going to happen with actual DOM
objects anytime soon.

------
angersock
noooooo

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.

~~~
flohofwoe
This solution isn't talking to GL from different threads, instead it builds a
command list on one thread, for the 'render thread' (here: actually the main
thread) to consume. Only one thread creates and talks to the GL context.

~~~
angersock
Correct, which is exactly what's wrong with it.

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?

~~~
flohofwoe
I think whether this is good or bad actually depends on the WebGL
implementation. In Chrome for instance, the actual GL rendering already
happens in a separate process, and the main thread only writes to a command
buffer, which is already as cheap as it gets (but may increase latency).

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'.

------
CmonDev
This is quite lame.

------
lelifer
webgl webgl, webgl! webgl? webgl.

------
pjmlp
Does it achieve parity with native code?

~~~
flohofwoe
In general, WebGL can't be as efficient as a good native implementation
because it has to do more validation for security reasons. However, the
quality of OpenGL drivers differs so much in the real world across vendors and
operating systems, that the difference to WebGL is lost in the noise (e.g. a
WebGL app on Windows can be close to a native GL app on OSX, I'm not even
joking).

~~~
pjmlp
I know. It remains to be seen if WebGL won't join VRML in a few years.

~~~
double051
How do you see that happening?

The WebGL standard is supported in all major browsers, including Internet
Explorer, Safari on iOS, and Chrome and Firefox on Android.

~~~
pjmlp
And most stuff I see done with it reminds me of late 90's games, while driving
my fan full speed.

Only a few selected mobile devices are able to run WebGL. Those that do, have
a tendency to drain the battery quite fast.

~~~
AKluge
It's not so much a question of which device, but which browser. Chrome and
Firefox provide WebGL well for Android, and once i0S 8 comes into the fold
support will be pretty widespread.

    
    
       http://caniuse.com/webgl
    

WebGL is a presentation of OpenGL through the browser, so we leverage an
existing skill set with an existing API. This is dramatically different from
the case with VRML.

I, and a few others, use it for leading edge instructional design.
[http://www.vizitsolutions.com/portfolio/gausslaw/](http://www.vizitsolutions.com/portfolio/gausslaw/)

~~~
pjmlp
> Chrome and Firefox provide WebGL well for Android

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€.

