content/blimp: Set up hooks for enabling LTHRemote in the renderer.

cc/proto/compositor_message.proto

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
 import "compositor_message_to_impl.proto";
 import "compositor_message_to_main.proto";
 import "layer_tree_host.proto";
 
 package cc.proto;
 
 // A top level message for serialized state used by the compositor remote
 // channels.
 // TODO(khushalsagar): Remove CompositorMessage and stop using
 // RemoteProtoChannel to plumb these to/from the browser. See crbug.com/648442
 message CompositorMessage {
   // Engine -> Client
   // Frame Update.
   optional LayerTreeHost layer_tree_host = 3;
 
+  // Client -> Engine
+  // Sent from the client to the engine when a frame update was processed
+  // successfully on the client.

[Wez, 2016/10/19 22:15:28]

nit: This wording implies that there is a possibility of _failure_ to process a
frame update on the Client; is that the case..?

What does the value of the bool indicate? Is the presence of the field all that
matters?  Would it be clearer to use an empty message rather than a bool?

[Khushal, 2016/10/20 01:29:33]

Oh I wanted to specify that this will be in response to the feature receiving
the update and applying it to the compositor state. Applying of the update can
never fail.
The value of the bool is irrelevant. Its just the presence of the field.

I think this should be an enum with the message type. I'd say please ignore the
structure of protos here, I'm not paying much attention to cleaning up the
protos for control messages right now. These are going to be nuked shortly. Its
a bit of a mess from the old path which depends on these and I want to migrate
to the new path quickly so we can remove all the old code that depends on these
messages, and re-define them clearly in blimp/.

I think the bool is fine for now. The next message type to come here is going to
be scroll and scale updates from the client so having an empty message is going
to be more confusing then.

+  optional bool frame_ack = 4;
+
   // One of these is set based on where the message is going to.
   optional CompositorMessageToMain to_main = 1;
   optional CompositorMessageToImpl to_impl = 2;
 }