cc: Use Scheduler::BeginFrame() in SingleThreadProxy

cc: Use Scheduler::BeginFrame() in SingleThreadProxy

Proxy should use BeginFrame() to request new BeginFrame instead of BeginImplFrame().
The scheduler turns BeginFrames into BeginImplFrames or BeginRetroFrames
as necessary to make sure we don't start a new BeginImplFrame
before the previous deadline.

Some of public methods that are only used by itself moved into the private.

[email protected]
BUG=NONE
TEST=cc_unittests

Committed: https://crrev.com/96b5967f6a201fdb0e7cb3782de01915362ecb8a
Cr-Commit-Position: refs/heads/master@{#293259}

[simonhong, 2014-09-03 21:07:20]

PTAL!

[danakj, 2014-09-03 21:16:01]

[email protected] changed reviewers:
+ [email protected]

[danakj, 2014-09-03 21:16:01]

> Proxy only can use BeginFrame() to request next BeginFrame instead of calling
BeginImplFrame().


Can you explain why? What does this fix?

[brianderson, 2014-09-03 21:21:13]

[email protected] changed reviewers:
+ [email protected]
- [email protected]

[brianderson, 2014-09-03 21:21:14]

Can you make BeginImplFrame a protected method in the Scheduler, so this doesn't
happen again? Several other methods should probably be protected as well...

+enne to double check this wont have unintended side-effects. The scheduler
turns BeginFrames into BeginImplFrames or BeginRetroFrames as necessary to make
sure we don't start a new BeginImplFrame before the previous deadline. I'm
surprised we haven't hit the first DCHECK in Scheduler::BeginImplFrame without
this patch.

[enne (OOO), 2014-09-03 21:27:51]

lgtm % brianderson

That sounds reasonable to me.  Calling BeginImplFrame wasn't an intentional
choice.  I think I meant BeginFrame and picked that because the name sounded
like the right thing (or it was in the past and then got renamed again?)

[simonhong, 2014-09-03 21:30:34]

On 2014/09/03 21:21:14, brianderson wrote:
> Can you make BeginImplFrame a protected method in the Scheduler, so this
doesn't
> happen again? Several other methods should probably be protected as well...
> 
> +enne to double check this wont have unintended side-effects. The scheduler
> turns BeginFrames into BeginImplFrames or BeginRetroFrames as necessary to
make
> sure we don't start a new BeginImplFrame before the previous deadline. I'm
> surprised we haven't hit the first DCHECK in Scheduler::BeginImplFrame without
> this patch.

danakj@, brian explained already.
Yes, I was surprised, too.
I'll find more methods which should be in protected.
(I'm on the way to go my office)

[danakj, 2014-09-03 21:31:15]

On 2014/09/03 21:30:34, simonhong wrote:
> On 2014/09/03 21:21:14, brianderson wrote:
> > Can you make BeginImplFrame a protected method in the Scheduler, so this
> doesn't
> > happen again? Several other methods should probably be protected as well...
> > 
> > +enne to double check this wont have unintended side-effects. The scheduler
> > turns BeginFrames into BeginImplFrames or BeginRetroFrames as necessary to
> make
> > sure we don't start a new BeginImplFrame before the previous deadline. I'm
> > surprised we haven't hit the first DCHECK in Scheduler::BeginImplFrame
without
> > this patch.
> 
> danakj@, brian explained already.
> Yes, I was surprised, too.
> I'll find more methods which should be in protected.
> (I'm on the way to go my office)

Yep thanks for the explanation brian. Simon can you throw something about that
in your patch description?

[brianderson, 2014-09-03 23:14:31]

On 2014/09/03 21:27:51, enne wrote:
> lgtm % brianderson
> 
> That sounds reasonable to me.  Calling BeginImplFrame wasn't an intentional
> choice.  I think I meant BeginFrame and picked that because the name sounded
> like the right thing (or it was in the past and then got renamed again?)

It was the right choice in the past and yes, the part of the path from the
OutputSurface to the Scheduler got renamed to just BeginFrame since it wouldn't
necessarily trigger a BeginImplFrame after one of the OutputSurface refactors.

[simonhong, 2014-09-04 00:39:09]

brian, please check again.
Thanks!

[brianderson, 2014-09-04 00:46:41]

lgtm, as long as tests don't need access to these methods.

[simonhong, 2014-09-04 00:53:29]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-09-04 00:56:18]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/[email protected]/536123002/20001

[commit-bot: I haz the power, 2014-09-04 03:01:28]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-09-04 03:01:28]

Try jobs failed on following builders:
  android_clang_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)

[simonhong, 2014-09-04 04:09:38]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-09-04 04:11:01]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/[email protected]/536123002/20001

[commit-bot: I haz the power, 2014-09-04 04:57:58]

Committed patchset #2 (id:20001) as cb57cd9b5e72b321973d5ed01e1e7c3eaab6a002

[commit-bot: I haz the power, 2014-09-10 03:29:48]

Patchset 2 (id:??) landed as
https://crrev.com/96b5967f6a201fdb0e7cb3782de01915362ecb8a
Cr-Commit-Position: refs/heads/master@{#293259}