gfx/docs/GraphicsOverview.rst

   1 Graphics Overview
   2 =========================
   3
   4 Work in progress. Possibly incorrect or incomplete.
   5 ---------------------------------------------------
   6
   7 Jargon
   8 ------
   9
  10 There's a lot of jargon in the graphics stack. We try to maintain a list
  11 of common words and acronyms `here <https://wiki.mozilla.org/Platform/GFX/Jargon>`__.
  12
  13 Overview
  14 --------
  15
  16 The graphics systems is responsible for rendering (painting, drawing)
  17 the frame tree (rendering tree) elements as created by the layout
  18 system. Each leaf in the tree has content, either bounded by a rectangle
  19 (or perhaps another shape, in the case of SVG.)
  20
  21 The simple approach for producing the result would thus involve
  22 traversing the frame tree, in a correct order, drawing each frame into
  23 the resulting buffer and displaying (printing non-withstanding) that
  24 buffer when the traversal is done. It is worth spending some time on the
  25 “correct order” note above. If there are no overlapping frames, this is
  26 fairly simple - any order will do, as long as there is no background. If
  27 there is background, we just have to worry about drawing that first.
  28 Since we do not control the content, chances are the page is more
  29 complicated. There are overlapping frames, likely with transparency, so
  30 we need to make sure the elements are draw “back to front”, in layers,
  31 so to speak. Layers are an important concept, and we will revisit them
  32 shortly, as they are central to fixing a major issue with the above
  33 simple approach.
  34
  35 While the above simple approach will work, the performance will suffer.
  36 Each time anything changes in any of the frames, the complete process
  37 needs to be repeated, everything needs to be redrawn. Further, there is
  38 very little space to take advantage of the modern graphics (GPU)
  39 hardware, or multi-core computers. If you recall from the previous
  40 sections, the frame tree is only accessible from the UI thread, so while
  41 we’re doing all this work, the UI is basically blocked.
  42
  43 (Retained) Layers
  44 ~~~~~~~~~~~~~~~~~
  45
  46 Layers framework was introduced to address the above performance issues,
  47 by having a part of the design address each item. At the high level:
  48
  49 1. We create a layer tree. The leaf elements of the tree contain all
  50    frames (possibly multiple frames per leaf).
  51 2. We render each layer tree element and cache (retain) the result.
  52 3. We composite (combine) all the leaf elements into the final result.
  53
  54 Let’s examine each of these steps, in reverse order.
  55
  56 Compositing
  57 ~~~~~~~~~~~
  58
  59 We use the term composite as it implies that the order is important. If
  60 the elements being composited overlap, whether there is transparency
  61 involved or not, the order in which they are combined will effect the
  62 result. Compositing is where we can use some of the power of the modern
  63 graphics hardware. It is optimal for doing this job. In the scenarios
  64 where only the position of individual frames changes, without the
  65 content inside them changing, we see why caching each layer would be
  66 advantageous - we only need to repeat the final compositing step,
  67 completely skipping the layer tree creation and the rendering of each
  68 leaf, thus speeding up the process considerably.
  69
  70 Another benefit is equally apparent in the context of the stated
  71 deficiencies of the simple approach. We can use the available graphics
  72 hardware accelerated APIs to do the compositing step. Direct3D, OpenGL
  73 can be used on different platforms and are well suited to accelerate
  74 this step.
  75
  76 Finally, we can now envision performing the compositing step on a
  77 separate thread, unblocking the UI thread for other work, and doing more
  78 work in parallel. More on this below.
  79
  80 It is important to note that the number of operations in this step is
  81 proportional to the number of layer tree (leaf) elements, so there is
  82 additional work and complexity involved, when the layer tree is large.
  83
  84 Render and retain layer elements
  85 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  86
  87 As we saw, the compositing step benefits from caching the intermediate
  88 result. This does result in the extra memory usage, so needs to be
  89 considered during the layer tree creation. Beyond the caching, we can
  90 accelerate the rendering of each element by (indirectly) using the
  91 available platform APIs (e.g., Direct2D, CoreGraphics, even some of the
  92 3D APIs like OpenGL or Direct3D) as available. This is actually done
  93 through a platform independent API (see Moz2D) below, but is important
  94 to realize it does get accelerated appropriately.
  95
  96 Creating the layer tree
  97 ~~~~~~~~~~~~~~~~~~~~~~~
  98
  99 We need to create a layer tree (from the frames tree), which will give
 100 us the correct result while striking the right balance between a layer
 101 per frame element and a single layer for the complete frames tree. As
 102 was mentioned above, there is an overhead in traversing the whole tree
 103 and caching each of the elements, balanced by the performance
 104 improvements. Some of the performance improvements are only noticed when
 105 something changes (e.g., one element is moving, we only need to redo the
 106 compositing step).
 107
 108 Refresh Driver
 109 ~~~~~~~~~~~~~~
 110
 111 Layers
 112 ~~~~~~
 113
 114 Rendering each layer
 115 ~~~~~~~~~~~~~~~~~~~~
 116
 117 Tiling vs. Buffer Rotation vs. Full paint
 118 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 119
 120 Compositing for the final result
 121 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 122
 123 Graphics API
 124 ~~~~~~~~~~~~
 125
 126 Moz2D
 127 ~~~~~
 128
 129 -  The Moz2D graphics API, part of the Azure project, is a
 130    cross-platform interface onto the various graphics backends that
 131    Gecko uses for rendering such as Direct2D (1.0 and 1.1), Skia, Cairo,
 132    Quartz, and NV Path. Adding a new graphics platform to Gecko is
 133    accomplished by adding a backend to Moz2D.
 134    See `Moz2D documentation on wiki <https://wiki.mozilla.org/Platform/GFX/Moz2D>`__.
 135
 136 Compositing
 137 ~~~~~~~~~~~
 138
 139 Image Decoding
 140 ~~~~~~~~~~~~~~
 141
 142 Image Animation
 143 ~~~~~~~~~~~~~~~
 144
 145 `Historical Documents <http://www.youtube.com/watch?v=lLZQz26-kms>`__
 146 ---------------------------------------------------------------------
 147
 148 A number of posts and blogs that will give you more details or more
 149 background, or reasoning that led to different solutions and approaches.
 150
 151 -  2010-01 `Layers: Cross Platform Acceleration <http://www.basschouten.com/blog1.php/layers-cross-platform-acceleration>`__
 152 -  2010-04 `Layers <http://robert.ocallahan.org/2010/04/layers_01.html>`__
 153 -  2010-07 `Retained Layers <http://robert.ocallahan.org/2010/07/retained-layers_16.html>`__
 154 -  2011-04 `Introduction <https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/%20Moz2D>`__
 155 -  2011-07 `Layers <http://chrislord.net/index.php/2011/07/25/shadow-layers-and-learning-by-failing/%20Shadow>`__
 156 -  2011-09 `Graphics API Design <http://robert.ocallahan.org/2011/09/graphics-api-design.html>`__
 157 -  2012-04 `Moz2D Canvas on OSX <http://muizelaar.blogspot.ca/2012/04/azure-canvas-on-os-x.html>`__
 158 -  2012-05 `Mask Layers <http://featherweightmusings.blogspot.co.uk/2012/05/mask-layers_26.html>`__
 159 -  2013-07 `Graphics related <http://www.basschouten.com/blog1.php>`__