Changes between Version 2 and Version 3 of CoordinatedGraphicsSystem


Ignore:
Timestamp:
Aug 3, 2012 12:38:54 PM (11 years ago)
Author:
kenneth@webkit.org
Comment:

A few minor changes

Legend:

Unmodified
Added
Removed
Modified

  • CoordinatedGraphicsSystem

    v2 v3  
    2626
    2727This document is here to serve as a snapshot of current architecture for hardware-acceleration in the Qt port. Though all of the components described here are used by the Qt port, most of them are not used exclusively by the Qt port. Every port has a different blend of components it uses.
     28
    2829The main components described in this document:
    29 [#TextureMapper TextureMapper] - a lightweight scenegraph implementation tuned specifically for WebKit accelerated compositing. Used by Qt, EFL and GTK.
     30[#TextureMapper TextureMapper] - a light-weight scenegraph implementation tuned specifically for WebKit accelerated compositing. Used by Qt, EFL and GTK+.
    3031
    3132[#CoordinatedCompositing Coordinated Compositing] - an architecture for WebKit2 that allows using accelerated compositing in a dual process environment. EFL is, at the time of writing this document, in the process of switching to use coordinated compositing.
    … …  
    4445
    4546== [#=TextureMapper Texture Mapper] ==
    46 TextureMapper is a lightweight scenegraph implementation that is specially attuned for efficient GPU or software rendering of CSS3 composited content, such as 3D transforms, animations and canvas.
    47 TextureMapper is pretty well-contained, and apart from the backing-store integration is thread safe.
     47TextureMapper is a light-weight scenegraph implementation that is specially attuned for efficient GPU or software rendering of CSS3 composited content, such as 3D transforms, animations and canvas.
    4848
    49 TextureMapper includes/uses the following classes. Note that the last two do not depend on TextureMapper, but are currently used only by TextureMapper.
     49TextureMapper is pretty well-contained, and apart from the backing-store integration, it is thread safe.
     50
     51TextureMapper includes/uses the following classes. Note that the last two (without TextureMapper in the name), do not depend on TextureMapper, but are currently used only by it.
    5052
    5153'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapper.cpp TextureMapper]''' is an abstract class that provides the necessary drawing primitives for the scenegraph.
    … …  
    5759'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.cpp TextureMapperImageBuffer]''' is a software implementation of the TextureMapper drawing primitives.
    5860
    59 It is currently used by Qt in WebKit1 when using a QWebView, and also by the GTK port as a fallback when OpenGL is not available.
     61It is currently used by Qt in WebKit1 when using a QWebView, and also by the GTK+ port as a fallback when OpenGL is not available.
    6062TextureMapperImageBuffer uses normal GraphicsContext operations to draw, making it not effectively use the GPU. However, unlike regular drawing in WebCore, it does use backing stores for the layers, which could cause some soft acceleration.
    6163
    62 '''[/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.
     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.
    6365
    6466TextureMapperGL tries to use scissors for clipping whenever it can, though if the clipping is not rectangular stencil is used.
    6567
    66 Other things that are handled specially in TextureMapperGL are masks, which are rendered using multitexturing the content texture with the mask texture, and filters, which are handled with special shaders. A feature that is not yet implemented in TextureMapperGL is CSS shaders, and that is in the pipeline.
     68Other things that are handled specially in TextureMapperGL are masks, which are rendered using multi-texturing the content texture with the mask texture, and filters, which are handled with special shaders. A feature that is not yet implemented in TextureMapperGL is CSS shaders, and that is in the pipeline.
    6769
    68 '''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp TextureMapperLayer]''' is the class that represent a node in the GPU-renderable layer tree. It maintains its own tree hierarchy, which is equivalent to the GraphicsLayer tree hierarchy, though unlike GraphicsLayers its hierarchy is thread safe.
     70'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp TextureMapperLayer]''' is the class that represent a node in the GPU-renderable layer tree. It maintains its own tree hierarchy, which is equivalent to the GraphicsLayer tree hierarchy, though unlike GraphicsLayers, its hierarchy is thread safe.
    6971
    7072The main function of TextureMapperLayer is to determine the render order and the use of intermediate surfaces. For example, opacity is to be applied on the rendering results of a subtree, and not separately for each layer.
    … …  
    7880However, rendering each of these phases into an intermediate surface would be costly on some GPUs. Therefore, TextureMapperLayer does its best to avoid using intermediate surfaces unless absolutely needed. For example, content that has reflections and no masks or opacity would not need intermediate surfaces at all, and the same goes for content with mask/opacity that does not have overlapping sub layers.
    7981
    80 Another use of TextureMapperLayer is to tie together TextureMapper, GraphicsLayerTextureMapper, TextureMapperBackingStore, GraphicsLayerAnimation and GraphicsLayerTransform. it includes all the synchronization phases, that are responsible to time when changes coming from different sources are actually supposed to occur. Without proper synchronization, many times flickers or artifact bugs occur.
     82Another use of TextureMapperLayer is to tie together TextureMapper, GraphicsLayerTextureMapper, TextureMapperBackingStore, GraphicsLayerAnimation and GraphicsLayerTransform. It includes all the synchronization phases, that are responsible to time when changes coming from different sources are actually supposed to occur. Without proper synchronization, many times flickers or artifact bugs will occur.
    8183
    8284'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp GraphicsLayerTextureMapper]''' is the glue between [/browser/trunk/Source/WebCore/platform/graphics/GraphicsLayer.cpp GraphicsLayer] and TextureMapperLayer. Since TextureMapperLayer is thread-safe and GraphicsLayer is not, GraphicsLayerTextureMapper provides the necessary glue. GraphicsLayerTextureMapper does not do anything interesting in particular apart from synchronization.
    8385
    8486'''[/browser/trunk/Source/WebCore/platform/graphics/texmap/TextureMapperBackingStore.cpp TextureMapperBackingStore]''' is what glues TextureMapperLayer with different backing stores.
    85 It allows the type of backing store to be abstracted away from TextureMapperLayer, allowing TextureMapperLayer to be used both with a standard tiled backing store for WebKit1 (TextureMapperTiledBackingStore), a GraphicsSurface-backed backing store for WebGL (TextureMapperSurfaceBackingStore) or a backing store for webkit2 (WebKit::LayerBackingStore).
     87It allows the type of backing store to be abstracted away from TextureMapperLayer, allowing TextureMapperLayer to be used both with a standard tiled backing store for WebKit1 (TextureMapperTiledBackingStore), a GraphicsSurface-backed backing store for WebGL (TextureMapperSurfaceBackingStore) or a backing store for WebKit2 (WebKit::LayerBackingStore).
     88
    8689The implementation in TextureMapperTiledBackingStore is pretty simple, and is used only to work around the 2000x2000 texture size limitation in OpenGL. It is very different from the dynamic tiled backing store, discussed later.
    8790
    … …  
    9699* Support for mask/reflection edge cases
    97100* Better readability in TextureMapperShaderManager
    98 * Using GraphicsContext3D instead of OpenGL (this is underway)
     101* Using GraphicsContext3D instead of OpenGL directly (this is underway)
    99102* Support for dynamic TiledBackingStore per layer in WebKit1
    100103* Make it better and faster :)
    … …  
    105108The coordinated compositing code might be a bit tricky to read, because of its asynchronous nature on top of the WebKit2 IPC mechanism.
    106109
    107 An important concept to understand is the roles of the UI and the web processes.
     110An important concept to understand is the roles of the UI and the web processes:
    108111The web process owns the content and the UI process owns the viewport. Thus, the UI process would know about viewport and user interactions before the web process, and the web process would know about content changes (e.g. a CSS layer getting added) before the UI process.
    109112
    110113The web process owns the frame and the content. It decides when to render a new frame, which information to include in the layer tree, how the backing stores behave, and also how the animations are timed.
    111 The UI process is responsible for rendering the latest frame from the web process, compensating for user interaction not yet committed by the web process.
    112 An example for that is scrolling adjustments - the web process tells the UI process which layers are fixed to the viewport, and the UI process knows the exact scroll position for each paint. It’s the UI process’ job to account for the difference. Another role of the UI process is to periodically notify the web process of viewport changes (e.g. panning), to allow the web process to decide whether or not to create/destroy tiles.
     114The UI process is responsible for rendering the latest frame from the web process, compensating for user interaction not yet committed by the web process.
     115 
     116''An example for that is scrolling adjustments - the web process tells the UI process which layers are fixed to the viewport, and the UI process knows the exact scroll position for each paint. It’s the UI process’ job to account for the difference. Another role of the UI process is to periodically notify the web process of viewport changes (e.g. panning), to allow the web process to decide whether or not to create/destroy tiles, as well as moving content into view when writing in text fields.''
    113117
    114118=== Classes ===