The integration points for Blimp on the client and engine need to move out of cc internals. On the engine this would involve implementing the LayerTreeHost interface for blimp and sharing the frame output in proto format with the blimp layer. There are also a lot of interfaces that we use which need to be re-structured as a part of this.
ImageSerializationProcessor: This mostly has interfaces for Engine/Client Picture caches, which are somewhat convoluted because we weren't doing the necessary state tracking inside cc at all. The purpose of these interfaces is just to track the SkPictures used in the current frame, so we can send the diff from the previous frame. I was thinking about structuring the way frame data is shared from cc in the following way:
struct CompositorProtoState {
// Serialized state stored in the LayerTree.
std::unique_ptr<cc::proto::LayerTreeState> layer_tree;
// List of serialized state for the dirty layers. This includes the Inputs in the Layer,
// and the serialized display list. For SkPictures, when we serialize we put the picture's
// unique id for the picture.
std::vector<cc::proto::LayerState> dirty_layers;
// The set of pictures used in this frame.
std::unordered_set<sk_sp<SkPicture>> pictures_;
}
Ideally cc shouldn't have to know about the caching being done in blimp. We'll be generating much more granular deltas from the cc protos for other state as well anyway. Slightly iffy part here is going to be that we might end up having to put what the final frame proto sent to the client looks like in cc, because we can't include protos from other directories right now. :/
RemoteProtoChannel: Its implemented by the RenderWidgetCompositor and is used to IPC compositor proto messages out to the browser. We shouldn't send bytes to/from the renderer anymore for the control messages. Especially because a lot of synchronization/scheduling details that were hidden inside cc protos up till now are now going to be done by blimp.
The other part is the sync protocol. I was thinking that for the transition, we can keep the protocol somewhat consistent with what we have right now. Both the engine and client can send state updates, but have to wait for an Ack from the peer before sending another update. And the ack can piggyback on a state update, so the ack for scroll/scale state from the engine can come with a frame update. This will change a lot when we start adding throttling policy to the frame scheduling logic.
Comment 1 by bugdroid1@chromium.org
, Oct 3 2016