Closed
Bug 845686
Opened 11 years ago
Closed 10 years ago
Hook up GeckoContentController for nested content processes
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1020199
People
(Reporter: cjones, Unassigned)
References
Details
In this diagram (attachment 718845 [details]), we'll need APZCs associated with layer trees under the blue CPCompositorParent in the top-left of the diagram to be able to request repaints from their TabChilds associated with the red ContentChild in the bottom-right of the diagram.
Currently, the RenderFrameParent associated with the APZC lives in the same process as the APZC, so we can just bounce requests to it. With nested content processes, that won't be the case anymore.
The simplest way to solve this is probably to create a second implementation of PRenderFrame that just bounces requests down the tree. For example
APZC ====> RenderFrameProxyParent [b2g process]
|
\./
RenderFrameProxyChild --> RenderFrameParent [first-level process]
|
\./
TabChild [nested process]
This will result in one extra IPC message per repaint request, which I suspect is fine since these are pretty infrequent (10 or so a second at most). If it's not fine, we can create a bridge for these messages.
Updated•10 years ago
|
Blocks: nested-oop
Comment 1•10 years ago
|
||
I think this is basically the same as bug 1020199, but perhaps based on a slightly older design of how the nested content processes worked out. Duping this over.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•