Webkit GL Architecture (Copy from code comments)

GL Architecture for webkit on android

Posted: January 4, 2012 in android

3

GL Architecture To draw things, WebView use a tree of layers. The root of that tree is a BaseLayerAndroid, which may have numerous LayerAndroid over it. The content of those layers are SkPicture, the content of the BaseLayer is an PictureSet. When drawing, we therefore have one large “surface” that is the BaseLayer, and (possibly) additional surfaces (usually smaller), which are the LayerAndroids. The BaseLayer usually corresponds to the normal web page content, the Layers are used for some parts such as specific divs (e.g. fixed position divs, or elements using CSS3D transforms, or containing video, plugins, etc.).

*** NOTE: The GL drawing architecture only paints the BaseLayer for now.

The rendering model is to use tiles to display the BaseLayer (as obviously a BaseLayer’s area can be arbitrarly large). The idea is to compute a set of tiles covering the viewport’s area, paint those tiles using the webview’s content (i.e. the BaseLayer’s PictureSet), then display those tiles. We check which tile we should use at every frame.

Overview

The tiles are grouped into a TiledPage — basically a map of tiles covering the BaseLayer’s surface. When drawing, we ask the TiledPage to prepare() itself then draw itself on screen. The prepare() function is the one that schedules tiles to be painted — i.e. the subset of tiles that intersect with the current viewport. When they are ready, we can display the TiledPage. Note that BaseLayerAndroid::drawGL() will return true to the java side if there is a need to be called again (i.e. if we do not have up to date textures or a transition is going on). Tiles are implemented as a BaseTile. It knows how to paint itself with the PictureSet, and to display itself. A GL texture is usually associated to it. We also works with two TiledPages — one to display the page at the current scale factor, and another we use to paint the page at a different scale factor. I.e. when we zoom, we use TiledPage A, with its tiles scaled accordingly (and therefore possible loss of quality): this is fast as it’s purely a hardware operation. When the user is done zooming, we ask for TiledPage B to be painted at the new scale factor, covering the viewport’s area. When B is ready, we swap it with A.

Texture allocation

Obviously we cannot have every BaseTile having a GL texture — we need to get the GL textures from an existing pool, and reuse them. The way we do it is that when we call TiledPage::prepare(), we group the tiles we need (i.e. in the viewport and dirty) into a TilesSet and call BaseTile::reserveTexture() for each tile (which ensures there is a specific GL textures backing the BaseTiles). reserveTexture() will ask the TilesManager for a texture. The allocation mechanism goal is to (in order): – prefers to allocate the same texture as the previous time – prefers to allocate textures that are as far from the viewport as possible – prefers to allocate textures that are used by different TiledPages Note that to compute the distance of each tile from the viewport, each time we prepare() a TiledPage. Also during each prepare() we compute which tiles are dirty based on the info we have received from webkit.

BaseTile Invalidation

We do not want to redraw a tile if the tile is up-to-date. A tile is considered to be dirty an in need of redrawing in the following cases – the tile has acquires a new texture – webkit invalidates all or part of the tiles contents To handle the case of webkit invalidation we store two ids (counters) of the pictureSets in the tile. The first id (A) represents the pictureSet used to paint the tile and the second id (B) represents the pictureSet in which the tile was invalidated by webkit. Thus, if A < B then tile is dirty. Since invalidates can occur faster than a full tiled page update, the tiled page is protected by a ‘lock’ (m_baseLayerUpdate) that is set to true to defer updates to the background layer, giving the foreground time to render content instead of constantly flushing with invalidates. See lockBaseLayerUpdate() & unlockBaseLayerUpdate().

Painting scheduling

The next operation is to schedule this TilesSet to be painted (TilesManager::schedulePaintForTilesSet()). TexturesGenerator will get the TilesSet and ask the BaseTiles in it to be painted. BaseTile::paintBitmap() will paint the texture using the BaseLayer’s PictureSet (calling TiledPage::paintBaseLayerContent() which in turns calls GLWebViewState::paintBaseLayerContent()). Note that TexturesGenerator is running in a separate thread, the textures are shared using EGLImages (this is necessary to not slow down the rendering speed — updating GL textures in the main GL thread would slow things down).