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