OLD | NEW |
1 # Platform paint code | 1 # Platform paint code |
2 | 2 |
3 This directory contains the implementation of display lists and display | 3 This directory contains the implementation of display lists and display |
4 list-based painting, except for code which requires knowledge of `core/` | 4 list-based painting, except for code which requires knowledge of `core/` |
5 concepts, such as DOM elements and layout objects. | 5 concepts, such as DOM elements and layout objects. |
6 | 6 |
7 This code is owned by the [paint team][paint-team-site]. | 7 This code is owned by the [paint team][paint-team-site]. |
8 | 8 |
9 Slimming Paint v2 is currently being implemented. Unlike Slimming Paint v1, SPv2 | 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 | 10 represents its paint artifact not as a flat display list, but as a list of |
(...skipping 161 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
172 `CachedDisplayItem` objects), and *new* display items and paint chunks, which | 172 `CachedDisplayItem` objects), and *new* display items and paint chunks, which |
173 are added as content is painted. | 173 are added as content is painted. |
174 | 174 |
175 When the new display items have been populated, clients call | 175 When the new display items have been populated, clients call |
176 `commitNewDisplayItems`, which merges the previous artifact with the new data, | 176 `commitNewDisplayItems`, which merges the previous artifact with the new data, |
177 producing a new paint artifact, where `CachedDisplayItem` objects have been | 177 producing a new paint artifact, where `CachedDisplayItem` objects have been |
178 replaced with the cached content from the previous artifact. | 178 replaced with the cached content from the previous artifact. |
179 | 179 |
180 At this point, the paint artifact is ready to be drawn or composited. | 180 At this point, the paint artifact is ready to be drawn or composited. |
181 | 181 |
182 *** aside | 182 ### Paint result caching and invalidation |
183 TODO(jbroman): Explain invalidation. | 183 |
184 *** | 184 See [Display item caching](../../../core/paint/README.md#paint-result-caching) |
| 185 and [Paint invalidation](../../../core/paint/README.md#paint-invalidation) for |
| 186 more details about how caching and invalidation are handled in blink core |
| 187 module using `PaintController` API. |
| 188 |
| 189 We use 'cache generation' which is a unique id of cache status in each |
| 190 `DisplayItemClient` and `PaintController` to determine if the client is validly |
| 191 cached by a `PaintController`. |
| 192 |
| 193 A paint controller sets its cache generation to |
| 194 `DisplayItemCacheGeneration::next()` at the end of each |
| 195 `commitNewDisplayItems()`, and updates the cache generation of each client with |
| 196 cached drawings by calling `DisplayItemClient::setDisplayItemsCached()`. |
| 197 A display item is treated as validly cached in a paint controller if its cache |
| 198 generation matches the paint controller's cache generation. |
| 199 |
| 200 `kInvalidCacheGeneration` is a special cache generation value which matches no |
| 201 other cache generations. When a `DisplayItemClient` is invalidated, we set its |
| 202 cache generation to `kInvalidCacheGeneration`. When a `PaintController` is |
| 203 cleared (e.g. when the corresponding `GraphicsLayer` is fully invalidated), we |
| 204 also set its cache generation to `kInvalidCacheGeneration`. |
| 205 |
| 206 For now we use a uint32_t variable to store cache generation. Assuming there is |
| 207 an animation in 60fps needing main-thread repaint, the cache generation will |
| 208 overflow after 2^32/86400/60 = 828 days. The time may be shorter if there are |
| 209 multiple animating `PaintController`s in the same process. When it overflows, |
| 210 we may treat some object that is not cached as cached if the following |
| 211 conditions are all met: |
| 212 * the object was painted when the cache generation was *n*; |
| 213 * the object has been neither painted nor invalidated since cache generation |
| 214 *n*; |
| 215 * when the cache generation wraps back to exact *n*, the object happens to be |
| 216 painted again. |
| 217 As the paint controller doesn't have cached display items for the object, there |
| 218 will be corrupted painting or assertion failure. The chance is too low to be |
| 219 concerned. |
| 220 |
| 221 SPv1 only: If a display item is painted on multiple paint controllers, because |
| 222 cache generations are unique, the client's cache generation matches the last |
| 223 paint controller only. The client will be treated as invalid on other paint |
| 224 controllers regardless if it's validly cached by these paint controllers. |
| 225 The situation is very rare (about 0.07% clients were painted on multiple paint |
| 226 controllers in a [Cluster Telemetry run](https://ct.skia.org/chromium_perf_runs) |
| 227 (run 803) so the performance penalty is trivial. |
185 | 228 |
186 ## Paint artifact compositor | 229 ## Paint artifact compositor |
187 | 230 |
188 The [`PaintArtifactCompositor`](PaintArtifactCompositor.h) is responsible for | 231 The [`PaintArtifactCompositor`](PaintArtifactCompositor.h) is responsible for |
189 consuming the `PaintArtifact` produced by the `PaintController`, and converting | 232 consuming the `PaintArtifact` produced by the `PaintController`, and converting |
190 it into a form suitable for the compositor to consume. | 233 it into a form suitable for the compositor to consume. |
191 | 234 |
192 At present, `PaintArtifactCompositor` creates a cc layer tree, with one layer | 235 At present, `PaintArtifactCompositor` creates a cc layer tree, with one layer |
193 for each paint chunk. In the future, it is expected that we will use heuristics | 236 for each paint chunk. In the future, it is expected that we will use heuristics |
194 to combine paint chunks into a smaller number of layers. | 237 to combine paint chunks into a smaller number of layers. |
195 | 238 |
196 The owner of the `PaintArtifactCompositor` (e.g. `WebView`) can then attach its | 239 The owner of the `PaintArtifactCompositor` (e.g. `WebView`) can then attach its |
197 root layer to the overall layer hierarchy to be displayed to the user. | 240 root layer to the overall layer hierarchy to be displayed to the user. |
OLD | NEW |