Parts of Gecko assumse that CompositorBridgeParent lives in the same process. Worst offenders look like nsBaseWidget, TabParent, and ContentParent. We'll have to build an abstraction layer that lets this code work either in-process or out. Initially this layer will simply redirect calls in-process, but on the GPU process branch we can start building the actual layers needed.

Just some cleanup, this method is all but duplicated in Android/Gonk for one bool flip. Might as well remove it and inline it into CreateCompositor.

Replace direct access to CompositorBridgeParent with IPC calls.

Going to do DOM access in a separate bug to keep this one small.

This introduces a new CompositorSession class, which now owns the CompositorBridgeParent and CompositorBridgeChild pointers in a widget. Widgets can still access the Child as normal, but the Parent pointer will not exist in out-of-process mode. Widgets that use it wthout auditing will not support out-of-process compositing.

We're not doing GPU process for Android initially, so for now we can just bypass the CompositorSession to access the parent. It looks like most of these calls could go through CompositorBridgeChild in the future.

Comment on attachment 8753098 [details] [diff] [review] part 4.1, fix android build Review of attachment 8753098 [details] [diff] [review]: ----------------------------------------------------------------- I don't really understand the name "CompositorSession" - in particular the "session" part. Are there going to be multiple "composition sessions" during the browser's lifetime? ::: widget/android/nsWindow.cpp @@ +1071,5 @@ > > void SyncResumeCompositor() > { > + if (RefPtr<CompositorBridgeParent> bridge = window.GetCompositorBridgeParent()) { > + if (bridge->ScheduleResumeOnCompositorThread()) { indentation in this file is 4 spaces. I don't care too much, we should be moving towards 2 space indentation anyway. Ditto the code below. @@ +3512,5 @@ > nsWindow::ComputeRenderIntegrity() > { > + if (gGeckoViewWindow) { > + if (RefPtr<CompositorBridgeParent> bridge = gGeckoViewWindow->GetCompositorBridgeParent()) { > + return bridge->ComputeRenderIntegrity(); I'll file a bug to get rid of this function, I don't think we use it for anything anymore.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8) > Comment on attachment 8753098 [details] [diff] [review] > part 4.1, fix android build > > Review of attachment 8753098 [details] [diff] [review]: > ----------------------------------------------------------------- > > I don't really understand the name "CompositorSession" - in particular the > "session" part. Are there going to be multiple "composition sessions" during > the browser's lifetime? Yeah, indeed. Each widget will have its own session, and the session might be recreated if something bad happens (like the process dies or a device resets). Other name suggests are welcome, it was like the least terrible candidate (others were "CompositorProxy" and "CompositorBroker").

(In reply to David Anderson [:dvander] from comment #9) > Yeah, indeed. Each widget will have its own session, and the session might > be recreated if something bad happens (like the process dies or a device > resets). Other name suggests are welcome, it was like the least terrible > candidate (others were "CompositorProxy" and "CompositorBroker"). Yeah I can't come up with anything better either. CompositorSession is ok.

Comment on attachment 8753100 [details] [diff] [review] part 4.2, fix gonk build Thanks David!

https://hg.mozilla.org/integration/mozilla-inbound/rev/7de1e31e30da https://hg.mozilla.org/integration/mozilla-inbound/rev/a7f37448ee21 https://hg.mozilla.org/integration/mozilla-inbound/rev/9c1eef8037ab https://hg.mozilla.org/integration/mozilla-inbound/rev/76466e550399

https://hg.mozilla.org/mozilla-central/rev/7de1e31e30da https://hg.mozilla.org/mozilla-central/rev/a7f37448ee21 https://hg.mozilla.org/mozilla-central/rev/9c1eef8037ab https://hg.mozilla.org/mozilla-central/rev/76466e550399