cc/blimp: Add a LayerTreeHostRemote implementation.

cc/trees/layer_tree_host.cc

Index: cc/trees/layer_tree_host.cc
diff --git a/cc/trees/layer_tree_host.cc b/cc/trees/layer_tree_host.cc
new file mode 100644
index 0000000000000000000000000000000000000000..a8b247940b60181cfdcf9a048e64141df275ecf8
--- /dev/null
+++ b/cc/trees/layer_tree_host.cc
@@ -0,0 +1,19 @@
+// Copyright 2016 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.
+
+#include "cc/trees/layer_tree_host.h"
+
+#include "base/atomic_sequence_num.h"
+
+namespace cc {
+namespace {
+static base::StaticAtomicSequenceNumber s_layer_tree_host_sequence_number;
+}  // namespace
+
+// static
+int LayerTreeHost::GenerateHostId() {
+  return s_layer_tree_host_sequence_number.GetNext() + 1;

[danakj, 2016/09/26 21:36:54]

It's not clear to me why this is here and not just in LTHRemote, like does
LTHRemote and LTHInProc need to share the same namespace for these ids?

[Khushal, 2016/09/27 01:07:50]

The API said that it will give you a process global id for the LayerTreeHost, so
I figured I'll respect that and make sure that LayerTreeHost ids never collide.
I don't think we'll ever have a case where you create both (in-process and
remote) in the same process, other than tests, so happy to keep it in LTHRemote
if that's better.

[danakj, 2016/09/30 22:37:12]

I think I'd prefer it as an implementation detail of each lth.

+}
+
+}  // namespace cc