Rename DisplayItemList to PaintController

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 75 matching lines @@
 In practice, display item clients are generally subclasses of `LayoutObject`,
 but can be other Blink objects which get painted, such as inline boxes and drag
 images.
 
 *** note
 It is illegal for there to be two drawings with the same ID in a display item
 list.
 ***
 
 Generally, clients of this code should use stack-allocated recorder classes to
-emit display items to a `DisplayItemList` (using `GraphicsContext`).
+emit display items to a `PaintController` (using `GraphicsContext`).
 
 ### Standalone display items
 
 #### [CachedDisplayItem](CachedDisplayItem.h)
 
 The type `DisplayItem::CachedSubsequence` indicates that the previous frame's
 display item list contains a contiguous sequence of display items which should
 be reused in place of this `CachedDisplayItem`.
 
 *** note
@@ skipping 12 matching lines @@
 ### Paired begin/end display items
 
 *** aside
 TODO(jbroman): Describe how these work, once we've worked out what happens to
 them in SPv2.
 ***
 
 ## Display item list
 
 Callers use `GraphicsContext` (via its drawing methods, and its
-`displayItemList()` accessor) and scoped recorder classes, which emit items into
-a `DisplayItemList`.
+`paintController()` accessor) and scoped recorder classes, which emit items into
+a `PaintController`.
 
-`DisplayItemList` is responsible for producing the paint artifact. It contains
+`PaintController` is responsible for producing the paint artifact. It contains
 the *current* paint artifact, which is always complete (i.e. it has no
 `CachedDisplayItem` objects), and *new* display items and paint chunks, which
 are added as content is painted.
 
 When the new display items have been populated, clients call
 `commitNewDisplayItems`, which merges the previous artifact with the new data,
 producing a new paint artifact, where `CachedDisplayItem` objects have been
 replaced with the cached content from the previous artifact.
 
 At this point, the paint artifact is ready to be drawn or composited.
 
 *** aside
 TODO(jbroman): Explain invalidation.
 ***