cc/blimp: Set up the framework for LayerTreeTests in remote mode.

cc/test/layer_tree_host_remote_for_testing.h

Index: cc/test/layer_tree_host_remote_for_testing.h
diff --git a/cc/test/layer_tree_host_remote_for_testing.h b/cc/test/layer_tree_host_remote_for_testing.h
new file mode 100644
index 0000000000000000000000000000000000000000..9220b96f2b5956279bc3386ffbf199930686734a
--- /dev/null
+++ b/cc/test/layer_tree_host_remote_for_testing.h
@@ -0,0 +1,114 @@
+// 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.
+
+#ifndef CC_TEST_LAYER_TREE_HOST_REMOTE_FOR_TESTING_H_
+#define CC_TEST_LAYER_TREE_HOST_REMOTE_FOR_TESTING_H_
+
+#include "base/macros.h"
+#include "cc/blimp/compositor_state_deserializer_client.h"
+#include "cc/blimp/layer_tree_host_remote.h"
+
+namespace gpu {
+class GpuMemoryBufferManager;
+}  // namespace gpu
+
+namespace cc {
+class CompositorStateDeserializer;
+class FakeImageSerializationProcessor;
+class LayerTreeHostInProcess;
+class SharedBitmapManager;
+class TaskGraphRunner;
+
+// This is a version of LayerTreeHostRemote meant to be used for tests that want
+// to inspect the CompositorFrame produced when state updates from the remote
+// host are used by a compositor on the client.
+class LayerTreeHostRemoteForTesting : public LayerTreeHostRemote,

[Khushal, 2016/10/06 18:39:07]

Also I'm hoping to use this class for Layout tests too, the only thing missing
for them is piping for CopyOutputRequests. It would be great if you could review
from that standpoint as well. Thanks!

[enne (OOO), 2016/10/06 20:19:55]

I think it might be worth running layout tests manually once, but I really don't
want to get to adding virtual test suites to layout tests for blimp.  I think
layer tree pixel tests and cc unit tests cover most everything that should be
needed.

We probably are going to want separate serialization unit tests anyway for
display lists and such, and I think those should cover the rest of the missing
pieces, in my opinion.

[Khushal, 2016/10/06 21:09:42]

I'll try with a few layout tests to see how feasible/stable using an approach
like this is. The aim is to get maximum coverage from the existing test
frameworks to make sure things don't fail silently. Its at least worth
experimenting with an FYI bot I guess.

[enne (OOO), 2016/10/06 21:32:18]

As I said, I think running layout tests manually is going to be the best
approach here.  Which functionality in particular are you worried about failing
that cc unit tests are not going to catch?

The only reason that there are even threaded vs single threaded layout tests is
because Blink itself set up animations differently based on this distinction and
nobody took the time to write the code to make it possible to have single
threaded animations on the compositor thread and it's been too thorny to remove
ever since.  I think in general these are implementation details in cc that
should not make a different to Blink, and so should be tested elsewhere by more
targeted unit tests.  I would also hope that Blimp integration tests would
involve more of the pipeline and not a LayerTreeRemoteForTesting.

If you want to run an FYI bot, you might want to chrishtr, as he's been doing
that for the slimming paint project.

[Khushal, 2016/10/06 22:48:51]

Sorry, that's what I meant. I'll try a few tests manually first. After I hook up
CopyOutputRequests, which is necessary for cc pixel tests as well anyway.

Regarding functionality, I don't have a good answer tbh. I'm just concerned
about cases where, for instance, a property is added to cc but its a trivial
push through to commit/activation so doesn't end up in a cc LayerTreeTest, but
does end up including a layout test. Though now that I think about it such cases
would not be covered in layout tests in single threaded mode as well, since that
code path will not cover the activation path?

So I guess its a distant possibility and I'm just being paranoid. Thanks for the
guidance on this. I'm not as familiar with layout tests to make a correct
judgement here so I'll put this on the back of the list for now, to come back
later when its clearer what code is where.
The integration tests would. We already have one which tests the complete
pipeline end-to-end
(https://cs.chromium.org/chromium/src/blimp/engine/browser_tests/integration_t...),
but these should be be more akin to the browser tests right? As you mentioned,
given that we don't even use threaded compositor for layout tests (I assume
because they tend to be flaky?), I was worried adding more parts of the blimp
pipeline to them is going to have the same problem. Also, one reason for
considering using a test suite like this was because setting up the code to have
more of the blimp pipeline without content shell and existing setup for the
blink test runner is not trivial.

But now I realize that if we don't include them then having layout tests is not
even worth it... 

+                                      public CompositorStateDeserializerClient {
+ public:
+  static std::unique_ptr<LayerTreeHostRemoteForTesting> Create(
+      LayerTreeHostClient* client,
+      std::unique_ptr<AnimationHost> animation_host,
+      LayerTreeSettings const* settings,
+      SharedBitmapManager* shared_bitmap_manager,
+      gpu::GpuMemoryBufferManager* gpu_memory_buffer_manager,
+      TaskGraphRunner* task_graph_runner,
+      scoped_refptr<base::SingleThreadTaskRunner> main_task_runner,
+      scoped_refptr<base::SingleThreadTaskRunner> impl_task_runner);
+
+  static std::unique_ptr<RemoteCompositorBridge> CreateRemoteCompositorBridge(
+      scoped_refptr<base::SingleThreadTaskRunner> main_task_runner);
+
+  ~LayerTreeHostRemoteForTesting() override;
+
+  // LayerTreeHost interface.
+  void SetVisible(bool visible) override;
+  void SetCompositorFrameSink(
+      std::unique_ptr<CompositorFrameSink> compositor_frame_sink) override;
+  std::unique_ptr<CompositorFrameSink> ReleaseCompositorFrameSink() override;
+  void SetNeedsRedraw() override;
+  void SetNeedsRedrawRect(const gfx::Rect& damage_rect) override;
+  void SetNextCommitForcesRedraw() override;
+  void NotifyInputThrottledUntilCommit() override;
+  const base::WeakPtr<InputHandler>& GetInputHandler() const override;
+
+  LayerTreeHostInProcess* layer_tree_host_in_process() const {
+    return layer_tree_host_in_process_.get();
+  }
+
+ protected:
+  explicit LayerTreeHostRemoteForTesting(InitParams* params);
+
+  void Initialize(SharedBitmapManager* shared_bitmap_manager,
+                  gpu::GpuMemoryBufferManager* gpu_memory_buffer_manager,
+                  TaskGraphRunner* task_graph_runner,
+                  scoped_refptr<base::SingleThreadTaskRunner> main_task_runner,
+                  scoped_refptr<base::SingleThreadTaskRunner> impl_task_runner,
+                  std::unique_ptr<FakeImageSerializationProcessor>
+                      image_serialization_processor);
+
+  virtual std::unique_ptr<LayerTreeHostInProcess> CreateLayerTreeHostInProcess(
+      LayerTreeHostClient* client,
+      SharedBitmapManager* shared_bitmap_manager,
+      gpu::GpuMemoryBufferManager* gpu_memory_buffer_manager,
+      TaskGraphRunner* task_graph_runner,
+      const LayerTreeSettings& settings,
+      scoped_refptr<base::SingleThreadTaskRunner> main_task_runner,
+      scoped_refptr<base::SingleThreadTaskRunner> impl_task_runner);
+
+ private:
+  class LayerTreeHostInProcessClient;
+  class RemoteCompositorBridgeImpl;
+
+  // CompositorStateDeserializerClient implementation.
+  bool ShouldRetainClientScroll(int engine_layer_id,
+                                const gfx::ScrollOffset& new_offset) override;
+  bool ShouldRetainClientPageScale(float new_page_scale) override;
+
+  // LayerTreeHostRemote interface.
+  void DispatchDrawAndSwapCallbacks() override;
+
+  void LayerDidScroll(int engine_layer_id);
+
+  void RemoteHostNeedsMainFrame();
+  void ProcessRemoteCompositorUpdate(
+      std::unique_ptr<CompositorProtoState> compositor_proto_state);
+  void UpdateStateOnInProcessHost();
+
+  std::unique_ptr<LayerTreeHostInProcess> layer_tree_host_in_process_;
+  std::unique_ptr<CompositorStateDeserializer> compositor_state_deserializer_;
+
+  std::unique_ptr<CompositorProtoState> pending_compositor_proto_state_;
+
+  std::unique_ptr<LayerTreeHostInProcessClient>
+      layer_tree_host_in_process_client_;
+
+  std::unique_ptr<FakeImageSerializationProcessor>
+      image_serialization_processor_;
+
+  DISALLOW_COPY_AND_ASSIGN(LayerTreeHostRemoteForTesting);
+};
+
+}  // namespace cc
+
+#endif  // CC_TEST_LAYER_TREE_HOST_REMOTE_FOR_TESTING_H_