Chromium CC部分浅析(一)

1. CC简介

   CC即是chromiumcompositing的简写，意思是chromium的合成器，是为webkit的硬件加速渲染提供合成和渲染逻辑的关键代码。关于硬件加速的基本知识可以参见chromium的官方文档http://dev.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome。

   最简单的理解就是，硬件加速模式下，一张网页被分成许多不同的层分别渲染，最后再合成起来。为的就是一个层的改变不影响其他层，这样可以减少渲染的工作量。相信接触过画图软件的人对于层和合成是有比较直观的感受的。

             至于分层的规则是什么，上述文档有全面的描述，我在下面的内容中也会提到。

             chromium CC当然没有说的这么简单。它为了进一步提升性能又使用了很多花招，下面的内容会有涉猎。

2. CC存在的问题

   在移植的过程中发现CC模块有两大问题，导致其代码较难阅读理解：复杂性和变化性。

1. 复杂性

            上面说了，CC为了提升性能或者提升通用性使用了很多花招，略举几例：

            a.将每一个层分割成很多tile，仅仅渲染当前viewport所涉及到的那些tile（实际上会略多一些）。这样进一步减少了渲染的工作量，但多出了很多代码来管理tile，包括分        配，渲染，回收等。

            b.将实际渲染操作独立成impl线程，与webkit所运行的main线程分离开来，这样可以减少渲染操作对webkit的影响。但在两个线程建立了类似的数据结构，双方通过代理沟通（thread_proxy），但数据结构之前的同步过程增大了开销。

            c.调用GPU进程绘制GL纹理，IPC方式使用共享内存和命名管道。

等等。可见，这些特性的引入也大大增加了CC模块的复杂性。比较一下androidbrowser的硬件加速代码，CC模块也算是庞然大物了。这又是线程同步又是进程通信的，某些性能不如androidbrowser也就不足为奇了。

说到这里不得不再罗嗦几句，不仅CC模块，复杂性存在于整个chromium。在移动平台来说，chromium真是一个比较吃硬件性能的浏览器，不管从内存耗用还算CPU耗用都是不吃素的。任你再怎么优化，也别跟androidbrowser这种轻量级浏览器比灵活性。

                      2. 变化性

CC部分代码一直在改进之中，每次更新都能看到CC部分有大量调整。在移植chromium24代码的过程中，发现滚动不流程，字体不清晰等问题都是由于CC模块的bug引起的。google显然早已发现了这些问题，并在chromium26中做出了修改。

为什么24的bug到26才改好？因为这个修改实在庞大，在保持CC主框架的前提下将很多实现、流程都进行了修改、增删。而与CC联系密切的content、webkit等模块也少不了相应的修改。

CC模块如此繁杂并且经常有剧烈变化，导致想要单独升级CC模块变成不可能的事情，实在是对我等抱大腿的人非常的不友好。