Through the use of Web Workers, WebRender can run in a multi-threaded mode which can improve the performance in applications with complex pixel/fragment shaders. Web workers are not like traditional threads in C/C++, and their usefulness for 3D rendering is limited by this. There is no shared memory and therefore no semaphores, and all communication between threads is through a messaging system.
When running in multi-threaded mode, WebRender divides the canvas into horizontal strips, and each strip is passed to a thread. When rendering, each thread then only fills in it's horizontal strip and passes it back to the main thread where it is combined back into the full image. This implementation therefore requires all the vertex, texture, shader, pixel and depth buffer to be copied for each thread, which will use more memory.
When rendering with threads, all the function calls to WebRender are stored until getBuffer is called, then all the instructions are sent in a single message and the threads begin rendering. This is important to know in case you are doing some other calculations during your rendering process.
For simple scenes without much complexity in the pixel shader, multi-threading will actually slow down the rendering time, as the overhead of sending messages and combining the pixel buffer will outweigh the time saved by rendering strips concurrently. The sweet spot for when threads are useful and when they are not also differs per device, and WebRender does not provide an automated way to find this out.
Our testing has shown that across many devices that using two threads is on average the best number of threads for improving performance. On devices such as computers, which may allow for many more current threads, additional threads after two has only a marginal improvement. WebRender does support running in one thread, which allows the rendering to take place separate from your application, which can prevent the browser freezing if the rendering takes too long.
Threads are good for complex Pixel Shaders and bad for simple ones.
The potential usefulness of threads will be determined by the device your webpage is running on.
Running with one thread is a good way to seperate the rendering process out of the main page thread
On average, two threads is the best number
Function calls are all queued until getBuffer is called