Chromium网页CPU光栅化原理分析.docVIP

Chromium网页CPU光栅化原理分析 Chromium除了支持网页分块GPU光栅化，还支持CPU光栅化。GPU光栅化的特点是快，缺点是硬件之间可能会导差异性，以及不是所有的绘图操作硬件都能很好地支持。CPU光栅化的特点是通用，以及能够支持所有的绘图操作，缺点是较慢，特别是在网页使用硬件加速渲染的情况下，CPU的光栅化结果还需要上传到GPU去渲染。本文接下来将详细分析CPU光栅化的原理，着重描述它是如何快速地光栅化结果上传到GPU去的。 从前面一文可以知道，网页分块的光栅化过程，实际上是执行之前所记录的分块绘制命令，最终得到一个包含RGB值的图形缓冲区，如下所示： 在CPU光栅化方式中，CPU将网页分块绘制一个图形缓冲区中。这个图形缓冲区需要进一步交给GPU渲染，才能显示在屏幕中。一般情况下，CPU访问的是系统内存，而GPU访问的是显卡内存。CPU将数据提交给GPU，需要执行的一个操作是将数据从系统内存拷贝到显卡内存。这个操作也称为GPU上传操作。 相比于GPU渲染操作，GPU上传操作是一个非常慢的过程。典型的GPU上传操作是纹理上传。纹理数据通常比较大，因此将它们上传到GPU去就会是一个性能问题。网页分块CPU光栅化完成后得到的图形缓冲区就相当于是一个纹理数据。因此在CPU光栅化过程中，也会碰到影响性能的纹理上传问题。 为了解决纹理上传慢的问题，Android平台提供了一种Native Buffer，也称为Graphic Buffer。Graphic Buffer有一个很好的特性，就是它既可以被CPU访问，也可以被GPU访问。因此，如果我们为每一个网页分块都分配一个Graphic Buffer，并且将每一个网页分块都光栅化在各自的Gaphic Buffer中，那么就可以免去将光栅化结果上传给GPU的步骤，从而大大地提高网页的渲染效率。这种CPU光栅化方式就得名为Zero Copy光栅化方式，也称为Image Raster方式。 通常，好的东西都是有代价的。Graphic Buffer也不例外，它不像系统内存一样，可以大量地使用。为了减少Graphic Buffer的使用，Chromium只申请临时使用的Graphic Buffer，并且为每一个网页分配一个纹理对象。每一个网页分块都光栅化在临时使用的Graphic Buffer中，并且在光栅化完成后，会将临时使用的Graphic Buffer的内容拷贝到各自的纹理对象中去，然后将临时使用的Graphic Buffer释放掉。注意，这个拷贝操作是在GPU内部完成的，因此它的执行过程很快，不像纹理上传操作那样存在性能问题。这种CPU光栅化方式就得名为One Copy光栅化方式，也称为Image Copy Raster方式。 有些Android手机，虽然本身提供了Graphic Buffer，但是只允许系统使用，不允许App使用。在这种情况下，Chromium只能将网页分块光栅化在一个CPU能够访问的Pixel Buffer中。光栅化完成之后，再将这个Pixel Buffer上传到GPU去渲染。这样就避不开纹理上传慢的问题了。这种CPU光栅化方称为Pixel Buffer Raster方式。 从前面的分析就可以知道，CPU光栅化方式有三种，分别是Image Raster、Image Copy Raster和Pixel Buffer Raster。接下来，我们分别对它们的实现原理进行分析。 1. Image Raster 从前面一文可以知道，当使用Zero Copy光栅化方式时，CC模块会创建一个ImageRasterWorkerPool对象来执行光栅化任务。从前面文章中一文又可以知道，在执行光栅化任务的过程中，ImageRasterWorkerPool类的成员函数AcquireCanvasForRaster会被调用来创建一个画布，如下所示： [cpp] view plain copy 在CODE上查看代码片派生到我的代码片 SkCanvas* ImageRasterWorkerPool::AcquireCanvasForRaster(RasterTask* task) { return resource_provider_-MapImageRasterBuffer(task-resource()-id()); } 这个函数定义在文件external/chromium_org/cc/resources/image_raster_worker_pool.cc中。 参数task指向的是一个RasterTas