Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # `Source/core/paint` | |
| 2 | |
| 3 This directory contains implementation of painters of layout objects. | |
| 4 | |
| 5 ## Painters | |
| 6 | |
| 7 ## Paint invalidation | |
| 8 | |
| 9 Paint invalidation marks anything that need to be painted differently from the o riginal | |
| 10 cached painting. | |
| 11 | |
| 12 ### Slimming paint v1 | |
| 13 | |
| 14 Though described in this document, most of the actual paint invalidation code is under | |
| 15 `Source/core/layout`. | |
| 16 | |
| 17 Paint invalidation is a document cycle stage after compositing update and before paint. | |
| 18 During the previous stages, objects are marked for needing paint invalidation ch ecking | |
| 19 if needed by style change, layout change, compositing change, etc. In paint inva lidation stage, | |
| 20 we traverse the layout tree for marked subtrees and objects and send the followi ng information | |
| 21 to `GraphicsLayer`s and `PaintController`s: | |
| 22 | |
| 23 * paint invalidation rects: must cover all areas that will generete different pixels. | |
| 24 * invalidated display item clients: must invalidate all display item clients t hat will | |
| 25 generate different display items. | |
| 26 | |
| 27 ### Paint invalidation of texts | |
| 28 | |
| 29 Texts are painted by `InlineTextBoxPainter` using `InlineTextBox` as display ite m client. | |
| 30 Text backgrounds and masks are painted by `InlineTextFlowPainter` using `InlineF lowBox` | |
| 31 as display item client. We should invalidate these display item clients when the ir painting | |
| 32 will change. | |
| 33 | |
| 34 `LayoutInline`s and `LayoutText`s are marked for full paint invalidation if need ed when | |
| 35 the style is set on them. During paint invalidation, we invalidate the `InlineFl owBox`s | |
| 36 directly contained by the `LayoutInline` in `LayoutInline::invalidateDisplayItem Clients()` and | |
| 37 `InlineTextBox`s contained by the `LayoutText` in `LayoutText::invalidateDisplay ItemClients()`. | |
| 38 We don't need to traverse into the subtree of `InlineFlowBox`s in `LayoutInline: :invalidateDisplayItemClients()` | |
| 39 because the descendant `InlineFlowBox`s and `InlineTextBox`s will be handled by their | |
| 40 owing `LayoutInline`s and `LayoutText`s, respectively. | |
|
chrishtr
2015/12/07 18:06:04
Nit: "owning"
Xianzhu
2015/12/07 20:42:48
Done.
| |
| 41 | |
| 42 ### Specialty of `::first-line` | |
| 43 | |
| 44 `::first-line` pseudo style dynamically applies to all `InlineBox`'s in the firs t line in the | |
| 45 block having `::first-line` style. The actual applied style is computed from the `::first-line` | |
| 46 style and other applicable styles. | |
| 47 | |
| 48 If the first line contains any `LayoutInline`, we compute the style from the `:: first-line` style | |
| 49 and the style of the `LayoutInline` and apply the computed style to the first li ne part of the | |
| 50 `LayoutInline`. In blink's style implementation, the combined first line style o f `LayoutInline` | |
| 51 is identified with `FIRST_LINE_INHERITED` pseudo ID. | |
| 52 | |
| 53 The normal paint invalidation of texts doesn't work for first line because | |
| 54 * `ComputedStyle::visualInvalidationDiff()` can't detect first line style chan ges; | |
| 55 * The normal paint invalidation is based on whole LayoutObject's, not aware of the first line. | |
| 56 | |
| 57 We have a special path for first line style change: the style system informs the layout system | |
| 58 when the computed first-line style changes through `LayoutObject::firstLineStyle DidChange()`. | |
| 59 When this happens, we invalidate all `InlineBox`es in the first line. | |
| 60 | |
| 61 ### Slimming paint v2 | |
| 62 | |
| 63 TODO(wangxianzhu): add details | |
| OLD | NEW |