Make LayerTreeHost::animateLayers take a wall clock time in addition to a monotonic time

Make LayerTreeHost::animateLayers take a wall clock time in addition to a monotonic time

This is in preparation for enabling accelerated animations for orphaned layers. When this happens, LayerTreeHost::animateLayers will need the wall clock time when generating animation events for layer animation controllers belonging to orphaned layers (just like LayerTreeHostImpl::animateLayers already needs a wall clock time when generating animation events). 

BUG=129683

[ajuma, 2013-01-10 19:23:45]

This is step 1 in the 3-step plan from
https://chromiumcodereview.appspot.com/11783037/ for enabling accelerated
animations for orphaned layers.

[jamesr, 2013-01-14 21:54:16]

Ian, this one's yours

[Ian Vollick, 2013-01-15 03:27:37]

lgtm with nits.

https://codereview.chromium.org/11783101/diff/1/webkit/compositor_bindings/we...
File webkit/compositor_bindings/web_layer_tree_view_impl.cc (right):

https://codereview.chromium.org/11783101/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_layer_tree_view_impl.cc:163: base::Time
wallClockFrameBeginTime =
base::Time::FromInternalValue(wallClockFrameBeginTimeSeconds*
base::Time::kMicrosecondsPerSecond);
It looks like Time has a ::FromDoubleT method that could be useful here.

https://codereview.chromium.org/11783101/diff/1/webkit/compositor_bindings/we...
File webkit/compositor_bindings/web_layer_tree_view_impl.h (right):

https://codereview.chromium.org/11783101/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_layer_tree_view_impl.h:52: // TODO(ajuma): Remove
this after the WebKit patch to use the 2-argument version lands.
Is there a bug for this work that could be cited here?

[ajuma, 2013-01-15 16:24:08]

Fixed nits.

https://chromiumcodereview.appspot.com/11783101/diff/1/webkit/compositor_bind...
File webkit/compositor_bindings/web_layer_tree_view_impl.cc (right):

https://chromiumcodereview.appspot.com/11783101/diff/1/webkit/compositor_bind...
webkit/compositor_bindings/web_layer_tree_view_impl.cc:163: base::Time
wallClockFrameBeginTime =
base::Time::FromInternalValue(wallClockFrameBeginTimeSeconds*
base::Time::kMicrosecondsPerSecond);
On 2013/01/15 03:27:37, vollick wrote:
> It looks like Time has a ::FromDoubleT method that could be useful here.

Done.

https://chromiumcodereview.appspot.com/11783101/diff/1/webkit/compositor_bind...
File webkit/compositor_bindings/web_layer_tree_view_impl.h (right):

https://chromiumcodereview.appspot.com/11783101/diff/1/webkit/compositor_bind...
webkit/compositor_bindings/web_layer_tree_view_impl.h:52: // TODO(ajuma): Remove
this after the WebKit patch to use the 2-argument version lands.
On 2013/01/15 03:27:37, vollick wrote:
> Is there a bug for this work that could be cited here?

Done.

