Remove ForceHorriblySlowRectMapping

third_party/WebKit/Source/core/paint/README.md

 # `Source/core/paint`
 
 This directory contains implementation of painters of layout objects.
 
 ## Stacked contents and stacking contexts
 
 This chapter is basically a clarification of [CSS 2.1 appendix E. Elaborate description
 of Stacking Contexts](http://www.w3.org/TR/CSS21/zindex.html).
 
 According to the documentation, we can have the following types of elements that are
@@ skipping 52 matching lines @@
 cached painting.
 
 ### Slimming paint v1
 
 Though described in this document, most of the actual paint invalidation code is under
 `Source/core/layout`.
 
 Paint invalidation is a document cycle stage after compositing update and before paint.
 During the previous stages, objects are marked for needing paint invalidation checking
 if needed by style change, layout change, compositing change, etc. In paint invalidation stage,
-we traverse the layout tree for marked subtrees and objects and send the following information
-to `GraphicsLayer`s and `PaintController`s:
+we traverse the layout tree in pre-order, crossing frame boundaries, for marked subtrees
+and objects and send the following information to `GraphicsLayer`s and `PaintController`s:
 
 *   paint invalidation rects: must cover all areas that will generete different pixels.
 *   invalidated display item clients: must invalidate all display item clients that will
     generate different display items.
 
+#### `PaintInvalidationState`
+
+`PaintInvalidationState` is an optimization used during the paint invalidation phase. Before
+the paint invalidation tree walk, a root `PaintInvalidationState` is created for the root
+`LayoutView`. During the tree walk, one `PaintInvalidationState` is created for each visited
+object based on the `PaintInvalidationState` passed from the parent object.
+It tracks the following information to provide O(1) complexity access to them if possible:
+
+*   Paint invalidation container: an ancestor (crossing frame boundaries) of the current object

[chrishtr, 2016/03/31 21:54:59]

"stacked object": positioned objects, non-auto-z-index-objects, and objects
creating stacking contexts. This is represented in the code by
ComputedStyle::isStacked().

"Paint container": the parent of an object for painting, as defined by <link to
css2.1 spec for painting>. For regular objects, this is the parent in the DOM.
For stacked objects, it's the containing stacking context-inducing object.

"paint container chain": the chain of paint ancestors between an element and the
root of the page

"compositing container": an implementation detail of Blink, which uses
PaintLayers to represent some layout objects. It is the ancestor along the paint
ancestor chain which has a PaintLayer. Implemented in
PaintLayer::compositingContainer(). Think of it as skipping intermediate normal
objects and going directly to the containing stacked object.

"compositing container chain": same as paint invalidation chain, but for
compositing container.

"Paint invalidation container": the nearest object on the compositing container
chain which is composited.

[Xianzhu, 2016/04/01 16:07:56]

Done. We already have a whole chapter for "stacked object" in the documentation.

+    which can handle paint invalidation of the current object. `PaintInvalidationState` must track
+    two paint invalidation containers for stacked contents and normal flow contents separately:

[chrishtr, 2016/03/31 21:54:59]

Add:

Since as indicated by the definitions above, the paint invalidation container
for stacked objects can differ from normal objects, we have to track both
separately. Here is an example:

<div style="overflow: scroll">
  <div id=A style="position: absolute"></div>
  <div id=B style="position: absolute"></div>
</div>

If the scroller is composited (for high-DPI screens for example), it is the
paint invalidation container for div B, but not for A.

[trchen, 2016/03/31 22:00:38]

It this example correct? It looks to me both A and B will paint into the root
layer, or potentially get composited for overlap reason.

[chrishtr, 2016/03/31 22:06:05]

Sorry, forgot to remove position:absolute on B.

[Xianzhu, 2016/04/01 16:07:56]

Done.

+
+    *   Paint invalidation container of a stacked object (and its normal flow contents) is the
+        nearest ancestor composited object which establishes a stacking context.
+
+    *   Paint invalidation container of a normal flow object is the nearest composited ancestor.
+
+*   Paint offset and clip rect: if possible, `PaintInvalidationState` accumulates paint offsets
+    and overflow clipping rects from the paint invalidation container to provide O(1) complexity to
+    map a point or a rect in current object's local space to paint invalidation container's space.
+    Because locations of absolute-position objects are determined by their containing blocks,

[chrishtr, 2016/03/31 21:54:59]

"Because locations of objects are determined by their containing blocks, and the
containing block for absolute-position elements differs from non-absolute, ..."

[Xianzhu, 2016/04/01 16:07:56]

Done.

+    we track paint offsets and overflow clipping rects for absolute-position objects separately.
+
+In cases that accurate accumulation of paint offsets and clipping rects is impossible,
+we will fallback to slow-path using `LayoutObject::localToAncestorPoint()` or
+`LayoutObject::mapToVisualRectInAncestorSpace()`. This includes the following cases:
+
+*   An object has transform related property, is multi-column or has flipped blocks writing-mode,
+    causing we can't simply accumulate paint offset for mapping a local rect to paint invalidation
+    container;
+
+*   An object has has filter or reflection, which needs to expand paint invalidation rect
+    for descendants, because currently we don't include and reflection extents into visual overflow;
+
+*   For a fixed-position object we calculate its offset using `LayoutObject::localToAncestorPoint()`,
+    but map for its descendants in fast-path if no other things prevent us from doing this;
+
+*   Because we track paint offset from the normal paint invalidation container only, if we are going
+    to use `m_paintInvalidationContainerForStackedContents` and it's different from the normal paint
+    invalidation container, we have to force slow-path because the accumulated paint offset is not
+    usable;
+
+*   We also stop to track paint offset and clipping rect for absolute-position objects when
+    `m_paintInvalidationContainerForStackedContents` becomes different from `m_paintInvalidationContainer`,
+    or absolute-position descendants' offsets will be determined by something (e.g. their containing
+    block) above the paint invalidation container.
+
 ### Paint invalidation of texts
 
 Texts are painted by `InlineTextBoxPainter` using `InlineTextBox` as display item client.
 Text backgrounds and masks are painted by `InlineTextFlowPainter` using `InlineFlowBox`
 as display item client. We should invalidate these display item clients when their painting
 will change.
 
 `LayoutInline`s and `LayoutText`s are marked for full paint invalidation if needed when
 new style is set on them. During paint invalidation, we invalidate the `InlineFlowBox`s
 directly contained by the `LayoutInline` in `LayoutInline::invalidateDisplayItemClients()` and
@@ skipping 46 matching lines @@
 In a subsequence paint, if the layer would generate exactly the same display items, we'll simply
 output a `CachedSubsequence` display item in place of the display items, and skip all paintings
 of the layer and its descendants in painting order. After painting, `PaintController` will
 replace `CacheSubsequence` with cached display items created in previous paintings.
 
 There are many conditions affecting
 *   whether we need to generate subsequence for a PaintLayer;
 *   whether we can use cached subsequence for a PaintLayer.
 See `shouldCreateSubsequence()` and `shouldRepaintSubsequence()` in `PaintLayerPainter.cpp` for
 the conditions.