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
+## Glossaries
+
+### Stacked elements 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).
 
+Note: we use 'element' instead of 'object' in this chapter to keep consistency with
+the spec. We use 'object' in other places in this document.
+
 According to the documentation, we can have the following types of elements that are
 treated in different ways during painting:
 
-*   Stacked elements: elements that are z-ordered in stacking contexts.
+*   Stacked objects: objects that are z-ordered in stacking contexts, including:
 
     *   Stacking contexts: elements with non-auto z-indices.
 
     *   Elements that are not real stacking contexts but are treated as stacking
         contexts but don't manage other stacked elements. Their z-ordering are
         managed by real stacking contexts. They are positioned elements with
         `z-index: auto` (E.2.8 in the documentation).
 
         They must be managed by the enclosing stacking context as stacked elements
         because `z-index:auto` and `z-index:0` are considered equal for stacking
@@ skipping 24 matching lines @@
     *   [grid items](http://www.w3.org/TR/css-grid-1/#z-order)
     *   custom scrollbar parts
 
     They are painted by `ObjectPainter::paintAllPhasesAtomically()` which executes
     all of the steps of the painting algorithm explained in the documentation, except
     ignores any descendants which are positioned or have non-auto z-index (which is
     achieved by skipping descendants with self-painting layers).
 
 *   Other normal elements.
 
-## Painters
+### Other glossaries
+
+*   Paint container: the parent of an object for painting, as defined by [CSS2.1 spec
+    for painting]((http://www.w3.org/TR/CSS21/zindex.html)). 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

[chrishtr, 2016/04/01 16:38:13]

Nit: add period.

[Xianzhu, 2016/04/01 17:07:22]

Done.

+
+*   Compositing container: an implementation detail of Blink, which uses
+    `PaintLayer`s 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 chain, but for compositing container.
+
+*   Paint invalidation container: the nearest object on the compositing container
+    chain which is composited.
 
 ## Paint invalidation
 
 Paint invalidation marks anything that need to be painted differently from the original
 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: Since as indicated by the definitions in [Glossaries](#Other glossaries),
+    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></div>
+        </div>
+
+    If the scroller is composited (for high-DPI screens for example), it is the paint invalidation
+    container for div B, but not A.
+
+*   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 objects are determined by their containing blocks, and the containing block
+    for absolute-position objects differs from non-absolute, 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

[chrishtr, 2016/04/01 16:38:13]

Nit: s/fallback/fall back/

[Xianzhu, 2016/04/01 17:07:21]

Done.

+`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

[chrishtr, 2016/04/01 16:38:13]

This one is obsolete in the latest patch set, right?

[Xianzhu, 2016/04/01 17:07:21]

The case before 'or' is still valid. Removed the latter case.

+    `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.