cc: Plumb device color space through to rasterization

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index 7f424f9897c6de8d5aa805c2032c17783022631f..ffb90b4451dc636c732b8c2ff8482f3cfeab43fe 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -1323,6 +1323,10 @@ void LayerTreeHostImpl::SetIsLikelyToRequireADraw(
   is_likely_to_require_a_draw_ = is_likely_to_require_a_draw;
 }
 
+const gfx::ColorSpace& LayerTreeHostImpl::GetTileColorSpace() const {
+  return sync_tree()->device_color_space();

[ccameron, 2016/09/13 23:34:16]

I'd vaguely want to put the device_color_space hanging off of the
LayerTreeHostImpl instead of the LayerTreeHost, but there seemed to be little
precedent for doing such a thing. Does pulling it from the sync_tree seem
reasonable here?

[vmpstr, 2016/09/14 23:00:43]

sync_tree might be nullptr, right? If we activate and scroll on the compositor
thread, then new tiles would have to access this

[ccameron, 2016/09/15 07:13:42]

I was planning to have this return a gfx::ColorSpace (instead of the const
reference) and just return the default value if there were no tree (sync_tree is
"pending_tree ? pending_tree : active_tree"), but then I found that that case
wasn't hit (at least in unittests and basic browsing).

That said, now that we've lifted the call to this out of the main loop, we might
as well have it return by value.

+}
+
 void LayerTreeHostImpl::NotifyReadyToActivate() {
   client_->NotifyReadyToActivate();
 }