Chromium Code Reviews| 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 |