Hardware Accelerated Rendering/Compositor

At the onset of this project Chrome was using two compositors - the compositor used by WebKit to hardware accelerate CSS transitions, and a "Browser Compositor" run in the UI thread of the browser process, used to implement Views transformations like whole-screen rotations.

For a number of reasons, it is desirable to unify our compositing efforts here and provide a single compositor. The primary reason is achieving acceptable performance on target hardware. It is necessary to have a single compositor and draw-pass instead of two as we have now. We would also like to unify the layer trees too at some point, although this was deemed less critical.

The Browser Compositor is implemented as implementations of a ui::Compositor interface, such as a GL one and a D3D one. Antoine has been proceeding by writing a new implementation that uses the WebKit-CC compositor. This way the UI can continue to use the ui::Layer API as its render target. As mentioned, we may eventually consolidate the API between UI and WebKit.

The compositor is a distinct component in Chrome code, consuming only gfx types, WebKit (obviously) and other low level components. In the fullness of time the WebKit compositor will be extracted from WebKit further so that we do not need to drag all of WebKit into Aura and Views.