cc: Setup API to release OutputSurface from LTHClient.

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
index 4d72eb246854c54d69d5c89b806c73be7d989a0b..c09550fb7999d1f0166cd9f1b10a6ad609acdda7 100644
--- a/cc/trees/layer_tree_host.cc
+++ b/cc/trees/layer_tree_host.cc
@@ -397,6 +397,11 @@ void LayerTreeHost::SetOutputSurface(scoped_ptr<OutputSurface> surface) {
   proxy_->SetOutputSurface(surface.Pass());
 }
 
+scoped_ptr<OutputSurface> LayerTreeHost::GetOutputSurface() {

[no sievers, 2015/09/10 00:00:22]

DCHECK(!visible_);

Otherwise it seems like you could end up displaying corruption.
Also making the LTH invisible before releasing the OutputSurface causes
resources to be deleted (incl. UI resource eviction), which is probably what you
want before you do this.

For this you will also have to make a small change here:

bool SchedulerStateMachine::ShouldBeginOutputSurfaceCreation() const {
+  if (!visible_)
+    return false;

[sohanjg, 2015/09/10 15:07:23]

sorry, i didnt get this part, you mean before asking for OS from proxy, we need
to set LTH visibility as false, right ?

should we also inform scheduler for an explicit OS creation after we release ? 

[no sievers, 2015/09/10 17:27:45]

Yes, I think it makes sense to properly clean up resources instead of going
through the more forceful 'lost context' codepath entirely here.
I'm afraid that otherwise you could end up with glitches on the screen or GL
errors in the log.
We can leave the scheduler alone. I can change that behavior in a separate
patch. It's a bit orthogonal whether LTH asks the client for a new OS while it's
hidden or not.

[sohanjg, 2015/09/11 07:00:49]

Acknowledged.

+  output_surface_lost_ = true;
+  return proxy_->GetOutputSurface();
+}
+
 void LayerTreeHost::RequestNewOutputSurface() {
   client_->RequestNewOutputSurface();
 }