Title: [144206] trunk/Source/WebKit/chromium
- Revision
- 144206
- Author
- jam...@google.com
- Date
- 2013-02-27 09:53:04 -0800 (Wed, 27 Feb 2013)
Log Message
[chromium] Remove WebViewImpl::animate shimmy out through compositor
https://bugs.webkit.org/show_bug.cgi?id=110935
Reviewed by Adrienne Walker.
WebViewImpl::animate() and WebViewImpl::updateAnimations() are confusingly similar. ::animate() implements
the WebWidget API and is called by content::RenderWidget and WebViewHost. ::updateAnimations() implements
the WebLayerTreeViewClient API and is called by content::RenderWidgetCompositor and by ::animate(). The
important part of this indirection is that whenever the compositor is active, all animation calls must
route through cc::LayerTreeHost before entering into WebCore's animation code so that the compositor
can set the appropriate rate limiting state. Animations may originate from
content::RenderWidget::AnimateIfNeeded when in software and single threaded mode or from
cc::LayerTreeHost::updateAnimations in threaded compositing mode. In the long ago, content::RenderWidget had no
idea if compositing was active or not and always called WebWidget::animate(), so WebViewImpl::animate() had to
redirect to the compositor when appropriate.
Now (as of chromium r180947) RenderWidget calls WebWidget::animate only when in software mode and otherwise
calls directly into the compositor. Thus WebViewImpl::animate() no longer needs to do this check. In a
follow-up, WebViewImpl::updateAnimations will go away completely in favor of just calling WebWidget::animate in
all cases.
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::animate):
(WebKit::WebViewImpl::updateAnimations):
Modified Paths
Diff
Modified: trunk/Source/WebKit/chromium/ChangeLog (144205 => 144206)
--- trunk/Source/WebKit/chromium/ChangeLog 2013-02-27 17:48:07 UTC (rev 144205)
+++ trunk/Source/WebKit/chromium/ChangeLog 2013-02-27 17:53:04 UTC (rev 144206)
@@ -1,3 +1,30 @@
+2013-02-26 James Robinson <jam...@chromium.org>
+
+ [chromium] Remove WebViewImpl::animate shimmy out through compositor
+ https://bugs.webkit.org/show_bug.cgi?id=110935
+
+ Reviewed by Adrienne Walker.
+
+ WebViewImpl::animate() and WebViewImpl::updateAnimations() are confusingly similar. ::animate() implements
+ the WebWidget API and is called by content::RenderWidget and WebViewHost. ::updateAnimations() implements
+ the WebLayerTreeViewClient API and is called by content::RenderWidgetCompositor and by ::animate(). The
+ important part of this indirection is that whenever the compositor is active, all animation calls must
+ route through cc::LayerTreeHost before entering into WebCore's animation code so that the compositor
+ can set the appropriate rate limiting state. Animations may originate from
+ content::RenderWidget::AnimateIfNeeded when in software and single threaded mode or from
+ cc::LayerTreeHost::updateAnimations in threaded compositing mode. In the long ago, content::RenderWidget had no
+ idea if compositing was active or not and always called WebWidget::animate(), so WebViewImpl::animate() had to
+ redirect to the compositor when appropriate.
+
+ Now (as of chromium r180947) RenderWidget calls WebWidget::animate only when in software mode and otherwise
+ calls directly into the compositor. Thus WebViewImpl::animate() no longer needs to do this check. In a
+ follow-up, WebViewImpl::updateAnimations will go away completely in favor of just calling WebWidget::animate in
+ all cases.
+
+ * src/WebViewImpl.cpp:
+ (WebKit::WebViewImpl::animate):
+ (WebKit::WebViewImpl::updateAnimations):
+
2013-02-27 Sheriff Bot <webkit.review....@gmail.com>
Unreviewed, rolling out r144179.
Modified: trunk/Source/WebKit/chromium/src/WebViewImpl.cpp (144205 => 144206)
--- trunk/Source/WebKit/chromium/src/WebViewImpl.cpp 2013-02-27 17:48:07 UTC (rev 144205)
+++ trunk/Source/WebKit/chromium/src/WebViewImpl.cpp 2013-02-27 17:53:04 UTC (rev 144206)
@@ -1815,20 +1815,9 @@
}
#endif
-void WebViewImpl::animate(double)
+void WebViewImpl::animate(double monotonicFrameBeginTime)
{
-#if ENABLE(REQUEST_ANIMATION_FRAME)
- double monotonicFrameBeginTime = monotonicallyIncreasingTime();
-
-#if USE(ACCELERATED_COMPOSITING)
- // In composited mode, we always go through the compositor so it can apply
- // appropriate flow-control mechanisms.
- if (isAcceleratedCompositingActive())
- m_layerTreeView->updateAnimations(monotonicFrameBeginTime);
- else
-#endif
- updateAnimations(monotonicFrameBeginTime);
-#endif
+ updateAnimations(monotonicFrameBeginTime);
}
void WebViewImpl::willBeginFrame()
@@ -1844,6 +1833,9 @@
void WebViewImpl::updateAnimations(double monotonicFrameBeginTime)
{
+ if (!monotonicFrameBeginTime)
+ monotonicFrameBeginTime = monotonicallyIncreasingTime();
+
#if ENABLE(REQUEST_ANIMATION_FRAME)
TRACE_EVENT0("webkit", "WebViewImpl::updateAnimations");
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