[commit-bot: I haz the power, 2013-01-15 16:31:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ajuma@chromium.org/11783101/9001

[commit-bot: I haz the power, 2013-01-15 16:31:25]

Presubmit check for 11783101-9001 failed and returned exit status 1.


Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    webkit/compositor_bindings

Presubmit checks took 2.1s to calculate.

[ajuma, 2013-01-15 16:36:00]

On 2013/01/15 16:31:25, I haz the power (commit-bot) wrote:
> Missing LGTM from an OWNER for files in these directories:
>     webkit/compositor_bindings

jamesr, PTAL.

[jamesr, 2013-01-16 04:15:04]

Color me confused.  What's the relationship between orphan layers and needing
wall clock time in more places?

[Ian Vollick, 2013-01-16 04:56:04]

On 2013/01/16 04:15:04, jamesr wrote:
> Color me confused.  What's the relationship between orphan layers and needing
> wall clock time in more places?

Good question. We used to only issue animation events from the impl thread.
Rather than syncing these orphan layers just for this purpose, the main thread
will (in a later patch) have the ability issue animation events for these
layers. These events need the wall clock time.

[jamesr, 2013-01-16 04:57:32]

On 2013/01/16 04:56:04, vollick wrote:
> On 2013/01/16 04:15:04, jamesr wrote:
> > Color me confused.  What's the relationship between orphan layers and
needing
> > wall clock time in more places?
> 
> Good question. We used to only issue animation events from the impl thread.
> Rather than syncing these orphan layers just for this purpose, the main thread
> will (in a later patch) have the ability issue animation events for these
> layers. These events need the wall clock time.

Issue it to what? The only reason we deal with wall clock times at all is to
generate events for DOM elements that may register for animation events, but
when would we want to generate events for a layer that's not in the tree?

[Ian Vollick, 2013-01-16 05:24:40]

On 2013/01/16 04:57:32, jamesr wrote:
> On 2013/01/16 04:56:04, vollick wrote:
> > On 2013/01/16 04:15:04, jamesr wrote:
> > > Color me confused.  What's the relationship between orphan layers and
> needing
> > > wall clock time in more places?
> > 
> > Good question. We used to only issue animation events from the impl thread.
> > Rather than syncing these orphan layers just for this purpose, the main
thread
> > will (in a later patch) have the ability issue animation events for these
> > layers. These events need the wall clock time.
> 
> Issue it to what? The only reason we deal with wall clock times at all is to
> generate events for DOM elements that may register for animation events, but
> when would we want to generate events for a layer that's not in the tree?

Issue it to the WebCore animation system. It can sometimes happen that main
thread animations block waiting for the accelerated animation. It caused this
bug: https://bugs.webkit.org/show_bug.cgi?id=95950. To get around this problem,
we had to say that if the layer wasn't in the tree, we couldn't accelerate its
animations. This means that many animations (most transitions on android IIRC --
epenner, please correct me if that's wrong) are not accelerated. The point of
the orphan layer and graphics layer factory stuff is to allow us to accelerate
animations for layers that are not yet in the tree.

[Ian Vollick, 2013-01-16 05:51:35]

On 2013/01/16 05:24:40, vollick wrote:
> On 2013/01/16 04:57:32, jamesr wrote:
> > On 2013/01/16 04:56:04, vollick wrote:
> > > On 2013/01/16 04:15:04, jamesr wrote:
> > > > Color me confused.  What's the relationship between orphan layers and
> > needing
> > > > wall clock time in more places?
> > > 
> > > Good question. We used to only issue animation events from the impl
thread.
> > > Rather than syncing these orphan layers just for this purpose, the main
> thread
> > > will (in a later patch) have the ability issue animation events for these
> > > layers. These events need the wall clock time.
> > 
> > Issue it to what? The only reason we deal with wall clock times at all is to
> > generate events for DOM elements that may register for animation events, but
> > when would we want to generate events for a layer that's not in the tree?
> 
> Issue it to the WebCore animation system. It can sometimes happen that main
> thread animations block waiting for the accelerated animation. It caused this
> bug: https://bugs.webkit.org/show_bug.cgi?id=95950. To get around this
problem,
> we had to say that if the layer wasn't in the tree, we couldn't accelerate its
> animations. This means that many animations (most transitions on android IIRC
--
> epenner, please correct me if that's wrong) are not accelerated. The point of
> the orphan layer and graphics layer factory stuff is to allow us to accelerate
> animations for layers that are not yet in the tree.

Sorry for the spam. I also wanted to mention that this was intended as a
workaround until the deeper issue in WebCore is fixed (transitions blocking
waiting for animations on layers not yet in the tree).  The issue seems to have
been around for a long time (https://bugs.webkit.org/show_bug.cgi?id=26770) and
my hope was that this could get us accelerating transitions in the short term.