Support compositing for active animations in SPv2.

third_party/WebKit/Source/core/layout/LayoutObject.h

 /*
  * Copyright (C) 2000 Lars Knoll (knoll@kde.org)
  *           (C) 2000 Antti Koivisto (koivisto@kde.org)
  *           (C) 2000 Dirk Mueller (mueller@kde.org)
  *           (C) 2004 Allan Sandfeld Jensen (kde@carewolf.com)
  * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2012 Apple Inc.
  *               All rights reserved.
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
@@ skipping 1681 matching lines @@
     }
     void clearPreviousVisualRects() {
       m_layoutObject.clearPreviousVisualRects();
     }
     void setNeedsPaintPropertyUpdate() {
       m_layoutObject.setNeedsPaintPropertyUpdate();
     }
 
    protected:
     friend class PaintPropertyTreeBuilder;
+    FRIEND_TEST_ALL_PREFIXES(AnimationCompositorAnimationsTest,

[wkorman, 2016/12/16 23:08:00]

I am not happy about having to do this, but it's just for testing. I'd like to
not have to use a whole RenderingTest in CompositorAnimations.cpp. Open to
thoughts on another way to essentially tack an explicit transform node onto a
LayoutObject's paint properties.

[chrishtr, 2016/12/17 00:05:43]

Which method do you need that is private?

[wkorman, 2016/12/17 00:18:27]

CompositorAnimationsTest has to be able to call:

layoutObject->getMutableForPainting().ensurePaintProperties()

so that we can use updateTransform() to set an explicit transform node. This
method is protected
and per comment below in line 1705 and the friend statement in line 1701, only
PaintPropertyTreeBuilder can
access it currently.

Some other options, none of which seem better IMO but I can be swayed:

- add a public getPaintPropertiesForTesting() method
- loosen restriction on access to these methods (just make them public)
- use a RenderingTest in CompositorAnimationsTest (would make the test added to
CompositorAnimationsTest more deviant than the other tests already there, and
heavier weight than needed, and may need to fiddle other animation infra that
using their existing unit test infra takes care of, but we could do it). I'm
somewhat sketched by our use of RenderingTest in unit tests as using them
produces something more like an integration test for cases like this.
- some more intrusive class extension/override approach, or via interfaces,
essentially, to allow customizing LayoutObject / PaintPropertyTreeBuilder
behavior for test. For example cc/ has a pattern for test code where they will
create TestXxx classes that extend the non-test class and override methods to
produce what they want, see cc/test/test_image_factory.h for example.

+                             canStartAnimationOnCompositorTransformSPv2);
+
     // The following two functions can be called from PaintPropertyTreeBuilder
     // only.
     ObjectPaintProperties& ensurePaintProperties() {
       return m_layoutObject.ensurePaintProperties();
     }
     ObjectPaintProperties* paintProperties() {
       return const_cast<ObjectPaintProperties*>(
           m_layoutObject.paintProperties());
     }
 
@@ skipping 944 matching lines @@
 CORE_EXPORT void showLineTree(const blink::LayoutObject*);
 CORE_EXPORT void showLayoutTree(const blink::LayoutObject* object1);
 // We don't make object2 an optional parameter so that showLayoutTree
 // can be called from gdb easily.
 CORE_EXPORT void showLayoutTree(const blink::LayoutObject* object1,
                                 const blink::LayoutObject* object2);
 
 #endif
 
 #endif  // LayoutObject_h