Changes between Version 5 and Version 6 of CoordinatedGraphicsSystem


Ignore:
Timestamp:
Aug 3, 2012 12:53:48 PM (9 years ago)
Author:
kenneth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CoordinatedGraphicsSystem

    v5 v6  
    6464'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp TextureMapperGL]''' is the GPU-accelerated implementation of the drawing primitives. It is currently used by Qt-WebKit2, GTK+ and EFL(?). TextureMapperGL uses shaders compatible with GL ES 2.0, though we’re in the process of converting it to use the WebGL infrastructure directly, which would help with shader compatibility.
    6565
     66== Comments ==
     67
    6668TextureMapperGL tries to use scissors for clipping whenever it can, though if the clipping is not rectangular stencil is used.
    6769
     
    122124'''[/browser/trunk/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp LayerTreeCoordinator]''' is the “boss” for synchronizing the content changes and the viewport changes.  It acts on a frame-by-frame basis. For each frame it retrieves the up-to-date layer information from the different WebGraphicsLayers, makes sure the backing-store content is ready to be serialized, prepares the information needed for scroll adjustment, and passes all that info to the UI process in a series of messages for each frame.
    123125
    124 LayerTreeCoordinator maintains a map of “directly composited images” - images that are rendered once and used multiple times in the same texture. LayerTreeCoordinator maintains the ref-counted lifecycle of such an image, signaling to the UI process when an image is no longer used and its backing texture can be destroyed.
     126LayerTreeCoordinator maintains a map of “directly composited images” - images that are rendered once and used multiple times in the same texture. LayerTreeCoordinator maintains the ref-counted lifecycle of such an image, signaling to the UI process when an image is no longer in use and its backing texture can be destroyed.
    125127
    126 LayerTreeCoordinator is also responsible for two special layers that are not recognized as “composited” by WebCore – a layer for the main web-content, known as non-composited content, is treated as a layer. That is also true for the overlay layer, which paints things such as the scrollbar and the tap indicators.
     128LayerTreeCoordinator is also responsible for two ''special layers'' that are not recognized as “composited” by WebCore – a layer for the '''main web-content''', known as non-composited content, is treated as a layer. That is also true for the '''overlay layer''', which paints things such as the scrollbar and the tap indicators.
    127129
    128130Another important role of LayerTreeCoordinator is to receive the viewport information from the UI process, and to propagate that information to the different backing-stores so that they can prepare to create/destroy tiles.
     
    134136
    135137=== What’s missing from Coordinated Compositing ===
    136 * Coordinating animations seprately from normal rendering, e.g. in a thread. See CSS Animations.
     138* Coordinating animations separately from normal rendering, e.g. in a thread. See CSS Animations.
    137139* Using ScrollingCoordinator instead of the home-brewed fixed-position adjustments, also use it to support UI-side overflow:scroll. There is still a lot to do around scrolling.
    138 * Serializing and coordinating CSS shaders, once they're ready in TextureMapper.
     140* Serializing and coordinating CSS shaders, once they're implemented in TextureMapper.
    139141* VSync support in the UI process, separately from QtScenegraph.
    140142
    141143== [#=CoordinatedBackingStore Coordinated Backing Store] ==
    142 Unlike coordinated compositing, which includes mainly lightweight rendering information about each layer, backing-stores contain pixel data, and thus are both memory-hungry and are expensive to copy and serialize. Backing-stores are drawing into by software or by hardware, depending on the scenario, and thus require binding to platform/OS/GPU-specific code.
     144Unlike coordinated compositing, which includes mainly light-weight rendering information about each layer, backing-stores contain pixel data, and thus are both memory-hungry and are expensive to copy and serialize. Backing-stores are drawing into by software or by hardware, depending on the scenario, and thus require binding to platform/OS/GPU-specific code.
    143145
    144 The current Qt architecture is based on a dynamic tiled backing-store. This means that for each layer in the layer tree, not all content is saved in GPU memory the whole time, but rather only the visible contents plus some cover area around it, depending on heuristics. The TiledBackingStore system is responsible for maintaining these heuristics, based on variables such as the scroll position, contents scale and panning trajectory.
     146The current Qt architecture is based on a dynamic tiled backing-store. This means that for each layer in the layer tree, not all the content is saved in GPU memory the whole time, but rather only the visible contents plus some cover area around it, depending on heuristics. The TiledBackingStore system is responsible for maintaining these heuristics, based on variables such as the scroll position, contents scale and panning trajectory.
    145147
    146148=== Classes ===
     
    168170=== What’s missing from Coordinated Backing Stores ===
    169171* More platform support for GraphicsSurfaces – e.g. on some embedded/mobile systems.
    170 * Graceful handling of low memory situations, e.g. by visible incremental updates to tiles using a smaller UpdateAtlas.
     172* Graceful handling of low memory situations, e.g. by visible incremental updates to tiles using a smaller UpdateAtlas, and adjustment to how the the TiledBackingStore computes the keep and cover rects.
    171173* Allow different pixel formats for tiles, e.g. 16-bit for opaque tiles and 8-bit for masks.
    172174
     
    1791811. Render the view's background.
    180182
    181 The class that handles most of this is [/browser/trunk/Source/WebKit2/UIProcess/qt/QtWebPageSGNode.cpp QtWebPageSGNode]. Its main function, “render”, is used to translate QtScenegraph parameters to WebLayerTreeRenderer parameters. The SG node contains 3 nodes - a root node that controls the viewport transform, a background node, and a custom contents node which renders the actual web contents using WebLayerTreeRenderer.
     183The class that handles most of this is [/browser/trunk/Source/WebKit2/UIProcess/qt/QtWebPageSGNode.cpp  QtWebPageSGNode]. Its main function, “render”, is used to translate QtScenegraph parameters to WebLayerTreeRenderer parameters. The SG node contains 3 nodes - a root node that controls the viewport transform, a background node, and a custom contents node which renders the actual web contents using WebLayerTreeRenderer.
    182184Some other functionality is in QQuickWebPage::updatePaintNode.
    183185
     
    192194== [#=WebGL WebGL Support] ==
    193195There are two possible approaches to WebGL. The current approach uses GraphicsSurfaces, allowing the web process to render with GPU into a platform-specific buffer, later compositing it in the UI process. This approach is somewhat easier to implement, but might not be efficient on some GPU systems, and can also create security issues if the web process has direct access to the GPU.
     196
    194197The other option is to serialize the WebGL display list to the UI process, making the actual GL calls there, into an FBO. This is a safer and potentially more cross-platform approach, however it's yet to be seen how much of an undertaking it is, and how well it scales.
    195198