Switch to null root property tree nodes [spv2]

third_party/WebKit/Source/platform/graphics/paint/README.md

 # Platform paint code
 
 This directory contains the implementation of display lists and display
 list-based painting, except for code which requires knowledge of `core/`
 concepts, such as DOM elements and layout objects.
 
 This code is owned by the [paint team][paint-team-site].
 
 Slimming Paint v2 is currently being implemented. Unlike Slimming Paint v1, SPv2
 represents its paint artifact not as a flat display list, but as a list of
@@ skipping 13 matching lines @@
 
 ## Paint properties
 
 Paint properties define characteristics of how a paint chunk should be drawn,
 such as the transform it should be drawn with. To enable efficient updates,
 a chunk's paint properties are described hierarchically. For instance, each
 chunk is associated with a transform node, whose matrix should be multiplied by
 its ancestor transform nodes in order to compute the final transformation matrix
 to the screen.
 
-*** note
-Support for all paint properties has yet to be implemented in SPv2.
-***
+Paint properties are owned and stored by the object that creates them (see
+[ObjectPaintProperties](../../../core/paint/ObjectPaintProperties.h) and the
+paint properties on [FrameView](../../../core/frame/FrameView.h)). The complete
+set of property tree nodes used to paint a LayoutObject is cached on
+[ObjectPaintProperties](../../../core/paint/ObjectPaintProperties.h) in
+`LocalBorderBoxProperties`. There is an important distinction between the local
+border box properties and the properties owned by a layout object: a null
+property in [ObjectPaintProperties](../../../core/paint/ObjectPaintProperties.h)
+(e.g., `paintOffsetTranslation`) only implies that a specific LayoutObject
+doesn't create a property, but a null value in `LocalBorderBoxProperties`
+implies that the root property tree node should be used.
 
 *** aside
 TODO(jbroman): Explain the semantics of transforms, clips, scrolls and effects
 as support for them is added to SPv2.
 ***
 
 ### Transforms
 
-Each paint chunk is associated with a [transform node](TransformPaintPropertyNode.h),
+Paint chunks can be associated with a [transform node](TransformPaintPropertyNode.h)
 which defines the coordinate space in which the content should be painted.
 
 Each transform node has:
 
 * a 4x4 [`TransformationMatrix`](../../transforms/TransformationMatrix.h)
 * a 3-dimensional transform origin, which defines the origin relative to which
   the transformation matrix should be applied (e.g. a rotation applied with some
   transform origin will rotate the plane about that point)
 * a pointer to the parent node, which defines the coordinate space relative to
   which the above should be interpreted
@@ skipping 17 matching lines @@
 ***
 
 Note that, even though CSS does not permit it in the DOM, the transform tree can
 have nodes whose children do not flatten their inherited transform and
 participate in no 3D rendering context. For example, not flattening is necessary
 to preserve the 3D character of the perspective transform, but this does not
 imply any 3D sorting.
 
 ### Clips
 
-Each paint chunk is associated with a [clip node](ClipPaintPropertyNode.h),
+Paint chunks can be associated with a [clip node](ClipPaintPropertyNode.h)
 which defines the raster region that will be applied on the canvas when
 the chunk is rastered.
 
 Each clip node has:
 
 * A float rect with (optionally) rounded corner radius.
 * An associated transform node, which the clip rect is based on.
 
 The raster region defined by a node is the rounded rect transformed to the
 root space, intersects with the raster region defined by its parent clip node
 (if not root).
 
 ### Scrolling
 
-Each paint chunk is associated with a [scroll node](ScrollPaintPropertyNode.h)
+Paint chunks can be associated with a [scroll node](ScrollPaintPropertyNode.h)
 which defines information about how a subtree scrolls so threads other than the
 main thread can perform scrolling. Scroll information includes:
 
 * Which directions, if any, are scrollable by the user.
 * A reference to a [transform node](TransformPaintPropertyNode.h) which contains
 a 2d scroll offset.
 * The extent that can be scrolled. For example, an overflow clip of size 7x9
 with scrolling contents of size 7x13 can scroll 4px vertically and none
 horizontally.
 
 To ensure geometry operations are simple and only deal with transforms, the
 scroll offset is stored as a 2d transform in the transform tree.
 
 ### Effects
 
-Each paint chunk is associated with an [effect node](EffectPaintPropertyNode.h),
+Paint chunks can be associated with an [effect node](EffectPaintPropertyNode.h)
 which defines the effect (opacity, transfer mode, filter, mask, etc.) that
 should be applied to the content before or as it is composited into the content
 below.
 
 Each effect node has:
 
 * a floating-point opacity (from 0 to 1, inclusive)
 * a pointer to the parent node, which will be applied to the result of this
   effect before or as it is composited into its parent in the effect tree
 
@@ skipping 140 matching lines @@
 visual and transformed rects of display items in the coordinate space of ancestor
 [`GeometryPropertyTreeState`](GeometryPropertyTreeState.h)s.
 
 The transformed rect of a display item in an ancestor `GeometryPropertyTreeState`
 is that rect, multiplied by the transforms between the display item's
 `GeometryPropertyTreeState` and the ancestors, then flattened into 2D.
 
 The visual rect of a display item in an ancestor `GeometryPropertyTreeState` is
 the intersection of all of the intermediate clips (transformed in to the
 ancestor state), with the display item's transformed rect.