[Android] Fix a flicker in stopping Chrome

content/browser/renderer_host/compositor_impl_android.cc

Index: content/browser/renderer_host/compositor_impl_android.cc
diff --git a/content/browser/renderer_host/compositor_impl_android.cc b/content/browser/renderer_host/compositor_impl_android.cc
index 3745a376a347e0412999f2652ec4e3df8bb264f7..e32a6600e6e2a7fbbcede995861b448d08d8b10a 100644
--- a/content/browser/renderer_host/compositor_impl_android.cc
+++ b/content/browser/renderer_host/compositor_impl_android.cc
@@ -182,6 +182,7 @@ CompositorImpl::CompositorImpl(CompositorClient* client,
       composite_on_vsync_trigger_(DO_NOT_COMPOSITE),
       pending_swapbuffers_(0U),
       defer_composite_for_gpu_channel_(false),
+      paused_(false),
       weak_factory_(this) {
   DCHECK(client);
   DCHECK(root_window);
@@ -262,6 +263,9 @@ void CompositorImpl::OnGpuChannelEstablished() {
 }
 
 void CompositorImpl::Composite(CompositingTrigger trigger) {
+  if (paused_)

[David Trainor- moved to gerrit, 2015/01/12 18:58:24]

Does bypassing this cause side effects?  I know some render processes wait for
the render ack and I don't know if simply skipping the Composite call would
cause issues.  CC'ing sievers@ who would know more about the scheduling here.

[no sievers, 2015/01/12 19:56:49]

TLDR: We should either unify our code more with Aura and adopt the mechanism of
compositing locks for inhibiting compositing during intermittent transitions
(like resize) if that applies here. Otherwise (anything that's not
intermittent), we should keep the tree in a state that it generates
non-corrupt-looking or flickering content (keep in mind that
CopyFromCompositingSurface is also supposed to eventually lead to a composite
and produce a good frame) *while the compositor surface is visible/available*.
Let's be especially careful what other notions we expose especially to the
embedder (ideally none other than visibility/surface availability).

Exposing the notion of paused makes things more complicated, and it will break
with https://codereview.chromium.org/344743002/ since cc does not have such a
notion. Actually the latter is not entirely true: It's true that cc does not
have the notion but Aura has some sort of compositing locks for short
transitions during resize where the result from compositing would not look good
(wrong aspect ratio or so if scaled). But it should really only be used in
transitions. Is your use case like that?

Otherwise, some general thoughts:
A surface (to which the compositor draws) is either visible or not.
While it's visible you need to be able to generate its contents (because you
also have a readback API that is not expected to generate corrupted content,
i.e. it doesn't actually read back the surface but generates contents from the
layers).

You can certainly hide the surface in different ways (obscure or remove it at
the view hierarchy level, and then you can also set the compositor to hidden or
remove the surface).
While it's onscreen and visible you should have layers in the tree that do not
cause corruption (you can use actual contents, i.e. delegated layer from the
renderer, or some sort of placeholder).

[Changwan Ryu, 2015/01/13 02:24:55]

Thanks for pointing out the conflict, and CopyFromCompositingSurface case. I am
not sure how I can apply resizelock to generic compositing lock without
corruption handling. Let me work on the other idea first, and come back here if
that fails.

+    return;
+
   if (trigger == COMPOSITE_IMMEDIATELY)
     will_composite_immediately_ = false;
 
@@ -327,6 +331,14 @@ ui::ResourceManager& CompositorImpl::GetResourceManager() {
   return resource_manager_;
 }
 
+void CompositorImpl::Pause() {
+  paused_ = true;
+}
+
+void CompositorImpl::Resume() {
+  paused_ = false;
+}
+
 void CompositorImpl::SetRootLayer(scoped_refptr<cc::Layer> root_layer) {
   if (subroot_layer_.get()) {
     subroot_layer_->RemoveFromParent();