chromium for android v34 2dCanvas硬件绘制及硬件渲染实现分析

HTMLCanvasElement对应h5的canvas元素。

解析网页遇到canvas元素会创建HTMLCanvasElement实例。

Canvas可以支持2d和3d图形的绘制。

HTMLCanvasElement提供了getContext()接口,返回图形绘制的上下文对象,

对于2d图形返回的是CanvasRenderingContext2D。

CanvasRenderingContext2D提供了网页可调用的所有绘制动作。

CanvasRenderingContext2D的所有绘制命令都转接给了

HTMLCanvasElement::drawingContext()提供的绘制上下文。

HTMLCanvasElement是整个Canvas实现的入口。

我们从这里入手理出2dCanvas的硬件绘制及硬件渲染架构。

一.硬件绘制的实现结构

硬件绘制是指,网页调用的绘制动作,通过HTMLCanvasElement

转给skia库,skia库通过调用GPU命令完成实际的绘制操作。

软件绘制是指skia库在cpu上完成绘制操作。

完成硬件绘制需要:

1.建立HTMLCanvasElement与skia库的GrContext(skia硬件绘制上下文)之间的联系。

2.建立skia库GrContext与GPU之间的联系。

3.创建保存硬件绘制结果的Texture.

完成这3件事,网页调用HTMLCanvasElement的绘制命令经由Skia库调用

实际的GPU操作绘制到保存绘制结果的Texture上。

1.建立HTMLCanvasElement与skia库的GrContext(硬件绘制上下文)之间的联系。

Skia的GrContext封装在webkit::gpu:: GrContextForWebGraphicsContext3D类中。

创建过程如下图:

GrContext是在Canvas2DLayerBridge::create中被创建并保存在SkGpuDevice中。

GrContext创建过程涉及的类图:

GrContext是在Canvas2DLayerBridge::create中被创建并保存在SkGpuDevice中。

GrContext创建过程涉及的类图grcontextwrap.jpg。

CanvasRenderingContext2D的绘制动作转接给刚刚创建的GrContext的过程

(以CanvasRenderingContext2D的fillRect()为例),可以分为三步(A,B,C):

A.CanvasRenderingContext2D::fillRect()--->Canvas2DLayerBridge::create()

中创建的SkDeferredCanvas::drawRect()。

CanvasRenderingContext2D的fillRect()通过HTMLCanvasElement::drawingContext()

传给了ImageBuffer中创建的GraphicsContext,GraphicContext又进一步调用

它包含的SkCanvas::drawRect().GraphicContext包含的SkCanvas是

Canvas2DLayerBridge中创建的SkDeferredCanvas。

这个过程中涉及到的类图:

B.SkDeferredCanvas::drawRect()--->DeferredDevice:: fImmediateCanvas::drawRect()

SkDeferredCanvas::drawRect()调用的是SkDefferdCanvas创建的DeferredDevice中

包含的成员变量SkCanvas* fImmediateCanvas的drawRect().我们看这个fImmediateCanvas的来源.

SkDefferdCanvas创建时传入了SkSurface_Gpu实例作为参数。

SkDeferredCanvas::Create()中以SkSurface_Gpu为参数创建了DeferredDevice。

并将这个DeferredDevice传递给了SkCanvas.可以通过SkCanvas的getDevice()

接口得到DeferredDevice实例。所以DeferredDevice成员变量SkCanvas* fImmediateCanvas是

在SkSurface_Gpu::onNewCanvas()中创建的SkCanvas,并传入了SkGpuDevice作为参数。

这个过程涉及的类图:

C.DeferredDevice:: fImmediateCanvas::drawRect()--->SkCanvas::drawRect().

接下来看以SkGpuDevice为参数创建的SkCanvas的drawRect()的执行流程。

到这,终于看到,CanvasRenderingContext2D的绘制动作转给了GrContext。

2.建立skia库GrContext与GPU之间的联系。

由GrContext的创建过程我们知道GrContetxt被封装在GrContextForWebGraphicsContext3D实例中。

GrContextForWebGraphicsContext3D的构造函数中传入了

WebGraphicsContext3DCommandBufferImpl实例。

chromium for android GPU进程结构分析我们知道,

WebGraphicsContext3DCommandBufferImpl是与GPU进程(线程)通信的入口。

GrContextForWebGraphicsContext3D的构造函数中

GrContext与WebGraphicsContext3DCommandBufferImpl的关联是通过GrGLInterface建立的。

GrGLInterface包含与opengl es对应的接口。

WebGraphicsContext3DCommandBufferImpl::createGrGLInterface()调用

skia_bindings::CreateCommandBufferSkiaGLBinding()生成GrGLInterface,

并将GrGLInterface包含的接口绑定到WebGraphicsContext3DCommandBufferImpl对应的接口上。

GrGlInterface被传给了GrContext.这样在GrContext中通过GrGlInterface调用的操作

实际调用的是WebGraphicsContext3DCommandBufferImpl的gl操作,

并由WebGraphicsContext3DCommandBufferImpl通过CommandBuffer结构调用到

实际的GPU进程(线程中)中提给的真正gl操作。参见chromium for android GPU进程结构分析。

下图是GrContext::drawRect()调用到WebGraphicsContext3DCommandBufferImpl的gl操作的过程:

3.创建保存硬件绘制结果的Texture.

以下是具体创建过程:

这个texture由GrGpuGL::onCreateTexture()调用WebGraphicsContext3DCommandBufferImpl

