[SPv2] Adds pre-computed paint property context to PaintLayer.

third_party/WebKit/Source/core/paint/ObjectPaintProperties.h

 // Copyright 2015 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.
 
 #ifndef ObjectPaintProperties_h
 #define ObjectPaintProperties_h
 
+#include "platform/geometry/LayoutPoint.h"

[pdr., 2016/02/04 04:54:01]

Can you update PaintPropertyTreePrinter too?

To test, I usually add this to FrameView.cpp:
#include "core/paint/PaintPropertyTreePrinter.h"
and
showTransformPropertyTree(*this);
showClipPropertyTree(*this);
to the end of FrameView::updatePaintProperties.

Or, if you don't find this class useful, lets delete PaintPropertyTreePrinter in
a followup. AFAIK, I'm the only user.

[trchen, 2016/02/04 23:08:40]

Acknowledged.

[trchen, 2016/02/04 23:49:01]

I examined PaintPropertyTreePainter. The painter only dumps the property tree
hierarchy, but this CL doesn't change the tree hierarchy at all. For the newly
added information you probably want to show them in the layout tree dumper.

 #include "platform/graphics/paint/ClipPaintPropertyNode.h"
 #include "platform/graphics/paint/EffectPaintPropertyNode.h"
+#include "platform/graphics/paint/PaintChunkProperties.h"
 #include "platform/graphics/paint/TransformPaintPropertyNode.h"
 #include "wtf/PassOwnPtr.h"
 #include "wtf/PassRefPtr.h"
 #include "wtf/RefPtr.h"
 
 namespace blink {
 
 // The minimal set of paint properties created by a |LayoutObject|. These

[pdr., 2016/02/04 04:54:01]

We need to update this comment too, since the properties here are not just the
ones created by a layout object.

[trchen, 2016/02/04 23:08:40]

Acknowledged.

 // properties encode a hierachy of transforms, clips, effects, etc, both between
 // LayoutObjects (each property has a parent) and among the properties of a
 // single LayoutObject (e.g., transform and perspective with the correct parent
 // relationship to represent ordering).
 //
 // This differs from |PaintChunkProperties| because it can store multiple
 // properties of the same type (e.g., transform and perspective which are both
 // transforms).
 class ObjectPaintProperties {
     WTF_MAKE_NONCOPYABLE(ObjectPaintProperties);
     USING_FAST_MALLOC(ObjectPaintProperties);
 public:
+    struct PropertyTreeContext;
+
     static PassOwnPtr<ObjectPaintProperties> create(
         PassRefPtr<TransformPaintPropertyNode> paintOffsetTranslation,
         PassRefPtr<TransformPaintPropertyNode> transform,
         PassRefPtr<EffectPaintPropertyNode> effect,
         PassRefPtr<ClipPaintPropertyNode> overflowClip,
         PassRefPtr<TransformPaintPropertyNode> perspective,
-        PassRefPtr<TransformPaintPropertyNode> scrollTranslation)
+        PassRefPtr<TransformPaintPropertyNode> scrollTranslation,
+        PassOwnPtr<PropertyTreeContext> propertyTreeContext)
     {
-        return adoptPtr(new ObjectPaintProperties(paintOffsetTranslation, transform, effect, overflowClip, perspective, scrollTranslation));
+        return adoptPtr(new ObjectPaintProperties(paintOffsetTranslation, transform, effect, overflowClip, perspective, scrollTranslation, propertyTreeContext));
     }
 
     // The hierarchy of transform subtree created by a LayoutObject.
     // [ paintOffsetTranslation ]           Normally paint offset is accumulated without creating a node
     // |                                    until we see, for example, transform or position:fixed.
     // +---[ transform ]                    The space created by CSS transform.
+    //     |                                It is the local border box space the painter expects,

[pdr., 2016/02/04 04:54:01]

This helped me understand the situation. Maybe even rephrase this a little:
"<-- This is the local border box space, see: PropertyTreeContext below."

[trchen, 2016/02/04 23:08:40]

Acknowledged.

+    //     |                                see PropertyTreeContext below.
     //     +---[ perspective ]              The space created by CSS perspective.
     //         +---[ scrollTranslation ]    The space created by overflow clip.
     TransformPaintPropertyNode* paintOffsetTranslation() const { return m_paintOffsetTranslation.get(); }
     TransformPaintPropertyNode* transform() const { return m_transform.get(); }
     TransformPaintPropertyNode* perspective() const { return m_perspective.get(); }
     TransformPaintPropertyNode* scrollTranslation() const { return m_scrollTranslation.get(); }
 
     // Transform that applies to layer contents, or nullptr if this object
     // doesn't define one.
     TransformPaintPropertyNode* transformForLayerContents() const;

[pdr., 2016/02/04 04:54:01]

I think this comment and code still needs updating to return the context
transform node.

[trchen, 2016/02/04 23:08:40]

Not really. The difference is that this function only create nodes created
locally, while the cache always return the nearest ancestor. (And this function
is going away anyway.)

 
     EffectPaintPropertyNode* effect() const { return m_effect.get(); }
 
     ClipPaintPropertyNode* overflowClip() const { return m_overflowClip.get(); }
 
+    // This is a complete set of property nodes that should be used as a starting point to paint
+    // this layout object. It is needed becauase some property inherits from the containing block,
+    // not painting parent, thus can't be derived in O(1) during paint walk.
+    // Note: If this layout object has transform or stacking-context effects, those are already
+    // baked into in the context here. However for properties that affects only children,
+    // for example, perspective and overflow clip, those should be applied by the painter
+    // at the right painting step.
+    struct PropertyTreeContext {

[pdr., 2016/02/04 04:54:01]

WDYT of "LocalBorderBoxProperties"? In reading through this patch (and your
comment above), I realized this may be a better name since it implies that
transform may come before, and overflow clip after, etc.

[trchen, 2016/02/04 23:08:40]

Sounds clear! Let's do that.

+        LayoutPoint paintOffset;
+        PaintChunkProperties properties;

[pdr., 2016/02/04 04:54:01]

Can you think of a case when the effect/filter property ever be used?

[trchen, 2016/02/04 23:08:40]

Probably not. Effect node can be derived from the paint walk in O(1). It is
there just for convenience.

+    };
+    PropertyTreeContext* propertyTreeContext() const { return m_propertyTreeContext.get(); }
+
 private:
     ObjectPaintProperties(
         PassRefPtr<TransformPaintPropertyNode> paintOffsetTranslation,
         PassRefPtr<TransformPaintPropertyNode> transform,
         PassRefPtr<EffectPaintPropertyNode> effect,
         PassRefPtr<ClipPaintPropertyNode> overflowClip,
         PassRefPtr<TransformPaintPropertyNode> perspective,
-        PassRefPtr<TransformPaintPropertyNode> scrollTranslation)
+        PassRefPtr<TransformPaintPropertyNode> scrollTranslation,
+        PassOwnPtr<PropertyTreeContext> propertyTreeContext)
         : m_paintOffsetTranslation(paintOffsetTranslation)
         , m_transform(transform)
         , m_effect(effect)
         , m_overflowClip(overflowClip)
         , m_perspective(perspective)
-        , m_scrollTranslation(scrollTranslation) { }
+        , m_scrollTranslation(scrollTranslation)
+        , m_propertyTreeContext(propertyTreeContext) { }
 
     RefPtr<TransformPaintPropertyNode> m_paintOffsetTranslation;
     RefPtr<TransformPaintPropertyNode> m_transform;
     RefPtr<EffectPaintPropertyNode> m_effect;
     RefPtr<ClipPaintPropertyNode> m_overflowClip;
     RefPtr<TransformPaintPropertyNode> m_perspective;
     RefPtr<TransformPaintPropertyNode> m_scrollTranslation;
+
+    OwnPtr<PropertyTreeContext> m_propertyTreeContext;
 };
 
 } // namespace blink
 
 #endif // ObjectPaintProperties_h