Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # Platform paint code | |
| 2 | |
| 3 This directory contains the implementation of display lists and display | |
| 4 list-based painting, except for code which requires knowledge of `core/` | |
| 5 concepts, such as DOM elements and layout objects. | |
| 6 | |
| 7 This code is owned by the [paint team][paint-team-site]. | |
| 8 | |
| 9 Slimming Paint v2 is currently being implemented. Unlike Slimming Paint v1, SPv2 | |
| 10 represents its paint artifact not as a flat display list, but as a list of | |
| 11 drawings, and a list of paint chunks, stored together. | |
| 12 | |
| 13 This document explains the SPv2 world as it develops, not the SPv1 world it | |
| 14 replaces. | |
| 15 | |
| 16 [paint-team-site]: https://www.chromium.org/developers/paint-team | |
| 17 | |
| 18 ## Paint artifact | |
| 19 | |
| 20 The SPv2 paint artifact consists of a list of display items (ideally mostly or | |
| 21 all drawings), partitioned into *paint chunks* which define certain *paint | |
| 22 properties* which affect how the content should be drawn or composited. | |
| 23 | |
| 24 ## Paint properties | |
| 25 | |
| 26 Paint properties define characteristics of how a paint chunk should be drawn, | |
| 27 such as the transform it should be drawn with. To enable efficient updates, | |
| 28 a chunk's paint properties are described hierarchically. For instance, each | |
| 29 chunk is associated with a transform node, whose matrix should be multiplied by | |
| 30 its ancestor transform nodes in order to compute the final transformation matrix | |
| 31 to the screen. | |
| 32 | |
| 33 *** note | |
| 34 Support for all paint properties has yet to be implemented in SPv2. | |
| 35 *** | |
| 36 | |
| 37 *** aside | |
| 38 TODO(jbroman): Explain the semantics of transforms, clips, scrolls and effects | |
| 39 as support for them is added to SPv2. | |
| 40 *** | |
| 41 | |
| 42 ## Display items | |
| 43 | |
| 44 A display item is the smallest unit of a display list in Blink. Each display | |
| 45 item is identified by an ID consisting of: | |
| 46 | |
| 47 * an opaque pointer to the *display item client* that produced it | |
| 48 * a type (from the `DisplayItem::Type` enum) | |
| 49 * a scope number | |
| 50 | |
| 51 *** aside | |
| 52 TODO(jbroman): Explain scope numbers. | |
| 53 *** | |
| 54 | |
| 55 In practice, display item clients are generally subclasses of `LayoutObject`, | |
| 56 but can be other Blink objects which get painted, such as inline boxes and drag | |
| 57 images. | |
| 58 | |
| 59 *** note | |
| 60 It is illegal for there to be two drawings with the same ID in a display item | |
| 61 list. | |
| 62 *** | |
| 63 | |
| 64 Generally, clients of this code should use stack-allocated recorder classes to | |
| 65 emit display items to a `DisplayItemList` (using `GraphicsContext`). | |
| 66 | |
| 67 ### Standalone display items | |
| 68 | |
| 69 #### [CachedDisplayItem](CachedDisplayItem.h) | |
| 70 | |
| 71 The type `DisplayItem::CachedSubsequence` indicates that the previous frame's | |
| 72 display item list contains a contiguous sequence of display items which should | |
| 73 be reused in place of this `CachedDisplayItem`. | |
| 74 | |
| 75 *** note | |
| 76 Support for cached subsequences for SPv2 is planned, but not yet implemented. | |
|
chrishtr
2015/10/01 18:49:38
It is already partially implemented.
| |
| 77 *** | |
| 78 | |
| 79 Other cached display items refer to a single `DrawingDisplayItem` with a | |
| 80 corresponding type which should be reused in place of this `CachedDisplayItem`. | |
| 81 | |
| 82 #### [DrawingDisplayItem](DrawingDisplayItem.h) | |
| 83 | |
| 84 Holds an `SkPicture` which contains the Skia commands required to draw some atom | |
| 85 of content. | |
| 86 | |
| 87 ### Paired begin/end display items | |
| 88 | |
| 89 *** aside | |
| 90 TODO(jbroman): Describe how these work, once we've worked out what happens to | |
| 91 them in SPv2. | |
| 92 *** | |
| 93 | |
| 94 ## Display item list | |
| 95 | |
| 96 Callers use `GraphicsContext` (via its drawing methods, and its | |
| 97 `displayItemList()` accessor) and scoped recorder classes, which emit items into | |
| 98 a `DisplayItemList`. | |
| 99 | |
| 100 `DisplayItemList` is responsible for producing the paint artifact. It contains | |
| 101 the *current* paint artifact, which is always complete (i.e. it has no | |
| 102 `CachedDisplayItem` objects), and *new* display items and paint chunks, which | |
| 103 are added as content is painted. | |
| 104 | |
| 105 When the new display items have been populated, clients call | |
| 106 `commitNewDisplayItems`, which merges the previous artifact with the new data, | |
| 107 producing a new paint artifact, where `CachedDisplayItem` objects have been | |
| 108 replaced with the cached content from the previous artifact. | |
| 109 | |
| 110 At this point, the paint artifact is ready to be drawn or composited. | |
| 111 | |
| 112 *** aside | |
| 113 TODO(jbroman): Explain invalidation. | |
| 114 *** | |
| OLD | NEW |