【专业技术】chromium GPU 硬件加速合成

前言：

在传统浏览器网页渲染实现方案中，网页完全依赖CPU的能力去渲染网页(软件渲染简介：网页生成一张bitmap丢给CPU去绘制)，然而一台机器的CPU不仅仅提供给网页，CPU还需要处理其他的事务，响应除网页以外的动作。

那么这种效率可想而知，性能会打大折扣，尤其在配置较低的机型表现得更明显。当前的硬件能力已经将更多渲染任务交由GPU去处理，那么开发者更多的需要关心实现的渲染性能以及是否省电，这两个点在移动设备上更加突出。那么在浏览器上使用GPU来进行硬件加速合成网页显得更为重要。

硬件加速的优点：

1) 通过GPU进行合成网页层比CPU更快并且性能更好。

2）对于一些已经在GPU中的内容可以减少不必要的高代价回读(readbacks), 比如：WebGL,Canvas2D,Video加速。

3) 充分利用现在的设备能力，让GPU和CPU并行工作创建高效的图形管道(pipeline)。

既然硬件加速有这么好的优点，我们必须得充分的利用GPU。chromium 当中有个渲染的机制叫”CC“（chrome compositor）,使用硬件加速网页合成。我们先来看下为什么需要有"CC”, 下面是一个网页的展示例子：

当只有一个pixel buffer时需要对所有的元素进行更新，然而我们看到上图上下两部分是各自独立的，如果其中一个更新，另外一个是不需要随着变化。

上图中的Game/equipment有重叠部分如果有各自的pixel buffer那么可以将他们进行合成，而不需要整个进行绘制。

compositing的好处

1)避免不必要的重绘操作

2)让一些独立功能更高效包括 WebGL, video 硬解码，透明度处理，网页滑动等。

网页的Compositor过程

标识出compositor layer

图的黄色部分标识为compositor layer.我们可以看到轮播图、数字循环等被标记为单一的compositor layer，他们都有一个定时器在跑，会定时的请求刷新页面. 有了compositor layer 他们就可以单独进行渲染，不影响其他不刷新的内容，提供网页渲染性能。

那么执行compositing 任务需要哪些步骤？

compositing 任务是为了让网页渲染变得高效，一张网页首先需要parsing 页面生成DOM tree 进而生成RenderObject Tree 再生成RenderLayer Tree，此过程由WebCore完成，在Chromium中这一部分称作"blink" http://www.chromium.org/blink； WebCore并不提供Graphic 而是由porting层来执行渲染，比如移动设备上采用OpenGL ES, Chromium在渲染时采用了compositing layer。进行compositing 需要执行一下步骤：

1)Select 需要选择生成composite layer ,需要决定哪些内容块需要pixel buffer（backing store）

2) Paint 每个composite layer 的内容

3) Draw 画 composite layer 生成最终的image

实现层次分析

"CC" chromium composting 的数据源由RenderLayer提供，RenderLayer类代表 compositor的正真数据对象，当需要时会被paint到backing store.RenderLayer对象中拥有CompositedLayerMapping。

