Support for rendering in a separate thread (OffscreenCanvas API)

[Hellenic]

Feature request

Support for OffscreenCanvas API.

Sometimes the render can take a long time and it seems to lock up the main JS thread, causing rest of the UI to become slow or unresponsive. I haven't tested this out yet, but reading about the issue and looking at the Offscreen canvas spec, it seems like moving the rendering to another thread with service worker might help to solve that issue.

gl-react is easy to use, and it would be great addition if the library would easily allow switching to use OffscreenCanvas instead of 'normal' canvas. Of course, given that OffscreenCanvas API is still very new and experimental, it shouldn't affect the normal use.

Expected behavior

Rendering heavy shaders should not slow down the main thread (e.g.. other UI components).

Actual behavior

Repeatedly re-rendering heavy shaders will cause other UI components to slow down.

Steps to reproduce the behavior

Have a heavy shader, and an input slider from which the value is passed down to the shader. Continuously moving the slider will cause shader to re-render but the slider too will become slow.

Came across this while working on a side-project of mine. Can be re-produced there.

1. See http://fractalys.is/
2. Adjust any of the sliders (e.g. bailout)
3. You will see the rendered output changing but also notice that the slider gets laggy

[Hellenic]

This probably could easily rise other issues, e.g. when the value is changed quickly, the renderer cannot keep up, and is showing an old render that matches value from few cycles ago.

[gre]

this is a neat idea, the only technical difficulty I see is that, if this needs to run in a webworker, how will we access to the data and draw from this webworker. I feel it needs an important refactoring of how things get drawn (currently the draw are attached to the React element ref instances, e.g. a draw method in a Node and Surface that directly access & reads the React props)