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 fully |
| 77 implemented. |
| 78 *** |
| 79 |
| 80 Other cached display items refer to a single `DrawingDisplayItem` with a |
| 81 corresponding type which should be reused in place of this `CachedDisplayItem`. |
| 82 |
| 83 #### [DrawingDisplayItem](DrawingDisplayItem.h) |
| 84 |
| 85 Holds an `SkPicture` which contains the Skia commands required to draw some atom |
| 86 of content. |
| 87 |
| 88 ### Paired begin/end display items |
| 89 |
| 90 *** aside |
| 91 TODO(jbroman): Describe how these work, once we've worked out what happens to |
| 92 them in SPv2. |
| 93 *** |
| 94 |
| 95 ## Display item list |
| 96 |
| 97 Callers use `GraphicsContext` (via its drawing methods, and its |
| 98 `displayItemList()` accessor) and scoped recorder classes, which emit items into |
| 99 a `DisplayItemList`. |
| 100 |
| 101 `DisplayItemList` is responsible for producing the paint artifact. It contains |
| 102 the *current* paint artifact, which is always complete (i.e. it has no |
| 103 `CachedDisplayItem` objects), and *new* display items and paint chunks, which |
| 104 are added as content is painted. |
| 105 |
| 106 When the new display items have been populated, clients call |
| 107 `commitNewDisplayItems`, which merges the previous artifact with the new data, |
| 108 producing a new paint artifact, where `CachedDisplayItem` objects have been |
| 109 replaced with the cached content from the previous artifact. |
| 110 |
| 111 At this point, the paint artifact is ready to be drawn or composited. |
| 112 |
| 113 *** aside |
| 114 TODO(jbroman): Explain invalidation. |
| 115 *** |
OLD | NEW |