cc: DelegatedRendererLayer creates a ChildId with the ResourceProvider

cc/test/layer_tree_test_common.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/test/layer_tree_test_common.h"
 
 #include "cc/animation.h"
 #include "cc/animation_registrar.h"
 #include "cc/content_layer.h"
 #include "cc/input_handler.h"
@@ skipping 60 matching lines @@
 void MockLayerTreeHostImpl::beginCommit()
 {
     LayerTreeHostImpl::beginCommit();
     m_testHooks->beginCommitOnThread(this);
 }
 
 void MockLayerTreeHostImpl::commitComplete()
 {
     LayerTreeHostImpl::commitComplete();
     m_testHooks->commitCompleteOnThread(this);
+
+    if (!settings().implSidePainting)
+        m_testHooks->treeActivatedOnThread(this);

[piman, 2013/02/26 22:49:21]

Should this be before LayerTreeHostImpl::commitComplete? The assumption is that
activation happens in finishCommitOnImplThread, which is called before
commitComplete.

[danakj, 2013/02/26 22:56:54]

It could be commit complete - they're equal at the moment. But I think this will
remain true forever, whereas commit complete is true only if we block commit?

[piman, 2013/02/26 23:19:21]

This part is only relevant for non-impl-side-painting I guess - I assume when we
remove non-impl-side-painting, this code would go away too. I'm just trying to
see if we can preserve the order of the callbacks so that if we inspect state
from either of the callbacks, it's consistent.
If it doesn't matter, then feel free to land as is.

[danakj, 2013/02/26 23:32:55]

Oh sorry I replied about a completely different line of code... Yes this goes
away when implSidePainting is always true.

You're absolutely right. However, with impl painting on, the tree is activated
after commit complete. Creating a test environment where different settings call
things in different order is really horrible, so I prefer to lie here and do it
after commitComplete - same as with impl painting. It should be safe because it
just delays the activate notification, the tree is definitely activated when
this is called.

(For example theres lots of callbacks thread proxy does but single thread proxy
doesn't which makes testing both modes a lot trickier than it should be. I'm
scarred from this.)

+
 }
 
 bool MockLayerTreeHostImpl::prepareToDraw(FrameData& frame)
 {
     bool result = LayerTreeHostImpl::prepareToDraw(frame);
     if (!m_testHooks->prepareToDrawOnThread(this, frame, result))
         result = false;
     return result;
 }
 
 void MockLayerTreeHostImpl::drawLayers(FrameData& frame)
 {
     LayerTreeHostImpl::drawLayers(frame);
     m_testHooks->drawLayersOnThread(this);
 }
 
-void MockLayerTreeHostImpl::activatePendingTreeIfNeeded()
+bool MockLayerTreeHostImpl::activatePendingTreeIfNeeded()
 {
     if (!pendingTree())
-        return;
+        return false;
 
-    if (m_testHooks->canActivatePendingTree())
-        activatePendingTree();
+    if (!m_testHooks->canActivatePendingTree())
+        return false;
+
+    bool activated = LayerTreeHostImpl::activatePendingTreeIfNeeded();
+    if (activated)
+        m_testHooks->treeActivatedOnThread(this);
+    return activated;
+}
+
+bool MockLayerTreeHostImpl::initializeRenderer(scoped_ptr<OutputSurface> outputSurface)
+{
+    bool success = LayerTreeHostImpl::initializeRenderer(outputSurface.Pass());
+    m_testHooks->initializedRendererOnThread(this, success);
+    return success;
 }
 
 void MockLayerTreeHostImpl::animateLayers(base::TimeTicks monotonicTime, base::Time wallClockTime)
 {
     m_testHooks->willAnimateLayers(this, monotonicTime);
     LayerTreeHostImpl::animateLayers(monotonicTime, wallClockTime);
     m_testHooks->animateLayers(this, monotonicTime);
 }
 
 void MockLayerTreeHostImpl::updateAnimationState()
@@ skipping 356 matching lines @@
     ASSERT_FALSE(m_layerTreeHost.get());
     m_client.reset();
     if (m_timedOut) {
         FAIL() << "Test timed out";
         return;
     }
     afterTest();
 }
 
 }  // namespace cc