Google Git
Sign in
chromium / chromium / src / b9619673 / . / third_party / WebKit / Source / platform / graphics / paint
tree: e8d884d8e98951bcb5be12d89f3da1c6e2b6bf4a [path history] [tgz]
  1. CachedDisplayItem.h
  2. ClipDisplayItem.cpp
  3. ClipDisplayItem.h
  4. ClipPaintPropertyNode.h
  5. ClipPathDisplayItem.cpp
  6. ClipPathDisplayItem.h
  7. ClipPathRecorder.cpp
  8. ClipPathRecorder.h
  9. ClipRecorder.cpp
  10. ClipRecorder.h
  11. CompositingDisplayItem.cpp
  12. CompositingDisplayItem.h
  13. CompositingRecorder.cpp
  14. CompositingRecorder.h
  15. CullRect.cpp
  16. CullRect.h
  17. DisplayItem.cpp
  18. DisplayItem.h
  19. DisplayItemCacheSkipper.h
  20. DisplayItemClient.cpp
  21. DisplayItemClient.h
  22. DisplayItemClientTest.cpp
  23. DisplayItemList.cpp
  24. DisplayItemList.h
  25. DisplayItemListTest.cpp
  26. DisplayItemTest.cpp
  27. DrawingDisplayItem.cpp
  28. DrawingDisplayItem.h
  29. DrawingRecorder.cpp
  30. DrawingRecorder.h
  31. EffectPaintPropertyNode.h
  32. FilterDisplayItem.cpp
  33. FilterDisplayItem.h
  34. FloatClipDisplayItem.cpp
  35. FloatClipDisplayItem.h
  36. ForeignLayerDisplayItem.cpp
  37. ForeignLayerDisplayItem.h
  38. PaintArtifact.cpp
  39. PaintArtifact.h
  40. PaintArtifactToSkCanvas.cpp
  41. PaintArtifactToSkCanvas.h
  42. PaintArtifactToSkCanvasTest.cpp
  43. PaintChunk.h
  44. PaintChunker.cpp
  45. PaintChunker.h
  46. PaintChunkerTest.cpp
  47. PaintChunkProperties.h
  48. PaintController.cpp
  49. PaintController.h
  50. PaintControllerTest.cpp
  51. README.md
  52. ScopedPaintChunkProperties.h
  53. ScrollDisplayItem.cpp
  54. ScrollDisplayItem.h
  55. SkPictureBuilder.cpp
  56. SkPictureBuilder.h
  57. SubsequenceDisplayItem.h
  58. SubsequenceRecorder.cpp
  59. SubsequenceRecorder.h
  60. Transform3DDisplayItem.cpp
  61. Transform3DDisplayItem.h
  62. TransformDisplayItem.cpp
  63. TransformDisplayItem.h
  64. TransformPaintPropertyNode.h
third_party/WebKit/Source/platform/graphics/paint/README.md

Platform paint code

This directory contains the implementation of display lists and display list-based painting, except for code which requires knowledge of core/ concepts, such as DOM elements and layout objects.

This code is owned by the paint team.

Slimming Paint v2 is currently being implemented. Unlike Slimming Paint v1, SPv2 represents its paint artifact not as a flat display list, but as a list of drawings, and a list of paint chunks, stored together.

This document explains the SPv2 world as it develops, not the SPv1 world it replaces.

Paint artifact

The SPv2 paint artifact consists of a list of display items in paint order (ideally mostly or all drawings), partitioned into paint chunks which define certain paint properties which affect how the content should be drawn or composited.

Paint properties

Paint properties define characteristics of how a paint chunk should be drawn, such as the transform it should be drawn with. To enable efficient updates, a chunk's paint properties are described hierarchically. For instance, each chunk is associated with a transform node, whose matrix should be multiplied by its ancestor transform nodes in order to compute the final transformation matrix to the screen.

Support for all paint properties has yet to be implemented in SPv2.
TODO(jbroman): Explain the semantics of transforms, clips, scrolls and effects as support for them is added to SPv2.

Transforms

Each paint chunk is associated with a transform node, which defines the coordinate space in which the content should be painted.

