Multi-threaded, pipelined rendering architecture

[bryphe]

I've been researching / thinking a bit about how we could migrate to a multi-threaded, pipelined rendering solution.

In today's model, we do a lot of things synchronously that we could be doing in parallel:

• Reconciliation
• Layout
• OpenGL rendering

In particular, even though this would benefit primarily the native builds, I was thinking about this in the context of our JSOO playground. Currently, the compilation is time-consuming, and it's not a great experience to have to wait for it. We should delegate it to a web worker, but the challenge I had was then:

• How do I get the compiled 'render function' out from the top-level? Unfortunately, Marshal.to_string doesn't work on a function. I also tried an alternative of marshalling the React.syntheticElement that gets created from the render function - but this too had functional values.

Our current, non-pipelined world looks like this:

If, however, we could split out the 'reconciliation + layout' steps, and the 'OpenGL rendering' step, that would open us for a few cool things:

We could start processing the next frame while we are rendering the current frame - opening us up for a higher FPS. Note that I keep the reconcilation + layout together for those diagrams..., but perhaps those could be split apart as well. (Care has to be taken with the 'Node' hierarchy because the layout elements are mutable, but the initial processing / diff of updates could potentially be handled in a separate thread).

The 'draw' tends to be a bottleneck, and by splitting that out to be handling in a separate thread, it could potentially be a big win. This could be facilitated by the Nodes themselves not actually making OpenGL API calls - but an immutable description of the scene. This would also enable us to serialize these calls from a web worker, so that the worker does most of the logic, but the 'main thread' handles the actually OpenGL API calls.

[bryphe]

I went down this route a bit in the hopes of getting the live playground interactive - but I hit one more blocker. The TextNode requires font access via fontkit.js, which doesn't work from a Worker thread today.