1030721 - Use dedicated e10s processes for Shumway

Reporter

Description

•

11 years ago

We want most of Shumway running off the main thread. The Flash player even runs in its own process, and we'd like to look into doing the same for Shumway. Ideally, we'd not use any Shumway-specific platform capabilities, but just implement all inter-process communication on top of the e10s message manager[1]. The main difficulty is that we need re-entrant synchronous communication, explicitly with the capability to block to main thread/process on the Shumway thread/process: Flash exposes a synchronous interface that allows JS to call into Flash and vice-versa. In bug 930908, we're looking into instead implementing synchronous communication for a dedicated ShumwayWorker. I think nobody is happy with this solution, as it'd be a one-off implementation of complicated, error-prone platform functionality that would only be used by Shumway and hence be comparatively undertested. Additionally, using a dedicated process would have the advantage of enabling access to Canvas2D and text layout, simplifying and speeding up core parts of Shumway's document object model. I briefly talked about this with billm, and it seems like e10s should be a viable solution. AFAICT, if the following requirements can be met, we should be fine: - re-entrant synchronous communication. The main process can block on the child by using CPOWs, but can the child process use sendSyncMessage from within such a call without causing a deadlock? - copying/transferring of ArrayBuffers between processes. If my reading of the e10s documentation is correct, buffers cannot currently be transferred between processes. It seems to me like lifting that restriction shouldn't be too hard. It would be even better if we'd be able to transfer buffers as that would speed up the process of updating the rendering side of things based on what content script did to the display list. And ideally, copy-on-write would work for buffers that have to exist on both threads/processes but aren't ever written to after initial creation. Bug 1025085 tracks adding those for workers, and bug 934450 tracks adding support for COW arrays to SpiderMonkey in the first place. Still, these things are optimizations and we'd almost certainly have a viable implementation without them. - Shumway-process access to WebGL contexts that are part of web page compositing. Bill says that there is support for this, but that there might be restrictions on alpha compositing. Since we talked, it occurred to me that this might not be critical, as we could do all (WebGL-based Shumway) compositing in the main/web content process, while Canvas2D-based shape and text rendering would happen in the Shumway process. That should be it, I think. What do people think, are there any dealbreakers, or is this feasible? If the latter, what would be good first steps for setting it up? [1]: https://developer.mozilla.org/en-US/docs/The_message_manager

Till Schneidereit [:till]

Reporter

Comment 1

•

11 years ago

Oh, and I'm talking about more than one process because we need the ability to parallelize script execution and rendering: for a lot of Flash content we spend considerable amounts of time in both, and since Flash's rendering model is frame-based, it's possible to fully parallelize them by sending off a rendering request from the script execution and immediately start processing the next frame's scripts, while another thread/process can do the rendering. If we just do all rendering on the main/web content process, this becomes a non-issue, however. And that might well be a good solution.