cc: Clean up max frames/swaps pending usage.

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 6834c2200d58a17998221f7424d3a56a137db68c..0a25b945264cf8e128c00cef6e9af7a5cafd32a5 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -2300,8 +2300,7 @@ bool LayerTreeHostImpl::InitializeRenderer(OutputSurface* output_surface) {
   client_->SetEstimatedParentDrawTime(parent_draw_time);
 
   int max_frames_pending = output_surface_->capabilities().max_frames_pending;
-  if (max_frames_pending <= 0)
-    max_frames_pending = OutputSurface::DEFAULT_MAX_FRAMES_PENDING;
+  DCHECK_EQ(1, max_frames_pending);

[sunnyps, 2015/11/16 20:17:46]

Why not remove the max_frames_pending capability completely? Keeping it has
potential to cause confusion about whether we're supposed to support values
other than 1.

[brianderson, 2015/11/16 20:56:58]

I guess we could remove it from LTHI and cc::Scheduler. I'll do that as part of
this patch.

The OutputSurface for the DisplayScheduler can have more than 1 frame pending
though (for example on Chrome OS) - so we'll still need to keep it in the
OutputSurface::Capability.

   client_->SetMaxSwapsPendingOnImplThread(max_frames_pending);
   client_->OnCanDrawStateChanged(CanDraw());