WebLayerTreeView and WebWidget API cleanup

WebLayerTreeView and WebWidget API cleanup

This CL consists of 3 orthogonal changes. None of the changes affect code
behavior.

[3/3] Use WebLayerTreeView::setNeedsAnimate in place of WebWidgetClient::scheduleAnimation

In single thread mode WebWidgetClient::scheduleAnimation will be routed through
SingleThreadProxy::SetNeedsAnimate. Now WebLayerTreeView::setNeedsAnimate
should work in both modes.

[2/3] Remove WebLayerTreeView::setNeedsRedraw

The implementation is fully equivalent to setNeedsAnimate.

[1/3] Remove WebWidget/WebViewImpl::setNeedsRedraw

BUG=112837
R=jamesr
DEPENDS=https://codereview.chromium.org/80173002/

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162572

[jamesr, 2013-11-21 23:59:33]

https://codereview.chromium.org/80203002/diff/1/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/80203002/diff/1/Source/web/WebViewImpl.cpp#ne...
Source/web/WebViewImpl.cpp:3912: if (m_client)
since m_client here is the RenderWidget which knows about compositing, can we
get rid of this branch completely and have RenderWidget always make the right
call on the cc::LayerTreeHost?  These branches and divergent codepaths exist
from a time when the content::RenderWidget didn't know anything about the
cc::LayerTreeHost and only the WebViewImpl knew about both (via
WebLayerTreeView), but that's not the situation any more

[trchen, 2013-11-22 00:15:32]

https://codereview.chromium.org/80203002/diff/1/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/80203002/diff/1/Source/web/WebViewImpl.cpp#ne...
Source/web/WebViewImpl.cpp:3912: if (m_client)
For single thread mode that would be an infinite recursion:

WebViewImpl::scheduleAnimation --> RenderWidget::scheduleAnimation -->
RenderWidgetCompositor::setNeedsAnimate --> LayerTreeHost::SetNeedsAnimate -->
SingleThreadProxy::SetNeedsAnimate --> RenderWidgetCompositor::ScheduleAnimation
--> RenderWidget::scheduleAnimation

The problem is that the first RenderWidget::scheduleAnimation means "the blink
engine wants to tell you there is an ongoing animation", and the latter
RenderWidget::scheduleAnimation means "so let's post AnimationCallback on the
task queue".

The solution would be renaming the existing scheduleAnimation to
postAnimationTask or something.

[jamesr, 2013-11-23 00:08:19]

I see. lgtm

[commit-bot: I haz the power, 2013-11-23 00:18:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/trchen@chromium.org/80203002/1

[commit-bot: I haz the power, 2013-11-23 12:19:45]

Change committed as 162572