WebView should paint directly into a GraphicsLayer when in accelerated compositing mode
Created attachment 79179 [details] Paint directly into a GraphicsLayer when using accelerated compositing
Comment on attachment 79179 [details] Paint directly into a GraphicsLayer when using accelerated compositing View in context: https://bugs.webkit.org/attachment.cgi?id=79179&action=review > Source/WebCore/ChangeLog:11 > + Remove special-cased support for providing content for the root layer > + > + Clients will just have to provide content through the normal > + GraphicsLayer channels now! > + > + Support for <http://webkit.org/b/52582> WebView should paint directly > + into a GraphicsLayer when in accelerated compositing mode > + > + Reviewed by NOBODY (OOPS!). The order of these paragraphs is backwards. > WebKit/win/ChangeLog:23 > + Paint directly into a GraphicsLayer when using accelerated compositing > + > + Before this patch, we were painting into our normal backing store > + HBITMAP, wrapping it in a CGImage, and handing it off to Core > + Animation. This had at least two disadvantages: > + 1) The bitmap could be modified while Core Animation was using it. > + 2) It introduced extra complexity. > + > + When entering accelerated compositing mode, WebView now creates a > + GraphicsLayer to draw into. This GraphicsLayer sits between the root > + layer (owned by WKCACFLayerRenderer) and the RenderView's layer. When > + WebView invalidates, it just calls setNeedsDisplayInRect on its > + GraphicsLayer. When WebView paints, it just tells its > + WKCACFLayerRenderer to paint, which will call back to WebView to draw > + into the GraphicsLayer if it has a dirty region. This is very similar > + to the current implementation of LayerBackedDrawingArea in WebKit2. > + > + Fixes <http://webkit.org/b/52582> WebView should paint directly into a > + GraphicsLayer when in accelerated compositing mode > + > + Reviewed by NOBODY (OOPS!). Backwards paragraphs.
Committed r75987: <http://trac.webkit.org/changeset/75987>