Each transform node has:

  • a 4x4 TransformationMatrix
  • a 3-dimensional transform origin, which defines the origin relative to which the transformation matrix should be applied (e.g. a rotation applied with some transform origin will rotate the plane about that point)
  • a pointer to the parent node, which defines the coordinate space relative to which the above should be interpreted

The parent node pointers link the transform nodes in a hierarchy (the transform tree), which defines how the transform for any painted content can be determined.

The painting system may create transform nodes which don't affect the position of points in the xy-plane, but which have an apparent effect only when multiplied with other transformation matrices. In particular, a transform node may be created to establish a perspective matrix for descendant transforms in order to create the illusion of depth.
TODO(jbroman): Explain flattening, etc., once it exists in the paint properties.

Clips

Each paint chunk is associated with a clip node, which defines the raster region that will be applied on the canvas when the chunk is rastered.

Each clip node has:

  • A float rect with (optionally) rounded corner radius.
  • An associated transform node, which the clip rect is based on.

The raster region defined by a node is the rounded rect transformed to the root space, intersects with the raster region defined by its parent clip node (if not root).

Effects

Each paint chunk is associated with an effect node, which defines the effect (opacity, transfer mode, filter, mask, etc.) that should be applied to the content before or as it is composited into the content below.

Each effect node has:

  • a floating-point opacity (from 0 to 1, inclusive)
  • a pointer to the parent node, which will be applied to the result of this effect before or as it is composited into its parent in the effect tree

The paret node pointers link the effect nodes in a hierarchy (the effect tree), which defines the dependencies between rasterization of different contents.

One can imagine each effect node as corresponding roughly to a bitmap that is drawn before being composited into another bitmap, though for implementation reasons this may not be how it is actually implemented.

TODO(jbroman): Explain the connection with the transform and clip trees, once it exists, as well as effects other than opacity.

Display items

A display item is the smallest unit of a display list in Blink. Each display item is identified by an ID consisting of:

  • an opaque pointer to the display item client that produced it
  • a type (from the DisplayItem::Type enum)
  • a scope number
TODO(jbroman): Explain scope numbers.

In practice, display item clients are generally subclasses of LayoutObject, but can be other Blink objects which get painted, such as inline boxes and drag images.

It is illegal for there to be two drawings with the same ID in a display item list.

Generally, clients of this code should use stack-allocated recorder classes to emit display items to a PaintController (using GraphicsContext).

Standalone display items

CachedDisplayItem

See Display item caching.

DrawingDisplayItem

Holds an SkPicture which contains the Skia commands required to draw some atom of content.

ForeignLayerDisplayItem

Draws an atom of content, but using a cc::Layer produced by some agent outside of the normal Blink paint system (for example, a plugin). Since they always map to a cc::Layer, they are always the only display item in their paint chunk, and are ineligible for squashing with other layers.

Paired begin/end display items

TODO(jbroman): Describe how these work, once we've worked out what happens to them in SPv2.

Paint controller

Callers use GraphicsContext (via its drawing methods, and its paintController() accessor) and scoped recorder classes, which emit items into a PaintController.

PaintController is responsible for producing the paint artifact. It contains the current paint artifact, which is always complete (i.e. it has no CachedDisplayItem objects), and new display items and paint chunks, which are added as content is painted.

When the new display items have been populated, clients call commitNewDisplayItems, which merges the previous artifact with the new data, producing a new paint artifact, where CachedDisplayItem objects have been replaced with the cached content from the previous artifact.

At this point, the paint artifact is ready to be drawn or composited.

TODO(jbroman): Explain invalidation.

Paint artifact compositor

The PaintArtifactCompositor is responsible for consuming the PaintArtifact produced by the PaintController, and converting it into a form suitable for the compositor to consume.

At present, PaintArtifactCompositor creates a cc layer tree, with one layer for each paint chunk. In the future, it is expected that we will use heuristics to combine paint chunks into a smaller number of layers.

The owner of the PaintArtifactCompositor (e.g. WebView) can then attach its root layer to the overall layer hierarchy to be displayed to the user.