来源参考：http://www.chromium.org/developers/design-documents/compositor-thread-architecture

Render线程的stalls：
  1，style recalc
  2，sync network request
  3，long painting times（复杂的页面内容？）
  4，GC

Compositor线程的引入：

0、对页面快照做滚动

1、2半，main/impl，2个layer树：LayerChromium和CCLayerImpl

2、‘可滚动’的layer

3、WebCompositorInputHandler：对可以fast-scroll的情况，直接route all input event到Compositor线程

4、每个Tab对应一对LayerTreeHost(Impl)，简称LTH(I)
  Impl线程可阻塞main线程（或说成main可发起对impl的阻塞调用），反之不行，不然会死锁

5、SetNeedsDisplayInRect：main运行layer delegate通知impl做paint

6、（delayed）SetNeedsCommit（如page内容改变） => Scheduler

7、commit flow：重点在CCThreadProxy类（同时为兼容单线程模式抽取的CCProxy接口）
  beginFrameAndCommit（bFAC）on main：
      （1）main端scroll（JS可以收到通知？）
      （2）回调JS requestAnimationFrame
      （3）执行任何pending layout
      （4）绘制layers（软件光栅化，或Ganesh GPU光栅化）

  beginCommit
    直到impl发回main ‘done’消息（2棵树完成同步，同步后就可以各干各的了？说起来Compositor线程主要就是为了提高滚动的性能，却搞了这么复杂的设计，想不通，其实只要在滚动时暂停JS、事件、IO、layout操作不就可以了嘛）

Chromium Compositor线程架构（笔记）