CompositedLayerMapping类为RenderLayer tree & GraphicsLayer Tree提供一个桥梁(bridge），保持RenderLayer tree 与 GraphicsLayer tree的映射关系，每个CompositedLayerMapping 管理一些小的GraphicsLayer群集以及哪些RenderLayer需要在解析阶段提供给GraphicsLayer。GraphicsLayer是包含backing store 的rendering surface 的抽象，管理transformation 和 animations. WebLayer提供 Chromium 和 Blink 的compositing 桥梁，是cc::layer接口映射到GraphicLayer的枢纽，cc::layer代表Chromium composite layer，是cc的接口。前面提到CompositedLayerMapping管理一些小的GraphicsLayers群集，那么为什么需要这么多小的GraphicsLayers群集：

（1）需要为scrollbars创建 layer 来保证与内容本身之间的分离。 （2）用来标记和反射一些显示的layers。（3） 一些需要scroll的网页内容进行合并。

实现代码逻辑分析

前面我们提到过compositor需要三个步骤下面介绍对应的代码实现.

1.Select 选择哪些RenderLayer需要生成 compositor layer。在chromium 32代码中这部分的逻辑实现位于RenderLayerCompositor

1）RenderLayerCompositor::computeCompositingRequirements ()

（1） 递归检查孩子节点 painting顺序是否正确，决定任何孩子节点成为被compositor对象，如果一个孩子layer拥有compositing layer，则他的所有孩子节点也会成为compostiing 为了渲染这一层次。

（2） 如果一个孩子位于z-order反面 列表是compositing，那么这一层本身也将被compositing为了保证这一层的内容渲染高于这一层。这就意味着它的正面z-index孩子节点也需要被compositing，为的是能将一整个合成起来，最终显示，否则会影响其中显示，导致部分被遮挡而未被显示出来。

2）RenderLyaerCompositor::rebuildComositingLayerTree

调用compositedLayerMapping 设置layer clipping区域内容，为paint做准备。

在Chromium 39 release 实现中这部分代码被重构了， 具体实现放在了CompositingRequirementsUpdate::update();

2.Paint 将compositor layer paint到 backing store. GraphicsLayer::paint()

paintGraphicsLayerContents 接受GraphicsContext，将这个context传递给GraphicsLayerClient::paintContents;

实现GraphicsLayerClient类有两个分别是：CompositedLayerMapping，RenderLayerCompositor。

compositor 控制paint时机，提供给RenderLayer 合适的context，和paint 解析结构。

3.触发平台Draw方法

注：上面分析基于chromium 39 源码.

参考资料：

http://www.chromium.org/developers/design-documents

http://www.chromium.org/blink

源码目录：

./third_party/WebKit/Source/core/rendering/compositing/

./third_party/WebKit/Source/core/rendering/

./third_party/WebKit/Source/platform/graphics/

./cc/layers/

./cc/blink/

Compositing summary

程序算法世界的永恒话题 时间、空间复杂度相互对立。对于compositing 合成优化 权衡计算开销与额外的内存占用也是相互对立的概念。

compositing的计算开销主要体现在 网页的组块内容如何到composited layer.

compositing的内存开销主要体现在提供backing store给compositor layer 绘制内容。

这两者之间的平衡是程序优化的哲理。

一些思考：

chromium 的“cc”的渲染架构可以说在业内浏览器内核中领先的浏览器内核渲染架构，当然他也可以独立与浏览器做为单独的渲染架构，但是其更多是为网页渲染提供的服务。

HTML5的标准W3C已经完成定稿，那么很多人会关注H5游戏在浏览器上的性能表现，从移动浏览器针对H5的跑分来看，其性能是目前业内浏览器中最优的，当然其代价开销也相当的大，尤其内存的占用。H5对游戏的支持主要提供两种方式一种是提供2D canvas给游戏开发者，还有一种是WebGL支持绘制，WebGL的开发成本会相对高很多，开发者需要对opengl api 非常熟悉，而目前业内中游戏开发者对这一块熟悉的开发者少之又少，因此就成了高门槛。随着移动设备的硬件能力的提升，理论上WebGL能提供与原生native 应用相当的性能与流畅度。不过目前的JS引擎在移动端上的表现和PC上还是有相当大的差距，WebGL, 2D canvas需要通过js引擎来执行他们的动作，包括游戏逻辑，事件响应等，而普通的native原生应用通过Activity 直接接受处理事件响应，直接操作原生API， 跨越这一层是HTML5 游戏及应用巨大难题。 在渲染上Chromium 提供先进的"CC"，但是在游戏领域，对于一些MMO,RPG，社交游戏这种特点的游戏支持的作用就相当的弱了， 因为Chromium 在局部repaint 起到绝佳的作用，而提到这些类型游戏，需要实时渲染，甚至是全局渲染即所有元素需要渲染，“CC”的威力就大大减弱。

转自：http://blog.csdn.net/typename powered by miechalzhao@gmail.com