cc: Activate when going invisible.

cc/scheduler/scheduler_state_machine.cc

 // Copyright 2011 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/scheduler/scheduler_state_machine.h"
 
 #include "base/debug/trace_event.h"
 #include "base/debug/trace_event_argument.h"
 #include "base/format_macros.h"
 #include "base/logging.h"
@@ skipping 264 matching lines @@
   // These are all the cases where we normally cannot or do not want to draw
   // but, if needs_redraw_ is true and we do not draw to make forward progress,
   // we might deadlock with the main thread.
   // This should be a superset of PendingActivationsShouldBeForced() since
   // activation of the pending tree is blocked by drawing of the active tree and
   // the main thread might be blocked on activation of the most recent commit.
   if (PendingActivationsShouldBeForced())
     return true;
 
   // Additional states where we should abort draws.
-  // Note: We don't force activation in these cases because doing so would
-  // result in checkerboarding on resize, becoming visible, etc.
   if (!can_draw_)

[brianderson, 2014/09/25 20:07:42]

Do we also set the high res required to draw flag on the pos edge of can_draw_?

If so, should we force activation in this case too? It might make resize more
responsive if we have less tiles to manage and rasterize.

If not, should we?

Then PendingDrawsShouldBeAborted and PendingActivationsShouldBeForced would be
the same thing.

[danakj, 2014/09/25 20:16:07]

That's a good question. We recently had to add a SetRequiresHighRes when making
a output surface, which is another case of CanDraw.

Having no root layer -> checkerboards sounds wrong. I think we guard against
that by checking for a twin when marking things active right now.

The other one is the viewport size changing. Then we stop drawing until we
activate. In that case it's less clear to me that we want to force high res to
complete if you were looking at low res. But it's also a super corner case and I
don't feel strongly if we were to do that.

     return true;
-  if (!visible_)
-    return true;
   return false;
 }
 
 bool SchedulerStateMachine::PendingActivationsShouldBeForced() const {
-  // These are all the cases where, if we do not force activations to make
-  // forward progress, we might deadlock with the main thread.
+  // There is no output surface to trigger our activations.
+  // If we do not force activations to make forward progress, we might deadlock
+  // with the main thread.
+  if (output_surface_state_ == OUTPUT_SURFACE_LOST)
+    return true;
 
-  // There is no output surface to trigger our activations.
-  if (output_surface_state_ == OUTPUT_SURFACE_LOST)
+  // If we're not visible, we should force activation.
+  // Since we set RequiresHighResToDraw when becoming visible, we ensure that we
+  // don't checkerboard until all visible resources are done. Furthermore, if we
+  // do keep the pending tree around, when becoming visible we might activate
+  // prematurely causing RequiresHighResToDraw flag to be reset. In all cases,
+  // we can simply activate on becoming invisible since we don't need to draw
+  // the active tree when we're in this state.
+  if (!visible_)
     return true;
 
   return false;
 }
 
 bool SchedulerStateMachine::ShouldBeginOutputSurfaceCreation() const {
   // Don't try to initialize too early.
   if (!can_start_)
     return false;
 
@@ skipping 784 matching lines @@
       static_cast<int>(begin_impl_frame_state_),
       static_cast<int>(commit_state_),
       has_pending_tree_ ? 'T' : 'F',
       pending_tree_is_ready_for_activation_ ? 'T' : 'F',
       active_tree_needs_first_draw_ ? 'T' : 'F',
       max_pending_swaps_,
       pending_swaps_);
 }
 
 }  // namespace cc