Don't schedule an animation during compositing dirty-bit setting unless needed.

Don't schedule an animation during compositing dirty-bit setting unless needed.

In particular, don't do it if the dirty bits are going to be cleaned up during synchronous
Blink execution anyway. To achieve this, this CL adds an m_updatingLayoutAndStyleForPainting state bit
in PageAnimator to indicate that code is in progress which is guaranteed to call
RenderLayerCompositor::updateCompositingLayers() at its end, and therefore any compositing dirty
bits set before that call do not require a call to scheduleAnimation().

Unfortunately, in a small number of cases RenderLayerCompositor::updateCompositingLayers will set
*new* dirty bits when updating direct compositing reasons. So put in code to check each
RenderLayerCompositor instance in the frame tree for dirty bits after
RenderLayerCompositor::updateCompositingLayers has run and call scheduleAnimation() if so. In the
future we can remove this once the compositing code is fixed to not leave around dirty bits.

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

[chrishtr, 2014-03-19 17:47:52]

The same as what we discussed, except for the sadness about
updateCompositingLayers sometimes adding on new dirty bits.

[abarth-chromium, 2014-03-19 17:50:33]

> will set *new* dirty bits when updating direct compositing reasons

Yes, that's craziness that we should weed out.

[abarth-chromium, 2014-03-19 18:04:57]

lgtm

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
File Source/core/rendering/compositing/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:416:
m_renderView.frameView()->scheduleAnimation();
Should we early return here?

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:423:
childCompositor->scheduleAnimationIfNeeded();
Rather than using recursion here, we can use frame->tree().traverseNext(...) to
make this walk into a simple loop.  Once we do that, we can early return once we
find some dirty bits.

[chrishtr, 2014-03-19 18:15:59]

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
File Source/core/rendering/compositing/RenderLayerCompositor.cpp (right):

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:416:
m_renderView.frameView()->scheduleAnimation();
On 2014/03/19 18:04:57, abarth wrote:
> Should we early return here?

Done. Confirmed with enne@ that this is ok.

https://codereview.chromium.org/202533003/diff/2/Source/core/rendering/compos...
Source/core/rendering/compositing/RenderLayerCompositor.cpp:423:
childCompositor->scheduleAnimationIfNeeded();
On 2014/03/19 18:04:57, abarth wrote:
> Rather than using recursion here, we can use frame->tree().traverseNext(...)
to
> make this walk into a simple loop.  Once we do that, we can early return once
we
> find some dirty bits.

Done.

[abarth-chromium, 2014-03-19 18:26:09]

https://codereview.chromium.org/202533003/diff/50001/Source/core/frame/FrameV...
File Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/202533003/diff/50001/Source/core/frame/FrameV...
Source/core/frame/FrameView.cpp:2797:
view->compositor()->scheduleAnimationIfNeeded();
Would you be willing to file a bug on this topic?  If there are unresolved dirty
bits, that means we'll put up a bad frame, right?

[chrishtr, 2014-03-19 18:31:13]

https://codereview.chromium.org/202533003/diff/50001/Source/core/frame/FrameV...
File Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/202533003/diff/50001/Source/core/frame/FrameV...
Source/core/frame/FrameView.cpp:2797:
view->compositor()->scheduleAnimationIfNeeded();
On 2014/03/19 18:26:11, abarth wrote:
> Would you be willing to file a bug on this topic?  If there are unresolved
dirty
> bits, that means we'll put up a bad frame, right?

Done.

[chrishtr, 2014-03-19 20:12:45]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2014-03-19 20:12:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/chrishtr@chromium.org/202533003/20002

[commit-bot: I haz the power, 2014-03-19 20:16:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 20:16:06]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[chrishtr, 2014-03-19 20:18:44]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2014-03-19 20:18:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/chrishtr@chromium.org/202533003/20002

[commit-bot: I haz the power, 2014-03-19 20:21:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 20:21:47]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[chrishtr, 2014-03-20 16:00:51]

The CQ bit was checked by chrishtr@chromium.org

[chrishtr, 2014-03-20 16:00:54]

The CQ bit was unchecked by chrishtr@chromium.org

[chrishtr, 2014-03-20 16:03:11]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2014-03-20 16:03:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/chrishtr@chromium.org/202533003/20002

[commit-bot: I haz the power, 2014-03-20 16:35:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-20 16:35:41]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_rel

[chrishtr, 2014-03-20 18:16:05]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2014-03-20 18:16:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/chrishtr@chromium.org/202533003/70001

[commit-bot: I haz the power, 2014-03-20 18:17:31]

Change committed as 169672