Multithreaded rendering

[AshleyScirra]

I've noticed Ejecta has a single threaded renderer. Calls to both the 2D and WebGL contexts result in synchronous OpenGL calls on the same thread.

If context calls simply save their parameters, push the call to a queue then return, then it can return to the JS thread more quickly. Main thread contention is reduced and there is more time to run JS code (very much important on iOS since there is no JIT support). Then a separate renderer thread runs the queue and actually executes it. The driver code in actual OpenGL calls, as well as calculations made in the 2D context calls, can happen in parallel to the JS execution. The iPhone 4S and newer have dual-core processors so can definitely benefit from this, since rendering work can happen on a separate core. Modern browsers like Chrome employ this strategy to maximise performance.

A couple of notes:

• the 2D context binding should not be totally dumb and just forward all calls blindly; it would still be prudent to eliminate redundant calls such as setting the same composite mode, global alpha, font etc. multiple times in a row. (Construct 2 does this very frequently since the plugin architecture makes the state unpredictable.) WebGL mode however can just forward everything that is passed to it.
• in my experience many platforms have some limitations on the threaded use of OpenGL contexts; it may need a special creation mode, or the context may need to be created on the renderer thread, or you may need special calls like Windows' wglMakeCurrent to explicitly indicate control of the context is switching to another thread. iOS probably has its own quirks with this.

I will of course look in to this myself, but all of the codebase, language and platform are unfamiliar to me.

[weepy]

This would be really sweet. I often find that the JSC blocks for much longer than I'd like it to.

On Fri, Apr 11, 2014 at 4:21 PM, Ashley (Scirra) notifications@github.comwrote:

I've noticed Ejecta has a single threaded renderer. Calls to both the 2D and WebGL contexts result in synchronous OpenGL calls on the same thread.

If context calls simply save their parameters, push the call to a queue then return, then it can return to the JS thread more quickly. Main thread contention is reduced and JS performance increases (very much important on iOS since there is no JIT support). Then a separate renderer thread runs the queue and actually executes it. The driver code in actual OpenGL calls, as well as calculations made in the 2D context calls, can happen in parallel to the JS execution. The iPhone 4S and newer have dual-core processors so can definitely benefit from this, since rendering work can happen on a separate core.

I will of course look in to this myself, but all of the codebase, language and platform are unfamiliar to me.

Reply to this email directly or view it on GitHubhttps://github.com/phoboslab/Ejecta/issues/375 .

[weepy]

I'd be very interested in helping make this happen. I have a major lag in my external thread since it sometimes has to call into the JSC which is often in a draw thread.

I imagine that it would be relatively straight forward, the major amount of work would be in making sure the relevant information is copied from the JSC into C-land straight away.

Regarding the blind calls - it is potentially a useful strategy, but perhaps we would start off without it and add it in as necessary.

Are the difficulties with regard to OpenGL a problem with multi-threading ? I wouldn't expect a single thread to cause problems. I wonder if we could just use GCD and put the relevant code in blocks ?

@phoboslab - is this a sensible approach - are there any gotcha's?

[amadeus]

I'm no expert, however I don't think this would work for a few reasons.

Getting the pixel data would be out of sync.

Potentially serious frame lag relative to what the engine is doing, and that lag could potentially get worse and worse as time goes on.

I think I would prefer work going into the Web Workers API, when it comes to multi threaded stuff.

[AshleyScirra]

@amadeus - of course it will work, Chrome uses this approach to maximise performance and it works great. Getting pixel data back just needs to flush and block (which is slow, but nobody expects reading pixel data back to be fast). Despite being a separate thread it can still be synchronised with screen draws.

@weepy - I barely know where to begin, but if you can get as far as just one draw call working, I can flesh out the rest!

[phoboslab]

Closing for lack of interest. I don't think there's that much to gain here anyway. For Ejecta, most of the work is done on the GPU.