Chromium CC部分浅析（三）
3.2 工作流程
chromium24和26在流程上的主要区别就是，26中painting被分成了record和raster两步。
24中，painting过程发生在main线程（即上述的更新过程），26中record在main线程中执行，而将raster移到了impl线程。如图所示：
painting过程是webkit将网页内容用skia绘制成skbitmap的过程。record与painting的区别是，在绘制时不是使用skcanvas，而是使用其一个子类SkPictureRecord，该类中所有绘制操作都没有被真实执行，而是被记录进skpicture。
3.2.1 Record（Painting）
略
3.2.2 Rasterization（Painting）
根据skpicture来绘制出skbitmap。
这里还要说一下，现在绘制出的skbitmap是整个layer的，与tile还没有什么关系。
3.2.3Upload
当前viewprot所涉及的tile所包含的skbitmap被放到共享内存，来供GPU使用。这个过程就是upload。 下面是chromium24 upload的一个调用堆栈：
#0 cc::TextureUploader::uploadWithMapTexSubImage
#1 cc::TextureUploader::upload
#2 cc::ResourceProvider::upload
#3 cc::PrioritizedTexture::upload
#4 cc::ResourceUpdateController::updateTexture
#5 cc::ResourceUpdateController::updateMoreTexturesNow
#6 updateMoreTexturesIfEnoughTimeRemaining cc/resource_update_controller.cc:267
#7cc::ResourceUpdateController::updateMoreTexturesIfEnoughTimeRemaining
#8 cc::ResourceUpdateController::performMoreUpdates
#9 cc::ThreadProxy::beginFrameCompleteOnImplThread
chromium26据说对upload过程有一些调整，还没有详细研究。
3.2.4 Commit
commit过程是将main线程的layer树同步到impl线程的layerimpl树的过程。通常发生在layer树更新之后。当然具体什么时候发送由状态机类scheduler来控制。commit发生的比较频繁，而且在commit时，main线程需等待impl线程同步完成，所以commit过程应该对CC性能有一些影响。
Commit过程如图所示：
按理说一个简单网页，如果页面没有任何变化，那么在滚动过程中，这些树结构（包括layer树，layerimpl树）都没有变化。那么就不需要进行painting，commit等过程。实际调试过程中，paiting确实不再执行，但commit还会执行。
chromium26据说大大减少了commit的次数。
3.2.5 Draw
Draw过程是实际的绘制流程，主要分为prepareToDraw，drawLayers，swapBuffers这三步。其中包括一些计算，还有一些专业性较强的内容，这个流程没有详细研究了。
-
后记
研究了一段时间的CC，发现只看懂了些皮毛，固有的问题还是解决不了，不由感到非常的挫败。总的来说，CC部分复杂度较大，某些地方专业性强，chromium对其也一直在调整，是一块比较难啃的骨头。
另外想要详细了解chromium26CC有什么改进的，可以参考文档：http://dev.chromium.org/developers/design-documents/impl-side-painting
最近由于项目调整，对chromium24，26的CC探索告于段落了，日后可能会研究一下chromium31的CC，看看到时又有什么新变化，我们拭目以待。