接口GenTextures()生成,并保存在GrGLTexture实例中。

二.2dcanvas硬件渲染架构

时间: 2024-11-12 13:39:51

chromium for android v34 2dCanvas硬件绘制及硬件渲染实现分析的相关文章

chromium for android v34 2dcanvas硬件渲染实现分析

这篇接着上一篇2dcanvas硬件绘制,分析保存绘制结果的texture被合成到on screen framebuffer上的过程. 1.webkit为canvas元素相应的render树节点RenderHTMLCanvas, 创建RenderLayer的步骤例如以下: RenderLayerModelObject::createLayer()调用 RenderLayer::insertOnlyThisLayer()将创建完 的RenderLayer增加到renderlayer tree中. 2

android4.4 webview chromium与chromium for android硬件渲染的异同

相同点: android4.4 webview chromium的渲染流程与chromium for android硬件渲染流程全解析(render进程)中总结的五个子流程完全一致. android4.4 webview chromium的渲染流程也是这五个子流程组成的. 不同点: 1.android4.4中网页渲染的驱动还是android的UI系统控制的.即WebView.onDraw()是渲染的入口.chromium for android没有用到WebView控件,绘制的驱动完全由底层ch

chromium for android 硬件渲染流程总结

render进程中 一.webkit模块 webkit引擎会为网页内容同时创建Dom tree, Render tree和RenderLayer tree. 这三棵树之间的关系参见chrome硬件渲染 每一个Render Object都关联着一个RenderLayer.Render Object与RenderLayer是多对一的关系. RenderLayer代表了网页某一层的内容.正是由于RenderLayer的存在,网页上的元素才可以按照 正确的顺序合成,从而恰当的显示有交叠的内容,和半透明元

Chromium on Android: Android L平台上WebView的变化及其对浏览器厂商的影响分析

摘要:Android L平台在图形渲染方面有一项重要的改进,它引入了一个专门的线程用于执行渲染工作,UI线程负责生成的显示列表(DisplayList),渲染线程负责重放(playback)这个显示列表绘制最终的内容,因此Chromium WebView在图形栈的实现方面也作了相应的调整,以支持Android L系统上新的渲染线程模型.本文将深度分析Chromium WebView的渲染流水线是如何无缝整合到Android L系统的渲染模型中,以及对目前市场主流浏览器厂商将会产生什么样影响等问题

Android应用自定义View绘制方法手册

背景 这篇迟迟难产的文章算是对2015前半年的一个交代吧,那时候有一哥们要求来一发Android Canvas相关总结,这哥们还打赏了,实在不好意思,可是这事一放就给放忘了,最近群里小伙伴催着说没更新博客,坐等更新啥的,随先有这么一篇Android应用开发超级基础的文章诞生了(因为这种文章最好写哈,就是用熟了就行).不得不说下这么久为何一直没更新博客的原因了,首先遇上了过年,我个人崇尚过节就该放下一切好好陪陪亲人,珍惜在一起的时光:其次今年开年很是蛋疼,不是不顺当就是深深的觉得被坑,所以心情也就

Android中View的绘制过程 onMeasure方法简述

Android中View的绘制过程 当Activity获得焦点时,它将被要求绘制自己的布局,Android framework将会处理绘制过程,Activity只需提供它的布局的根节点. 绘制过程从布局的根节点开始,从根节点开始测量和绘制整个layout tree. 每一个ViewGroup 负责要求它的每一个孩子被绘制,每一个View负责绘制自己. 因为整个树是按顺序遍历的,所以父节点会先被绘制,而兄弟节点会按照它们在树中出现的顺序被绘制. 绘制是一个两遍(two pass)的过程:一个mea

Android 中View的绘制机制源码分析 一

尊重原创: http://blog.csdn.net/yuanzeyao/article/details/46765113 差不多半年没有写博客了,一是因为工作比较忙,二是觉得没有什么内容值得写,三是因为自己越来越懒了吧,不过最近我对Android中View的绘制机制有了一些新的认识,所以想记录下来并分享给大家.在之后的几篇博客中,我会给大家分享如下的内容: 1.View中measure(),layout(),draw()函数执行过程分析,带领大家详细分析View的尺寸测量过程,位置计算,并最终

Android中使用ListView绘制自定义表格(2)

上回再写了<Android中使用ListView绘制自定义表格>后,很多人留言代码不全和没有数据样例.但因为项目原因,没法把源码全部贴上来.近两天,抽空简化了一下,做了一个例子. 效果图如 一.功能: 1.支持列合并 2.考虑了界面刷新优化 3.预留部分接口 4.支持左右滚动 1.枚举类:CellTypeEnum package csdn.danielinbiti.custometableview.item; public enum CellTypeEnum { STRING //字符 ,DI

【转】Android中View的绘制过程 onMeasure方法简述 附有自定义View例子

Android中View的绘制过程 当Activity获得焦点时,它将被要求绘制自己的布局,Android framework将会处理绘制过程,Activity只需提供它的布局的根节点. 绘制过程从布局的根节点开始,从根节点开始测量和绘制整个layout tree. 每一个ViewGroup 负责要求它的每一个孩子被绘制,每一个View负责绘制自己. 因为整个树是按顺序遍历的,所以父节点会先被绘制,而兄弟节点会按照它们在树中出现的顺序被绘制. 绘制是一个两遍(two pass)的过程:一个mea