Android浏览器(一)：Webkit项目与Chromuim项目
转载请注明原文地址：http://blog.csdn.net/u/article/details/ &&& &目前，移动设备浏览器上常用的内核有Webkit，Blink，Trident，Gecko等，其中iPhone和iPad等苹果iOS平台主要是WebKit，Android 4.4之前的Android系统浏览器内核是WebKit，Android4.4系统浏览器切换到了Chromium(内核是Webkit的分支Blink)，Windows Phone 8系统浏览器内核是Trident。1.WebKit项目(1)项目简介& & WebKit项目是苹果公司在2005年发起的一个新的开源项目，是Safari浏览器的内核，是目前的主流浏览器渲染引擎。WebKit项目具有结构清晰、易于维护等优点，WebKit简单灵活和便于引入新移植的特性，使其迅速称为主流的渲染引擎。(2)WebKit架构&&◆WebCore部分：包含了目前被各个浏览器所使用的WebKit共享部分，是加载和渲染网页的基础部分，具体包括HTML解释器、CSS解释器等。& ◆JavaScriptCore引擎：是WebKit中的默认JavaScript引擎。在Google的Chromium项目中，它被替换为V8引擎。&&◆WebKit Ports部分：是WebKit红的非共享部分，属于WebKit被移植的模块。由于不同浏览器使得平台差异、依赖的第三方库和需求不同，从而导致多种WebKit版本。&&◆WebKit嵌入式接口：指在WebCore和JavaScript引擎之上的一层绑定和嵌入式编程接口，可以被各种浏览器调用。2.Chromuim项目(1)项目简介& & Chromuim项目是Google公司以苹果开源项目WebKit作为内核，创建的一个新的项目，该项目的目标是创建一个快速的、支持众多操作系统的浏览器。在Chromium项目基础上，Google发布了自己的浏览器产品Chrome。与使用WebKit作为内核的Safari浏览器不同，Chromium本身就是一个浏览器，而不是Chrome浏览器的内核，再未从WebKit项目分离之前，Chrome浏览器使用的是WebKit内核。2013年4月，Google宣布从Webkit复制出来并独立运作Blink项目，该项目也就是目前Android4.4及以上系统浏览器采用的内核。(2)Blink内核& & Blink项目从WebKit分离出来后，其本身也是源于WebKit项目，只是Google将除Chromium浏览器需要之外的其他移植的代码都删除了，并且在Blink项目中加入了很多新的技术，部分技术如下：◆实现跨进程的iframe。iframe允许网页中嵌入其他页面，为了解决潜在的安全问题，为iframe创建一个单独的沙箱进程。◆重新整理和修改WebKit关于网络方面的架构和接口。◆将DOM树引入JavaScript引擎中。◆针对各种技术的性能优化，包括图形、JavaScript引擎、内存使用、编译的二进制文件大小等。(3)基于Blink引擎的Chromium浏览器结构& & 下图描述了Chromium的架构和主要模块，可知Blink只是其中的一个模块，和它并列的还有众多的Chromium模块，包括GPU/CommandBuffer(硬件加速架构)、V8 JavaScript引擎、沙箱模型、CC(Chromium合成器)、IPC、UI等。◆&Content模块&和&Content API(接口)&& &Content模块&和&Content API&将下面的渲染机制、安全机制和插件机制等隐藏起来，提供一个接口层，是Chromium对渲染网页功能的抽象，被内部的Chromium浏览器、Content Shell调用，是用来渲染网页内容的模块。◆&Chromium浏览和&Content Shell&&&Chromium浏览和&Content Shell&是构建在Content API之上的两个&浏览器&，Chromium具有浏览器的完成功能。&Content Shell&是使用Content API包装的一层简单的&壳&，用户可以使用Content模块来渲染和显示网页内容。◆Android WebView模块&&Android WebView模块是希望利用Chromiuim的实现来替换原来的Android系统默认的WebView.(2)内核特征& & 一个渲染引擎主要包括HTML解释器、CSS解释器、布局和JavaScript引擎、绘图等。◆HTML解释器：解释HTML文本的解释器，主要作用是将HTML文本解释成DOM(文档对象模型)树，DOM是一种文档的表示方法.◆CSS解释器：级联样式表的解释器，主要作用是为DOM中各个元素对象计算出样式信息，从而为计算最后网页的布局提供基础设施。◆布局：在DOM创建之后，WebKit需要将其中的元素对象同样式信息结合起来，计算他们的大小位置等布局信息，形成一个能够表示这所有信息的内部表示模型。◆JavaScript引擎：使用JavaScript代码可以修改网页的内容，也能修改CSS的信息，JS引擎能够解释JS代码并通过DOM接口和CSSOM接口来修改网页内容和样式信息，从而改变渲染的结果。◆绘图：使用图形库将布局计算后的各个网页的节点绘制成图形结果。&参考：(1)http://mogoweb.net/blog//analysis-of-android-4-4-webview-implementation/(2)朱永盛-《WebKit技术内幕》
最新教程周点击榜
微信扫一扫相信读者已经注意到了，在最新的Android 4.4 Kitkat版本中，原本基于Android WebKit的WebView实现被换成基于Chromium的WebView实现。在前面的章节中，笔者也介绍过基于Chromium的WebView实现即将成为Android系统上的缺省实现方式，笔者也一直期待这一重大转变，现在它真的发生了。而之前基于WebView接口的应用程序甚至可以直接工作在该实现上而不需要任何特别的改变。举个例子来说，Android系统上的缺省浏览器（AOSP中的浏览器），可以不需要任何改变直接工作在新的实现上。
WebView是一种嵌入式的编程接口，能够提供Java接口给开发者来使用该模块来渲染网页。现在的WebView只是一个接口类，通过一些内部设计的改变，其具体的实现可以在之前的Android WebKit和Chromium之间进行切换。新的Chromium实现专注于提供一致性的接口（为了兼容以前的应用），而内部的渲染引擎改为使用基于Blink/Content内核的引擎，这实现不管是从功能上还是性能来讲，都带来巨大的提升。为了支持WebView的工作方式，Chromium还是做了不少的改变的，例如前面提到的进程模型，渲染方式等，下面一一对他们作介绍。
在Android 4.4中，基于Chromium项目的WebView千呼万唤始出来。为了支持历史遗留的接口，Chromium还是做了很大改变的，让笔者结合下图的层次结构来解释基本的过程。
上图主要有四个部分，其中跟WebView相关的主要是上面三个部分，首先是WebView接口部分，它提供对外编程接口，同时它的内部实现可以基于桥接代码，也就是第二个部分。桥接部分的代码主要有两个作用，其一是实现WebView接口对实现的调用，第二是调用下面一层的代码，这里面有个重要的部分就是需要设置AwContents为了绘图而需要设置的两组函数数组，这个在渲染部分介绍。它的代码可以在frameworks/webview/chromium部分找到。以上两个部分都是AOSP部分代码，而第三个部分是AwContents是在Chromium项目中的，主要是构建被桥接代码使用的接口，这一部分主要基于Content接口，里面有很多不同于Chrome浏览器的实现。Android的开源代码为了编译上的方面，直接将Chromium 版本30代码包含到external/chromium_org目录中，有兴趣的读者可以自行查看。
同Chrome浏览器的比较
同Chrome浏览器比较，Chromium WebView在很多部分非常不一样，例如开源与否、HTML5功能、版本支持、进程模型、渲染方式等。下表分析了这二者的主要区别。
Chromium WebView
Chrome浏览器（Android版）
全部开源，包括内核，桥接层等
Java层部分的代码，包括用户界面的代码是闭源的，也就是说开发者是没有办法基于Chrome浏览器定制新浏览器，只可以基于Content层
目前不支持WebGL，WebRTC，WebAudio等
支持绝大多数HTML5功能（HTML5test得分超过450），包括WebGL，WebRTC，WebAudio等
仅能工作在Android4.4上，而且依赖于系统内部的函数，只能同Android AOSP一起编译，目前是Chromium 30的版本
能工作在&=Android 4.0，而且不需要依赖Android系统内部的函数。Chromium方面是跟随最新的代码。
支持多进程和单进程（不过，目前单进程工作还有些问题）
支持软件渲染和硬件加速渲染方式
目前只是硬件加速渲染方式
至于WebView内部所使用的Chromium实现是采用硬件加速渲染还是软件渲染，这里还是比较复杂的。根据Android的View结构，WebView的内容需要通过一个onDraw(Canvas c)来完成绘制。为了将Chromium渲染网页的结果绘制到该Canvas中，需要两组绘图函数组，第一组用来软件渲染，第二组用来硬件加速渲染。而这两组函数需要使用Android内部函数，这决定了目前WebView只能同Android AOSP代码一起编译，而不能像应用程序一样，只是依赖于Android SDK/NDK来编译。下图是当用户界面或者网页需要绘制的时候，绘图的基本过程。
这里Chromium的合成器具有两种能力，就是包含支持软件渲染的软件渲染器和硬件加速渲染的渲染器。当用户界面所对应的画布（canvas）是硬件加速的话，那么内部采用硬件渲染机制。如果不是硬件加速的话，那么采用软件渲染机制。当用户的界面设置为硬件加速的时候（开发者可以在应用程序的AndroidManifest.xml中设置属性android:hardwareAccelerated=&true&），那么用户界面对应的画布即为硬件加速，否则即为软件渲染方式。所以，具体Chromium WebView采用什么样的方式，取决于调用WebView的应用程序的设置方式。
值得提出的是，这里的硬件加速机制同Chrome浏览器的硬件加速机制是不一致的，因为Chrome浏览器为渲染网页使用的控件是Android的SurfaceView，根据Android系统的说明，SurfaceView是可以在不同的线程来绘制的(One of the purposes of this class is to provide a surface in which a secondary thread can render into the screen)，请读者阅读这里了解背后的原理/reference/android/view/SurfaceView.html。由此，Chrome浏览器是首先获取SurfaceView的Surface对象的句柄（ID），然后由Chrome浏览器的GPU线程来绘制网页。这样，网页的渲染工作同主线程完全隔离开来了，不会因为网页的渲染而阻碍用户界面的响应。
而在Chromium WebView的实现中，因为WebView不是基于SurfaceView类的（因为历史遗留问题），所以，绘制内容到画布上必须在主线程来操作，有鉴于此，这些渲染任务只能在主线程上工作，可能在某种程度上会阻碍用户界面的响应，这是一个重大缺陷。根据笔者的数据来看，目前它的性能同Chrome浏览器/Content Shell也有一定的差距，考虑使用它的读者可能需要权衡一下。
因为WebView采用单进程的渲染方式并省略了一些共享内存和进程间通信的基础设备，所以可以节省一些内存使用空间，Chromium的官方也给出了一些数据，例如打开一个空白页，WebView目前只是需要33MB内存，而Chrome浏览器需要大概49MB，而单进程模式的Chrome浏览器需要大概45MB内存，还有更多详细的数据，有兴趣的读者可以进行参考和一些分析。
基于WebView的浏览器和基于Content接口的浏览器
目前Android默认浏览器（Stock Browser）是基于WebView接口，因为ChromiumWebView的实现被直接用于默认浏览器中，所以继承了ChromiumWebView的一些缺点，例如多标签页也只是在同一进程中工作，没有沙箱模型的支持等，性能也要差不少。而Chrome浏览器的Android版是基于Content接口的多进程方式工作的，因而保留了稳定性好，安全等好处。
/chrome/mobile/docs/webview/overview
/platform/external/chromium_org/
本文目前还没有评论……Chromium/Blink Rendering（15）
转载请注明原文地址：http://blog.csdn.net/yunchao_he
Google Chrome是当今最流行的浏览器之一，它实现并推动了最新的HTML5标准和Web开发技术。Chrome背后的开源项目是Chromium，其绘制引擎(render engine)从Webkit中克隆出来，名为Blink。而WebKit是苹果公司主导的网页渲染引擎，用于Safari, WKWebView等众多浏览器或相关组件中。作为开源项目，Chromium和WebKit也是当今IT界最有影响力、最活跃的几个开源项目之一。
本人从事Chromium/Blink/Webkit相关工作多年，因此对Chrome内核有一定了解，特别是对绘制有关的内容有深入研究。本人打算根据自己所学所知，撰写《Chrome内核解析》系列文章，作为自己的学习笔记，也一并分享出来和同行探讨。内容如有谬误，欢迎指正。
首先将从我最熟悉的绘制部分写起。作为浏览器内核的重要组成部分，绘制引擎的内容非常复杂。特别是对于Chromium这样的现代浏览器，在它的多进程构架下，网页的绘制分散在众多进程、线程和模块中，看起来更加纷繁复杂。在深入介绍绘制部分之前，也有必要大致介绍下和绘制相关的背景。所以先由背景篇开始，然后介绍Chrome内核的绘制部分。如有可能，后续将介绍Chrome的2D图形库Skia, Chrome for Android, Chromium WebView, Chrome的JS引擎V8, 以及一些知名的Web开发框架或游戏引擎，比如Three.js,
Unity3D-HTML, Cocos2D-HTML, Box2D, JQuery等等。&
Chrome Internal 将分为以下章节：
第一部分：背景篇
第一节：Chrome, Chromium, WebKit, WebKit2, Blink
第二节：Chromium的多进程构架
第三节：Chromium启动与资源加载
第四节：HTML, CSS, JavaScript的解析与执行
第五节：DOM Tree与Render Tree, RenderLayer与GraphicsLayer
第六节：布局(Layout)
第七节：绘制(Rendering, Drawing, Painting, Rasterization/Blitter, Compositing)
第二部分：绘制引擎基础篇
第一节：绘图上下文(GraphicsContext)及虚拟上下文(Virtual Context)
第二节：图形上下文相关的基础设施：GL Context, Texture, Buffer等。
第三节：Command Buffer
第四节：angle project
第五节：Canvas2D
第六节：Skia
第七节：WebGL
第八节：Resizing, Scrolling, Base Layer, Tiling
第九节：CSS
第十节：Video
第三部分：绘制引擎高级篇
第一节：vsync及进程间同步
第二节：Threaded compositing与Impl-side Painting
第三节：Gpu Rasterization
第四节：(delegated renderer) ubercompositor
第五节：Zero-copy
第四部分：绘制引擎应用篇
第一节：Layout Test
第二节：Telementry
第三节：Profiling
第四节：perf
第五部分：开放篇
第一节：Chromium WebView
&第二节：Chromium on Android(SurfaceView, TexutreView, SurfaceFlinger)
第六部分：Skia
参考文档主要为：
1. Chromium/Blink/WebKit源代码 (代码是最好的文档）
2. Chromium Graphics:&http://www.chromium.org/developers/design-documents/chromium-graphics
3. Chromium设计文档:&http://www.chromium.org/developers/design-documents/
4. 朱永盛的博客:&http://blog.csdn.net/milado_nju
5. 闵洪波的博客:&http://blog.csdn.net/hongbomin/
6. 《WebKit技术内幕》， 朱永盛著
7. 尹立的博客:&http://blog.csdn.net/yl02520/
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：5275次
排名：千里之外
原创：15篇
何云超，专注于Web技术，包括HTML5, Chromium, Blink/WebKit, Skia等技术或项目。 是Skia项目的committer, Chromium/V8项目的contributor。对Graphics和Android也有所涉猎。现就职于Intel，定居中国上海。
(3)(1)(10)(2)理解WebKit和Chromium: Canvas2D及其实现
理解WebKit和Chromium: Canvas2D及其实现
5067人阅读
转载请注明原文地址：
# Canvas 2D及其在WebKit和Chromium中的实现
Canvas是HTML5新引入的元素，它是一个画布。开发者可以用JavaScript脚本在该元素上绘制任意图形（2D或者3D）。
Canvas元素有两个属性“width”和“height”，用来设置画布的宽度和高度。Canvas本身来讲并没有定义绘制图形的动作和行为，只是提
供了一个获取绘图的上下文（context）对象的方法－getContext来获取绘制2D或者3D上下文。
Canvas的‘getContext’方法包含一个参数，该参数用来指定创建上下文对象的类型。对于2d的图形操作，通过传递参数值’2d’，浏
览器会返回一个2d的绘图上下文，称为CanvasRenderingContext2D， 它提供了用于绘制2d图形的各种API，
包括基本图形绘制（例如线，矩形，圆弧），文字绘制，图形变换，图片绘制及合成等。我们把以上这些称之为Canvas2D。下图是一个使用
Canvas2d的简单例子，后面的讨论都会基于它来进行。
Canvas 2D是HTML5草案的一部分，被众多的浏览器所支持， 包括chrome, IE， Firefox， Safari等等。
不仅如此，越来越多的浏览器开始支持在Canvas中绘制3D图形，该部分规范由Khronos组织定义。
也就是，通过传入适当的参数来调用Canvas的getContext函数以创建3D上下文对象用于绘制3D图形，
目前不同的浏览器支持不同的参数，例如chromium支持“webkit-3d”和”experimental-webgl”。
值得注意的是，2D和3D是互斥的，不能同时在同一个canvas中操作它们，也就是说，当创建了一个2D的上下文对象后，你不能再为其创建3D的
上下文，反之亦然。本章将重点介绍Canvas 2D方面的只是及在WebKit和chromium中的实现， Canvas
3D也就是WebGL将在下一章中作介绍。
&## CanvasRenderingContext2D 介绍
前面说到，CanvasRenderingContext2D是2d图形绘制的上下文对象，其提供了用于绘制2d图形的API，W3C工作组起草了
标准的草案，详细见参考文献2。该对象由JavaScript代码创建后，JavaScript便可以调用它的API在画布上绘制图形了。这些API主要
的作用就是在画布上绘制点，线，矩形，弧形，图片等等，除此之外，还提供了这些绘制的样式和合成效果等。下面按类简单介绍一下它所包含这些API。
第一部分，如下两个函数save和restore用来保存或者恢复2D上下文的状态；
第二部分，用来设置变换参数，例如缩放，旋转，平移等，这些构成了一个变换矩阵，缺省是Identity矩阵；
第三部分，对象的两个属性globalAlpha和globalCompositeOperation，用来设置alpha值和合成模
式，alpha值表示将要绘制图形的透明度，合成模式表示将要绘制的图形和绘制对象如何合成，合成模式有多种，例如source-over,
source-in, source-out, destination-over,destination-in,
destination-in等等；
第四部分，有关设置颜色和样式，包括两个属性strokeStyle, fillStyle，gradient, pattern, 用来表示笔画和填充的格式，变化率，和用来填充图片的模式
第五部分，有关线的样式属性，它们包括线宽度，线端样式及其线与线的连接方式等；
第六部分，有关阴影方面的属性，这是全局的，影响所有绘制的图形；
第七部分，绘制矩形的相关操作，包括清除矩形区域，填充和绘制矩形边框；
第八部分，Path相关的操作，用来绘制自定义的路径的图形，这可以是图形可以是直线，弧形，曲线等；
第九部分，与文字相关的操作，包括字体，文字对齐方式等属性和绘制文字等操作；
第十部分，绘制图像到画布上，图像来源可以Image元素，Canvas元素，或者是Video元素。通过设置的样式，可以把待绘制的图像以不同的方式绘制到目标的Canvas上；
第十一部分，有关像素方面的操作，包括ImageData创建，以及从canvas读取内容创建ImageData和把ImageData内容写到canvas；
第十二部分，定义与上面一些API相关的类（接口），例如CanvasGradient，CanvasPattern等，这些类街头连同上面的API都被定义WebIDL格式。
通过以上解释，那么canvas2d例子中的代码就比较容易理解了。那段JS代码首先创建一个2D的上下文对象，然后设置填充的颜色为红色，最后填
充一个80x100的矩形内部为红色。你可以尝试把例子放在chromium里面运行然后看看能得到什么。值得提醒的是，当画布的宽度或者高度发生改变
时，该画布上的所有绘制的内容都将被移除。
&## WebKit和Chromium的支持
W3C定义了2D context标准的草案， 这些接口保存在IDL文件中。
WebKit根据这IDL来直接生成相关的C++类的代码，这些类包括CanvasRenderingContext2D,CanvasPattern,
CanvasGradient, ImageData, TextMetrics等，
它们和标准中的接口一一对应，你可以在WebKit/Source/WebCore/html/canvas中找到它们。那么它们被JS中的代如何码调用
的呢？答案是生成JavaScript绑定。
Canvas2D上下文类的具体绘制动作由实现平台决定， 其由软件或者硬件来完成取决于移植。下面， 我们来看看WebKit如何支持Canvas2D以及如何提供合适的接口将实现交给移植来完成的。
首先，大致理解一下WebKit和chromium中支持Canvas2D的重要的类模块和它们之间关系，如下图所示。同以前一样， 包括WebKit的基础类和与平台相关的绘图类及支持canvas2D硬件加速的类。
让我们简单了解一下这些类的作用：
WebKit端：
HTMLCanvasElement：DOM中的对应着HTML5 的canvas元素，该类包含有关为2D或者3D
context服务的相关接口，主要的作用创建JS使用的2D或者3D上下文对象，绘图的平台无关的GraphicsContext对象，后端存储的
GraphicsContext：WebKit的平台无关的上下文类，用于绘制工作，具体调用平台相关的上下文类来实现绘制
PlatformGraphicsContext：平台绘制上下文类，不同的平台有不同的实现，在chromium中是PlatformContextSkia
ImageBuffer：WebKit平台无关后端存储类，不同平台会定义不同的结构，在chromium中会使用SkCanvas
RenderHTMLCanvas：RenderObject的子类，为canvas而设计的
Chromium端：
PlatformContextSkia： Chromium中的PlatformGraphicsContext类
SkCanvas：skia画布，包含所有的绘制状态，使用SkDevice来绘制图形
SkDevice：设备类，包含一个SkBitmap作为后端，利用光栅扫描算法来生成像素值保存于后端存储中，用于软件绘制方案
SkGpuDevice：设备类，包含一个绘制的目标对象，通过GrContext来绘制，其利用硬件加速的GL库来绘制2D图形
GrContext:& GPU绘制的上下文类，包含一个平台相关的3D上下文成员
Canvas2DLayerChromium:LayerChromium的子类，包含一个硬件加速的Canvas2D层
其他类：之前介绍过，不再赘述
上图中加速部分相关的GraphicsLayer, CCLayerImpl等，因为在之前介绍过，为方便起见，图中省略了它们。
Chromium中的Canvas2D的绘制操作的实现都是由图形库skia来完成，这里包括软件和硬件加速实现，chromium所要做的就是把WebKit中的调用交给skia来执行并和自己的绘制模型和硬件加速机制集成起来。
那么如何打开或者关闭Canvas2D的硬件加速功能呢？
Chromium中提供了两个选项，分别是“--disable-accelerated-2d-canvas”和“--enable-
accelerated-2d-canvas”，用户可以通过查看“about://gpu”来确认。
在介绍了基础设施之后，下面来看看具体的软件和硬件加速如何实现Canvas2D的。后面的软件实现和硬件加速实现都基于本章开始的canvas例子来说明。
&## Canvas 2D的软件实现
这里我们以本章中的Canvas2D的例子来说这个过程。
首先，当执行到JS代码中的canvas.getContext时，WebKit通过V8
JS绑定会调用HTMLCanvasElement.getContext。该函数根据传入的参数来决定创建2D或者3D的上下文对象。 在这里，
CanvasRenderingContext2D对象会被创建。此时其他有关的对象例如ImageBuffer，GraphicsContext等不会
被创建，直到后面使用到时才会被创建，这是WebKit的做事原则。
其次，当设置fillStyle属性时，WebKit同样通过V8
JS绑定调用CanvasRenderingContext2D.setFillStyle，在这种情形下，2D上下文对象会开始创建相关对象（在软件实
现情况下，上图中右侧框中的对象不会被创建，包括ImageBuffer， GraphicsContext，
PlatformContextSkia， SkCanvas，SkDevice和 SkBitmap）。
当执行JS的fillRect时，CanvasRenderingContext2D调用GraphicsContext来完成绘制。
这两个类是WebKit的基础类，GraphicsContext需要有不同移植来具体实现绘制工作，在chromium中，这就是
PlatformContextSkia。该类是一个转接口，调用skia来绘制。SkCanvas根据之前设定的样式，由SkDevice利用光栅扫描
法来计算生成相应的像素值，结果保存在一个SkBitmap中。
最后，当fillRect操作调用完成之后，会安排一个Invalidate相关区域的命令。而后，当该命令被执行了，WebKit会遍历
RenderLayer依次绘制RenderObject的内容，当绘制Canvas元素时，会把之前Canvas绘制在SkBitmap的内容绘制到网
页的Bitmap上（该bitmap通过共享内存机制会被Browser进程绘制在Tab子窗口中）。下图显示的是当有更新请求时，WebKit遍历
RenderLayer树和Render树来绘制网页及Canvas的详细调用过程。
## Canvas 2D的硬件加速实现
在硬件加速实现Canvas情况下，有一些地方是相似的，下面主要介绍它们的不同之处。
首先，硬件加速需要创建更多的对象和设施，主要有两点，一是如前面章节介绍的，会为Canvas元素创建一个新的RenderLayer及其相应的
GraphicsLayer，Canvas2DLayerChromium，CCLayerImpl等。二是因为利用GL来渲染，所以为skia的
SkCanvas创建一个SkGpuDevice, GrTexture,
GrContext来使用GL绘制2D图形，同时，跟合成器一样，它也会创建3D的上下文对象-
WebGraphicsContext3DCommandBufferImpl，
将skia的GrContext，
GrTexture等对gl调用转发给GPU进程，具体的创建过程可参考ImageBufferSkia.cpp文件中的
createAcceleratedCanvas函数。
其次，当调用fillRect时，canvas的内容由SkCanvas调用SkGpuDevice将其绘制在Texture，当然这些GL的操作
都通过WebGraphicsContext3DCommandBufferImpl交给GPU进程来完成绘制。最后，会请求一个更新某个区域的任务。
最后，更新请求会调度合成操作，其首先调用Canvas2DLayerImpl::paintContentsIfDirty绘制自己，然后将Canvas的Texture合成起来生成网页内容。
&## 源文件目录
WebKit/Source/WebCore/html/canvas/
& & & & & &WebKit支持Canvas相关的类，包括支持2D和3D上下文及其所涉及的其他类
WebKit/Source/WebCore/platform/graphics/skia/
&&&&&&&&&& 实现WebKit中的平台相关的2D图形功能，Canvas2D在chromium中的实现依赖skia图形库
&## 参考文献
1.&&&&&&HTML5 canvas element
2.&&&&&&Canvas2D context
3.&&&&&&WebKit HTMLCanvasElement
&By &yongsheng@chromium.org
上一篇下一篇
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：196096次积分：2451分排名：第4650名原创：40篇转载：0篇译文：0篇评论：254条
Mail: yongsheng@chromium.org
朱永盛，Chromium Committer，著有，专注HTML5、WebKit和Chromium、Android等方面技术。现就职于阿里巴巴，曾就职于英特尔公司并工作于GitHub开源项目。
文章：37篇
阅读：187995
(1)(1)(1)(1)(1)展开
发表评论：
TA的最新馆藏[转]&[转]&[转]&