Rename "paint invalidation rect" etc. to "visual rect".

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

 # `Source/core/paint`
 
 This directory contains implementation of painters of layout objects. It covers
 the following document lifecycle states:
 
 *   PaintInvalidation (`InPaintInvalidation` and `PaintInvalidationClean`)
 *   PrePaint (`InPrePaint` and `PrePaintClean`)
 *   Paint (`InPaint` and `PaintClean`)
 
 ## Glossaries
@@ skipping 69 matching lines @@
     `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.
 
+*   Visual rect: the bounding box of all pixels that will be painted by a
+    display item client.
+
 ## 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 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.
+*   invalidated display item clients: must invalidate all display item clients
+    that will generate different display items.
+
+*   paint invalidation rects: must cover all areas that will generate different
+    pixels. They are generated based on visual rects of invalidated display item
+    clients.
 
 #### `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),
@@ skipping 16 matching lines @@
     clipping rects for absolute-position objects separately.
 
 In cases that accurate accumulation of paint offsets and clipping rects is impossible,
 we will fall back 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;
+*   An object has has filter (including filter induced by reflection), which
+    needs to expand visual rect for descendants, because currently we don't
+    include and filter 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
@@ skipping 103 matching lines @@
 
 When layer structure changes, and we are not invalidate paint of the changed subtree,
 we need to manually update the `needsPaintPhaseXXX` flags. For example, if an object changes
 style and creates a self-painting-layer, we copy the flags from its containing self-painting
 layer to this layer, assuming that this layer needs all paint phases that its container
 self-painting layer needs.
 
 We could update the `needsPaintPhaseXXX` flags in a separate tree walk, but that would regress
 performance of the first paint. For slimming paint v2, we can update the flags during the
 pre-painting tree walk to simplify the logics.