专栏首页程序员互动联盟【专业技术】chromium GPU 硬件加速合成

【专业技术】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),作者:typename

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 程序员动辄几万的工资真的是虚高吗?

    程序员的工资除了自身技能影响之外,主要还是市场决定的,软件开发的作用可以无限放大,也可以无限大也可以无限小,软件开发工资得决定因素非常多,根据多年的开发经验决定...

    程序员互动联盟
  • 中国程序员真的比印度程序员差嘛?

    随着科技的进步,编程已经越来越多变得更加具有普及性了,程序员也慢慢变得不再那么神秘了,程序员给大家的印象就是做下能一天不起来,平时沉默寡言,说话比较刻板,这是中...

    程序员互动联盟
  • 毕业后想拿高工资,看来需要这么干

    相对于高中来说,大学比较自由,是脱离父母,单独生活的开端。很多人都萌生了挣钱的想法,一个原因可能是因为家里条件,一个可能是想提前体验一下自己养活自己。 大学是一...

    程序员互动联盟
  • 50.4 AP!FCOS再升级!简单而强大的anchor-free目标检测器

    FCOS+DeformConv2+ResNeXt101+BiFPN 在COCO上能刷到50.4 AP!

    Amusi
  • 深入玩转K8S之如何访问业务应用(Traefik-ingress配置https篇)

    上篇我们简单介绍了下traefik以及如何http访问, 但是在实际生产环境中不仅仅只是http的转发访问,还有https的转发访问,

    DevinGeng
  • FCOSv2.0强势归来!在COCO上达到50.4mAP(目前已开源)

    FCOS+DeformConv2+ResNeXt101+BiFPN 在COCO上能刷到50.4 AP!

    深度学习技术前沿公众号博主
  • 领域驱动设计,让程序员心中有码

    作为一名资深软件行业从业者,我以前一直从事项目开发。在项目执行过程中,往往会采用快速开发模式,按照软件工程的基本流程建立一套项目软件管理模式。

    歪脖贰点零
  • golang 格式“占位符”%d,%f,%s等应用类型

    golang 的fmt 包实现了格式化I/O函数,类似于C的 printf 和 scanf。 红色部分为常用占位符 ? ? ? ? ? ? ? 对于 ...

    学到老
  • golang 格式“占位符”%d,%f,%s等应用类型

    golang 的fmt 包实现了格式化I/O函数,类似于C的 printf 和 scanf。 红色部分为常用占位符

    学到老
  • 【典型案例】利用决策树实现乳腺癌预测助你成为半个医学专家

    乳腺癌是美国妇女最常见的癌症,也是癌症死亡的第二常见原因。利用机器学习算法从已有的临床乳腺癌数据中,可以学习导致乳腺癌的特征,并通过大量历史数据的学习使得机器成...

    腾讯智能钛AI开发者

扫码关注云+社区

领取腾讯云代金券