Sometimes the chrome renderer wishes to ship IPCs to the browser process after a CompositorFrame has been received by the display compositor.
The way we deal with this today is through a frame token mechanism. The renderer allocates a new Frame token stuffs it into the CompositorFrame. The renderer ships IPCs tied to that particular frame with ViewHostMsg_FrameSwapMessages.
Currently, RenderWidgetHostImpl::SubmitCompositorFrame synchronously inspects the frame token in the CompositorFrame and matches it up with the frame token of the FrameSwapMessages. Once the frame token in the CF catches up with the frame swap messages, then we start handling the IPCs.
This cannot work with an out-of-process display compositor.
Instead, I propose the following:
1. CompositorFrameSinkSupport tracks the last frame token seen.
2. If it changes, then it informs FrameSinkManagerImpl which informs HostFrameSinkManager.
3. HostFrameSinkManager walks up the hierarchy and informs the parent HostFrameSinkClient.
4. DelegatedFrameHost (for content) is a HostFrameSinkClient and ServerWindow is a HostFrameSinkClient. It should take that changed frame token and inform the appropriate RenderWidgetHostImpl in content...somehow. Perhaps through a new FrameTokenObserver interface?
Comment 1 by fsamuel@google.com
, Oct 3 2017