Google Git
Sign in
chromium / chromium / src / 1abd795c0c483228c7cf69f2cbfae24d30c8626e / . / third_party / blink / renderer / core / paint / ng
tree: cec0328f261ddba31e2835f8aa14c05eb61a14b9 [path history] [tgz]
  1. ng_block_flow_painter.cc
  2. ng_block_flow_painter.h
  3. ng_box_fragment_painter.cc
  4. ng_box_fragment_painter.h
  5. ng_fieldset_painter.cc
  6. ng_fieldset_painter.h
  7. ng_fragment_painter.cc
  8. ng_fragment_painter.h
  9. ng_inline_box_fragment_painter.cc
  10. ng_inline_box_fragment_painter.h
  11. ng_paint_fragment.cc
  12. ng_paint_fragment.h
  13. ng_paint_fragment_test.cc
  14. ng_paint_fragment_traversal.cc
  15. ng_paint_fragment_traversal.h
  16. ng_paint_fragment_traversal_test.cc
  17. ng_text_fragment_painter.cc
  18. ng_text_fragment_painter.h
  19. ng_text_fragment_painter_test.cc
  20. ng_text_painter.cc
  21. ng_text_painter.h
  22. README.md
third_party/blink/renderer/core/paint/ng/README.md

LayoutNG Paint

This directory contains the paint system to work with the Blink's new layout engine LayoutNG.

This README can be viewed in formatted form here.

NGPaintFragment

LayoutNG produces a tree of NGPhysicalFragment.

One of its goals is to share a sub-tree of NGPhysicalFragment across frames, or even within a frame where possible. This goal enforces a few characteristics:

  • It must be immutable.
  • It must be relative within the sub-tree, ideally only to its parent.

A NGPaintFragment owns a NGPhysicalFragment by scoped_refptr in n:1 relation. For instance, NGPhysicalFragment can be shared across frames, but different NGPaintFragment instance can be created for each frame.

It has following characteristics when compared to NGPhysicalFragment:

  • It can have mutable fields, such as VisualRect().
  • It can use its own coordinate system.
  • Separate instances can be created when NGPhysicalFragment is shared.
  • It can have its own tree structure, differently from NGPhysicalFragment tree.

The tree structure

In short, one can think that the NGPaintFragment tree structure is exactly the same as the NGPhysicalFragment tree structure.

LayoutNG will be launched in phases. In the phase 1 implementation, only boxes with inline children are painted directly from fragments, and NGPaintFragment is generated only for this case. For other cases, LayoutNG copies the layout output to the LayoutObject tree and uses the existing paint system.

If LayoutBlockFlow::PaintFragment() exists, it‘s a root of a NGPaintFragment tree. It also means, in the current phase, it’s a box that contains only inline children.

Note that not all boxes with inline children can be laid out by LayoutNG today, so the reverse is not true.

Multiple NGPaintFragment tree

Because not all boxes are painted by the fragment painter, and even not all boxes are handled by LayoutNG, one LayoutObject tree can generate multiple NGPaintFragment trees.

For example, if a block contains an inline block that is not handled by LayoutNG, an NGPaintFragment tree is created with the inline block as a leaf child, even though the inline block LayoutObject has children.

If the inline block has another inline block which LayoutNG can handle, another NGPaintFragment tree is created for the inner inline block.