Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(610)

Side by Side Diff: third_party/WebKit/Source/platform/graphics/paint/README.md

Issue 1379883003: Create PaintChunk and begin writing code to build paint chunks. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: enable RuntimeEnabledFeature for PaintChunkerTest Created 5 years, 2 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(Empty)
1 # Platform paint code
2
3 This directory contains the implementation of display lists and display
4 list-based painting, except for code which requires knowledge of `core/`
5 concepts, such as DOM elements and layout objects.
6
7 This code is owned by the [paint team][paint-team-site].
8
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
11 drawings, and a list of paint chunks, stored together.
12
13 This document explains the SPv2 world as it develops, not the SPv1 world it
14 replaces.
15
16 [paint-team-site]: https://www.chromium.org/developers/paint-team
17
18 ## Paint artifact
19
20 The SPv2 paint artifact consists of a list of display items (ideally mostly or
21 all drawings), partitioned into *paint chunks* which define certain *paint
22 properties* which affect how the content should be drawn or composited.
23
24 ## Paint properties
25
26 Paint properties define characteristics of how a paint chunk should be drawn,
27 such as the transform it should be drawn with. To enable efficient updates,
28 a chunk's paint properties are described hierarchically. For instance, each
29 chunk is associated with a transform node, whose matrix should be multiplied by
30 its ancestor transform nodes in order to compute the final transformation matrix
31 to the screen.
32
33 *** note
34 Support for all paint properties has yet to be implemented in SPv2.
35 ***
36
37 *** aside
38 TODO(jbroman): Explain the semantics of transforms, clips, scrolls and effects
39 as support for them is added to SPv2.
40 ***
41
42 ## Display items
43
44 A display item is the smallest unit of a display list in Blink. Each display
45 item is identified by an ID consisting of:
46
47 * an opaque pointer to the *display item client* that produced it
48 * a type (from the `DisplayItem::Type` enum)
49 * a scope number
50
51 *** aside
52 TODO(jbroman): Explain scope numbers.
53 ***
54
55 In practice, display item clients are generally subclasses of `LayoutObject`,
56 but can be other Blink objects which get painted, such as inline boxes and drag
57 images.
58
59 *** note
60 It is illegal for there to be two drawings with the same ID in a display item
61 list.
62 ***
63
64 Generally, clients of this code should use stack-allocated recorder classes to
65 emit display items to a `DisplayItemList` (using `GraphicsContext`).
66
67 ### Standalone display items
68
69 #### [CachedDisplayItem](CachedDisplayItem.h)
70
71 The type `DisplayItem::CachedSubsequence` indicates that the previous frame's
72 display item list contains a contiguous sequence of display items which should
73 be reused in place of this `CachedDisplayItem`.
74
75 *** note
76 Support for cached subsequences for SPv2 is planned, but not yet fully
77 implemented.
78 ***
79
80 Other cached display items refer to a single `DrawingDisplayItem` with a
81 corresponding type which should be reused in place of this `CachedDisplayItem`.
82
83 #### [DrawingDisplayItem](DrawingDisplayItem.h)
84
85 Holds an `SkPicture` which contains the Skia commands required to draw some atom
86 of content.
87
88 ### Paired begin/end display items
89
90 *** aside
91 TODO(jbroman): Describe how these work, once we've worked out what happens to
92 them in SPv2.
93 ***
94
95 ## Display item list
96
97 Callers use `GraphicsContext` (via its drawing methods, and its
98 `displayItemList()` accessor) and scoped recorder classes, which emit items into
99 a `DisplayItemList`.
100
101 `DisplayItemList` is responsible for producing the paint artifact. It contains
102 the *current* paint artifact, which is always complete (i.e. it has no
103 `CachedDisplayItem` objects), and *new* display items and paint chunks, which
104 are added as content is painted.
105
106 When the new display items have been populated, clients call
107 `commitNewDisplayItems`, which merges the previous artifact with the new data,
108 producing a new paint artifact, where `CachedDisplayItem` objects have been
109 replaced with the cached content from the previous artifact.
110
111 At this point, the paint artifact is ready to be drawn or composited.
112
113 *** aside
114 TODO(jbroman): Explain invalidation.
115 ***
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698