Title: [91621] trunk/Source/WebKit/chromium
- Revision
- 91621
- Author
- [email protected]
- Date
- 2011-07-22 16:37:51 -0700 (Fri, 22 Jul 2011)
Log Message
[chromium] Remove code that attempted to explicitly sync compositing state before compositing
https://bugs.webkit.org/show_bug.cgi?id=65055
Reviewed by Kenneth Russell.
There was some logic in WebViewImpl to try to synchronously calculate compositing requirements and sync
compositing state on all frames before painting in an attempt to flush out all pending updates before entering
the composite routines. The idea behind this code was that it would allow us to not worry about compositing
turning off in the middle of a composite operation due to things like RenderLayer overlap being lazily
calculated. In practice, we still need to be defensive to compositing requirements updating during the
composite anyway and this code is quite expensive on some pages (10ms+ on the HTML specification on my box).
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::layout):
* src/WebViewImpl.h:
Modified Paths
Diff
Modified: trunk/Source/WebKit/chromium/ChangeLog (91620 => 91621)
--- trunk/Source/WebKit/chromium/ChangeLog 2011-07-22 23:33:05 UTC (rev 91620)
+++ trunk/Source/WebKit/chromium/ChangeLog 2011-07-22 23:37:51 UTC (rev 91621)
@@ -1,3 +1,21 @@
+2011-07-22 James Robinson <[email protected]>
+
+ [chromium] Remove code that attempted to explicitly sync compositing state before compositing
+ https://bugs.webkit.org/show_bug.cgi?id=65055
+
+ Reviewed by Kenneth Russell.
+
+ There was some logic in WebViewImpl to try to synchronously calculate compositing requirements and sync
+ compositing state on all frames before painting in an attempt to flush out all pending updates before entering
+ the composite routines. The idea behind this code was that it would allow us to not worry about compositing
+ turning off in the middle of a composite operation due to things like RenderLayer overlap being lazily
+ calculated. In practice, we still need to be defensive to compositing requirements updating during the
+ composite anyway and this code is quite expensive on some pages (10ms+ on the HTML specification on my box).
+
+ * src/WebViewImpl.cpp:
+ (WebKit::WebViewImpl::layout):
+ * src/WebViewImpl.h:
+
2011-07-22 Cris Neckar <[email protected]>
Hook v8 up to cryptographicallyRandomValues as an entropy source.
Modified: trunk/Source/WebKit/chromium/src/WebViewImpl.cpp (91620 => 91621)
--- trunk/Source/WebKit/chromium/src/WebViewImpl.cpp 2011-07-22 23:33:05 UTC (rev 91620)
+++ trunk/Source/WebKit/chromium/src/WebViewImpl.cpp 2011-07-22 23:37:51 UTC (rev 91621)
@@ -1059,13 +1059,6 @@
// layout to be invalidated, so layout needs to be called last.
webframe->layout();
-
-#if USE(ACCELERATED_COMPOSITING)
- // Call updateLayers here instead of during doComposite so that we don't
- // trigger another redundant frame during doComposite.
- if (isAcceleratedCompositingActive())
- syncCompositingLayers();
-#endif
}
}
@@ -1150,16 +1143,6 @@
layout();
}
-void WebViewImpl::syncCompositingLayers()
-{
- TRACE_EVENT("WebViewImpl::syncCompositingLayers", this, 0);
- // Update the compositing requirements for all frame in the tree before doing any painting
- // as the compositing requirements for a RenderLayer within a subframe might change.
- for (Frame* frame = page()->mainFrame(); frame; frame = frame->tree()->traverseNext())
- frame->view()->updateCompositingLayers();
- page()->mainFrame()->view()->syncCompositingStateIncludingSubframes();
-}
-
void WebViewImpl::composite(bool finish)
{
#if USE(ACCELERATED_COMPOSITING)
Modified: trunk/Source/WebKit/chromium/src/WebViewImpl.h (91620 => 91621)
--- trunk/Source/WebKit/chromium/src/WebViewImpl.h 2011-07-22 23:33:05 UTC (rev 91620)
+++ trunk/Source/WebKit/chromium/src/WebViewImpl.h 2011-07-22 23:37:51 UTC (rev 91621)
@@ -431,7 +431,6 @@
void reallocateRenderer();
void updateLayerRendererSettings();
void updateLayerRendererViewport();
- void syncCompositingLayers();
#endif
WebViewClient* m_client;
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
