【专业技术】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 条评论
登录 后参与评论

相关文章

来自专栏一个会写诗的程序员的博客

附录C Java编程简史附录C Java编程简史丰富多彩的JVM生态参考资料

在20世纪60年代,软件曾出现过严重危机,由软件错误而引起的信息丢失、系统报废事件屡有发生。为此,1968年,荷兰E.W.Dijkstra提出了程序设计中常用的...

914
来自专栏LET

glTF简介

27010
来自专栏大内老A

WCF技术剖析(卷1)之前言

第一次邂逅WCF是在微软举办的一场关于Windows Vista技术推广培训上,时间大概是2005年10月份,当时对WCF可谓是一见钟情。如果读者也像我一样,之...

1749
来自专栏技术分享

.NET应用架构设计—面向查询的领域驱动设计实践(调整传统三层架构,外加维护型的业务开关)

阅读目录: 1.背景介绍 2.在业务层中加入核心领域模型(引入DomainModel,让逻辑、数据有家可归,变成一个完整的业务对象) 3.统一协调层Applic...

2107
来自专栏企鹅号快讯

Android应用架构前世今生

前言 Android的开发生态系统发展迅速,在开发Android的几年的时间里,用来构建Android应用的架构与技术一直在不断进化。随着项目的不断更新迭代,应...

1896
来自专栏诸葛青云的专栏

C语言最难啃的三块硬骨头

指针之所以难理解,因为指针本身就是一个变量,是一个非常特殊的变量,专门存放地址的变量,这个地址需要给申请空间才能装东西,而且因为是个变量可以中间赋值,这么一倒腾...

922
来自专栏函数式编程语言及工具

FunDA(0)- Functional Data Access accessible to all

   大数据、多核CPU驱动了函数式编程模式的兴起。因为函数式编程更适合多线程、复杂、安全的大型软件编程。但是,对许多有应用软件开发经验的编程者来说,函数式编程...

20110
来自专栏UML

数据流程图 (DFD) 示例:食品订购系统

数据流图也称为气泡图。它通常用作创建系统概述的初步步骤,而不需要详细介绍,以后可以将其作为自上而下的分解方式进行详细说明。DFD显示将从系统输入和输出的信息类型...

1536
来自专栏HappenLee的技术杂谈

大数据小视角3:CarbonData,来自华为的中国力量

对于OLAP查询来说,存在多种不同类型的查询,存储结构的不同会影响到不同查询的数据表现。所以CarbonData的定位是作为一种通用的查询存储数据,通过Spar...

743
来自专栏一个会写诗的程序员的博客

第1章 JVM语言家族概览

所谓编程语言只是一个抽象的规范,而编译器是这个规范的实现,它是在这个规范的严格定义下被实现的.

943

扫码关注云+社区