LTHI's bg animation timer should set the fake thread to impl.

LTHI's bg animation timer should set the fake thread to impl.

The single thread proxy expects this to be true.

BUG=165399
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=176061

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=176171

[enne (OOO), 2012-12-11 18:54:02]

This kind of defeats the purpose of the assert at all, since even if we're using
the threaded proxy, that code will always pretend to be on the impl thread.

Is there some better way to have this assert? Or, only set that scope if we're
using the single thread proxy? If none of those work, I think I'd prefer to just
remove the assert.

[Ian Vollick, 2012-12-11 19:05:44]

On 2012/12/11 18:54:02, enne wrote:
> This kind of defeats the purpose of the assert at all, since even if we're
using
> the threaded proxy, that code will always pretend to be on the impl thread.

I don't think that's true. There are two ways of getting into
LTHI::animateLayers.
  1. One way is via the proxy. This is how animations on active tabs are ticked.
In this case we definitely set the single thread proxy's fake current thread to
be 'impl'.
  2. The other way is when we're ticking animations on backgrounded tabs using a
timer. This timer, in the threaded case, really will be running on the impl
thread, so it's true that on every tick we should report that the fake current
thread is 'impl'. It's a bug that the timer reports 'main' as the current thread
when it ticks right now.

The assert will still be able to catch mistakes. For example, we may shuffle
things around in the single thread proxy, and we may call animateLayers at the
wrong time, and this assert will let us know.

> 
> Is there some better way to have this assert? Or, only set that scope if we're
> using the single thread proxy? If none of those work, I think I'd prefer to
just
> remove the assert.

[enne (OOO), 2012-12-11 19:26:22]

Oh! Thanks so much for all the explanation.  lgtm

[commit-bot: I haz the power, 2013-01-08 01:08:25]

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

[enne (OOO), 2013-01-10 03:59:07]

It looks like the commit queue choked.  /me gives it a kick.

[commit-bot: I haz the power, 2013-01-10 06:27:52]

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

[commit-bot: I haz the power, 2013-01-10 14:07:03]

Change committed as 176061

[enne (OOO), 2013-01-10 17:42:27]

lgtm, but

https://codereview.chromium.org/11532009/diff/22002/cc/layer_tree_host_impl.cc
File cc/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/11532009/diff/22002/cc/layer_tree_host_impl.c...
cc/layer_tree_host_impl.cc:74: scoped_ptr<DebugScopedSetImplThread>
setImplThread;
I think this is the only conditional DebugScopedSetImplThread, so it really
needs a comment as to why this is ok.

[commit-bot: I haz the power, 2013-01-10 19:06:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vollick@chromium.org/11532009/25001

[commit-bot: I haz the power, 2013-01-10 22:20:52]

Change committed as 176171