【专业技术】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

原文发布于微信公众号 - 程序员互动联盟(coder_online)

原文发表时间:2015-08-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏QQ音乐前端团队专栏

自己动手打造前端性能监控系统

我们从三个各方面,前端上报,数据收集和入库,数据展示来介绍了如何打造一个测速系统。

35410
来自专栏何俊林

直播技术总结(三)ijkplayer的一些问题优化记录

前言:ijkplayer中一些问题记录优化,看下Agenda: 在弱网时如何优化 ijkplayer播放卡顿如何优化 如何支持https链接播放? 如何降低ij...

59710
来自专栏lgp20151222

关于一次性的数据输入,excel字符串连接保存到服务器还是CRUD?

开发中遇到个问题,线下一个紧急的活动,给一个excel的文件,要把里面的一次性的数据放进活动里面,说真的几百几千个数据啊,手写进数据库不是更麻烦了吗?

722
来自专栏Material Design组件

Material Design —Progress & activity

1853
来自专栏美团技术团队

移动端性能监控方案Hertz

性能问题是造成App用户流失的罪魁祸首之一。App的性能问题包括崩溃、网络请求错误或超时、响应速度慢、列表滚动卡顿、流量大、耗电等等。而导致App性能低下的原因...

4963
来自专栏非著名程序员

理解RESTful架构

越来越多的人开始意识到,网站即软件,而且是一种新型的软件。 这种"互联网软件"采用客户端/服务器模式,建立在分布式体系上,通过互联网通信,具有高延时(high ...

17010
来自专栏腾讯移动品质中心TMQ的专栏

【腾讯TMQ】精准测试之精简用例

手机管家目前有6年多的历史了,一直在持续不断的加入新特性,每次发布前除了新增功能之外,旧的核心功能也是发布之前必须确保的。

2350
来自专栏Material Design组件

Human Interface Guidelines — Progress Indicators

843
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|电量测试

电量测试 活动时间:2017年9月19日 斗鱼直播分享 活动介绍:TMQ在线沙龙第三十期分享 本次分享的主题是:电量测试 在线平均人气 70人! 想知道活动分享...

2068
来自专栏前端架构

理解RESTful架构

这种"互联网软件"采用客户端/服务器模式,建立在分布式体系上,通过互联网通信,具有高延时(high latency)、高并发等特点。

762

扫描关注云+社区