OLD | NEW |
---|---|
(Empty) | |
1 # cc/ | |
2 | |
3 This directory contains a threaded compositor. Its clients include blink | |
danakj
2017/05/10 14:35:18
nit: threaded is optional
| |
4 and the browser ui. | |
5 | |
6 ## Glossaries | |
7 | |
8 ### Stacked elements and stacking contexts | |
9 | |
10 ### Active CompositorFrame | |
11 | |
12 ### Active Tree | |
13 The set of layers and property trees that was/will be used to submit a | |
14 CompositorFrame from the layer compositor. Composited effects such as scrolling, | |
15 pinch, and animations are done by modifying the active tree, which allows for | |
16 producing and submitting a new CompositorFrame. | |
17 | |
18 ### CompositorFrame | |
19 A set of RenderPasses (which are a list of DrawQuads) along with metadata. | |
20 Conceptually this is the instructions (transforms, texture ids, etc) for how to | |
21 draw an entire scene which will be presented in a surface. | |
22 | |
23 ### CopyOutputRequest (or Copy Request) | |
24 A request for a texture (or bitmap) copy of some part of the compositor's | |
25 output. Such requests force the compositor to use a separate RenderPass for the | |
26 content to be copied, which allows it to do the copy operation once the | |
27 RenderPass has been drawn to. | |
28 | |
29 ### ElementID | |
30 Chosen by cc's clients and can be used as a stable identifier across updates. | |
31 For example, blink uses ElementIDs as a stable id for the object (opaque to cc) | |
32 that is responsible for a composited animation. Some additional information in | |
33 [element_id.h](https://codesearch.chromium.org/chromium/src/cc/trees/element_id. h) | |
34 | |
35 ### DirectRenderer | |
36 An abstraction that provides an API for the Display to draw a fully-aggregated | |
37 CompositorFrame to a physical output. Subclasses of it provide implementations | |
38 for various backends, currently GL or Software. | |
39 | |
40 ### Layer | |
41 | |
42 ### LayerImpl | |
43 | |
44 ### LayerTree | |
45 | |
46 ### Occlusion Culling | |
47 Avoiding work by skipping over things which are not visible due to being | |
48 occluded (hidden from sight by other opaque things in front of them). Most | |
49 commonly refers to skipping drawing (ie culling) of DrawQuads when other | |
50 DrawQuads will be in front and occluding them. | |
51 | |
52 ### Property Trees | |
53 | |
54 ### Display | |
55 A controller class that takes CompositorFrames for each surface and draws them | |
56 to a physical output. | |
57 | |
58 ### Draw | |
59 Filling pixels in a physical output (technically could be to an offscreen | |
60 texture), but this is the final output of the display compositor. | |
61 | |
62 ### DrawQuad | |
63 A unit of work for drawing. Each DrawQuad has its own texture id, transform, | |
64 offset, etc. | |
65 | |
66 ### Shared Quad State | |
67 A shared set of states used by multiple draw quads. DrawQuads that are linked to | |
68 the same shared quad state will all use the same properties from it, with the | |
69 addition of things found on their individual DrawQuad structures. | |
70 | |
71 ### Render Pass | |
72 A list of DrawQuads which will all be drawn together into the same render target | |
73 (either a texture or physical output). Most times all DrawQuads are part of a | |
74 single RenderPass. Additional RenderPasses are used for effects that require a | |
75 set of DrawQuads to be drawn together into a buffer first, with the effect | |
76 applied then to the buffer instead of each individual DrawQuad. | |
77 | |
78 ### Render Surface | |
79 Synonym for RenderPass now. Historically part of the Layer tree data structures, | |
80 with a 1:1 mapping to RenderPasses. RenderSurfaceImpl is a legacy piece that | |
81 remains. | |
82 | |
83 ### Surface | |
84 | |
85 ### Record | |
86 | |
87 ### Raster | |
88 | |
89 ### Paint | |
90 | |
91 ### Pending CompositorFrame | |
92 | |
93 ### Pending Tree | |
94 The set of layers and property trees that is generated from a main frame (or | |
95 BeginMainFrame, or commit). The pending tree exists to do raster work in the | |
96 layer compositor without clobbering the active tree until it is done. This | |
97 allows the active tree to be used in the meantime. | |
98 | |
99 ### Composite | |
100 To produce a single graphical output from multiple inputs? In practice, the | |
chrishtr
2017/05/10 16:47:26
Does this section help with understanding?
enne (OOO)
2017/05/10 18:14:13
I think s/?/./ and this is fine.
| |
101 layer compositor does raster from recordings and manages memory, performs | |
102 composited effects such as scrolling, pinch, animations, producing a | |
103 CompositorFrame. The display compositor does an actual "composite" to draw the | |
104 final output into a single physical output. | |
105 | |
106 ### Invalidation | |
107 | |
108 ### Damage | |
109 | |
110 ### Tiles | |
111 | |
112 ### Prepare Tiles | |
113 Prioritize and schedule needed tiles for raster. This is the entry point to a | |
114 system that converts painting (raster sources / recording sources) into | |
115 rasterized resources that live on tiles. This also kicks off any dependent image | |
116 decodes for images that need to be decode for the raster to take place. | |
117 | |
118 ### Device Scale Factor | |
119 The scale at which we want to display content on the output device. For very | |
120 high resolution monitors, everything would become too small if just presented | |
121 1:1 with the pixels. So we use a larger number of physical pixels per logical | |
122 pixels. This ratio is the device scale factor. 1 or 2 is the most common on | |
123 ChromeOS. Values between 1 and 2 are common on Windows. | |
OLD | NEW |