Changes between Version 5 and Version 6 of CoordinatedGraphicsSystem

Timestamp:

Aug 3, 2012 12:53:48 PM (12 years ago)

Author:

kenneth@webkit.org

Comment:

--

CoordinatedGraphicsSystem

@@ -64 +64 @@
 '''[/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.
 
+== Comments ==
+
 TextureMapperGL tries to use scissors for clipping whenever it can, though if the clipping is not rectangular stencil is used.
 
@@ -122 +124 @@
 '''[/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.
 
-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.
+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 in use and its backing texture can be destroyed.
 
-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.
+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.
 
 Another 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.
@@ -134 +136 @@
 
 === What’s missing from Coordinated Compositing ===
-* Coordinating animations seprately from normal rendering, e.g. in a thread. See CSS Animations.
+* Coordinating animations separately from normal rendering, e.g. in a thread. See CSS Animations.
 * 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.
-* Serializing and coordinating CSS shaders, once they're ready in TextureMapper.
+* Serializing and coordinating CSS shaders, once they're implemented in TextureMapper.
 * VSync support in the UI process, separately from QtScenegraph.
 
 == [#=CoordinatedBackingStore Coordinated Backing Store] ==
-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.
+Unlike 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.
 
-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.
+The 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.
 
 === Classes ===
@@ -168 +170 @@
 === What’s missing from Coordinated Backing Stores ===
 * More platform support for GraphicsSurfaces – e.g. on some embedded/mobile systems.
-* Graceful handling of low memory situations, e.g. by visible incremental updates to tiles using a smaller UpdateAtlas.
+* 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.
 * Allow different pixel formats for tiles, e.g. 16-bit for opaque tiles and 8-bit for masks.
 
@@ -179 +181 @@
 1. Render the view's background.
 
-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.
+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.
 Some other functionality is in QQuickWebPage::updatePaintNode.
 
@@ -192 +194 @@
 == [#=WebGL WebGL Support] ==
 There 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.
+
 The 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.