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

相关文章

来自专栏hightopo

从IE6到IE11上运行WebGL 3D遇到的各种坑

1313
来自专栏互联网杂技

20个为前端开发者准备的文档和指南4

1.I want to use 基于的数据和功能都在Can I use网站上列出来了,这个app可以给你选择很多前端开发功能的能力和获得全世界用户看到你选择的功...

32910
来自专栏程序员宝库

刚开始学编程?这几款小工具能让你事半功倍

2037
来自专栏web前端教室

前端开发实际上操作的是数据,而不是DOM

image.png 昨天写了 逆向的前端学习思路,就是从数据为源头,来反向的学习HTML,CSS,JS这些知识,今天想再详细的说说这个话题。 一般情况下,我们学...

1768
来自专栏程序员的知识天地

前后端分离后的前端时代,使用前端技术能做哪些事?

什么是前后端分离,要区分前端和后端,需要有个明确的界限。一般,用户可以直接看到的东西,都是属于前端的范畴,除了前端之外都属于后端了。

1482
来自专栏ATYUN订阅号

Medium网友开发了一款应用程序 让学习算法和数据结构变得更有趣

Medium网友Peter Weinberg开发了一款名叫CS-Playground-React的应用程序,可以使大家更有意思、也更加轻松地学习算法和数据结构。...

4025
来自专栏施炯的IoT开发专栏

《101 Windows Phone 7 Apps》读书笔记-Subservient Cat

课程内容 Ø Playing Video Ø MediaElement     Subservient Cat是一个“虚拟宠物”的应用程序。与大多数猫不一...

1769
来自专栏编程微刊

提高工作效率的几个小技巧

1434
来自专栏空帆船w

我的公众号文章是如何排版的?

文字排版是一篇文章展现给读者的第一印象,不知道大家怎么看,反正我每次看到排版错乱的文章,往下读的兴趣直接减少了一半。

1552
来自专栏数据小魔方

rmarkdown+flexdashboard制作dashboard原型

R语言作为一门统计计算和数据可视化为核心特色的工具性语言,其在可视化领域或者说数据呈现方面有着非常成熟和系统的解决方案。

1063

扫码关注云+社区