1# LayoutNG Paint # 2 3This directory contains the paint system to work with 4the Blink's new layout engine [LayoutNG]. 5 6This README can be viewed in formatted form 7[here](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/paint/ng/README.md). 8 9## NGPaintFragment ## 10 11LayoutNG produces a tree of [NGPhysicalFragment]. 12 13One of its goals is to share a sub-tree of NGPhysicalFragment across frames, 14or even within a frame where possible. 15This goal enforces a few characteristics: 16 17* It must be immutable. 18* It must be relative within the sub-tree, ideally only to its parent. 19 20A [NGPaintFragment] owns a NGPhysicalFragment by `scoped_refptr` in n:1 relation. 21For instance, NGPhysicalFragment can be shared across frames, 22but different NGPaintFragment instance can be created for each frame. 23 24It has following characteristics when compared to NGPhysicalFragment: 25 26* It can have mutable fields, such as `VisualRect()`. 27* It can use its own coordinate system. 28* Separate instances can be created when NGPhysicalFragment is shared. 29* It can have its own tree structure, differently from NGPhysicalFragment tree. 30 31### The tree structure ### 32 33In short, one can think that the NGPaintFragment tree structure is 34exactly the same as the NGPhysicalFragment tree structure. 35 36LayoutNG will be launched in phases. In the phase 1 implementation, 37only boxes with inline children are painted directly from fragments, and 38NGPaintFragment is generated only for this case. 39For other cases, LayoutNG copies the layout output to the LayoutObject tree 40and uses the existing paint system. 41 42If `LayoutBlockFlow::PaintFragment()` exists, 43it's a root of a NGPaintFragment tree. 44It also means, in the current phase, it's a box that contains only inline children. 45 46Note that not all boxes with inline children can be laid out by LayoutNG today, 47so the reverse is not true. 48 49### Multiple NGPaintFragment tree ### 50 51Because not all boxes are painted by the fragment painter, 52and even not all boxes are handled by LayoutNG, 53one LayoutObject tree can generate multiple NGPaintFragment trees. 54 55For example, if a block contains an inline block that is not handled by LayoutNG, 56an NGPaintFragment tree is created with the inline block as a leaf child, 57even though the inline block LayoutObject has children. 58 59If the inline block has another inline block which LayoutNG can handle, 60another NGPaintFragment tree is created for the inner inline block. 61 62### NGPhysicalFragment traversal ### 63 64When possible (when sufficiently transitioned to LayoutNG), we'll paint and 65hit-test by traversing the physical fragment tree, rather than traversing the 66LayoutObject tree. This is important for block fragmentation, where a CSS layout 67box (LayoutObject) may be split into multiple fragments, and it's the 68relationship between the fragments (not the layout objects) that determines the 69offsets. In LayoutNG, there are also fragments that have no corresponding layout 70object - e.g. a column (or other types of [fragmentainer]s too). 71 72Traditionally, when doing block fragmentation (multicol) in legacy layout, we 73have to perform some complicated calculations, where we map and slice layout 74objects into fragments during pre-paint. In LayoutNG this job is now as a 75natural part of layout. So, all we have to do for painting and hit-testing, is 76traverse the fragments. A fragment holds a list of child fragments and their 77offsets. The offsets are relative to the parent fragment. As such, it's a rather 78straight-forward job for pre-paint to calculate the offsets and bounding box. 79 80[LayoutNG]: ../../layout/ng/README.md 81[NGPaintFragment]: ng_paint_fragment.h 82[NGPhysicalFragment]: ../../layout/ng/ng_physical_fragment.h 83[fragmentainer]: https://drafts.csswg.org/css-break/#fragmentation-container 84