cc: Don't double-tick unthrottled FrameRateController

cc: Don't double-tick unthrottled FrameRateController

When the FrameRateController is configured with a non-throttling time
source (i.e., vsync is off), it posts the next tick task manually
whenever it is active at the end of a previous tick. However, it also
posts a manual tick task when a swap buffers call completes to make sure
rendering doesn't stall.

These two tick task sources combined can lead to an expential growth of
tick tasks. Consider the following call tree where each edge is an
asynchronous task:

    OnTimerTick
        |  |
        |   `--------------------.
        |                        |
    BeginImplFrame               |
    Deadline                     |
        |                        |
    OnSwapBuffers                |
    Complete                     |
        |                        |
    OnTimerTick              OnTimerTick
        |  |                     |  |
        |   `--------.           |   `----------.
        |            |           |              |
    BeginImplFrame   |       BeginImplFrame     |
    Deadline         |       Deadline           |
        |            |           |              |
    OnSwapBuffers    |       OnSwapBuffers      |
    Complete         |       Complete           |
        |            |           |              |
    OnTimerTick  OnTimerTick OnTimerTick    OnTimerTick
        |  |         |  |        |  |           |  |
        :  :         :  :        :  :           :  :

    (etc.)

In practice this situation happens if both the impl and main threads request a
BeginFrame and when the tick task runs, the scheduler isn't ready to draw
because the previous BeginFrame deadline hasn't triggered yet. This means the
the pending swap count never increases to the throttling limit and each timer
tick causes another one to get queued. Once the deadline triggers and we do
swap, the swap completion spawns a parallel line of tick tasks.

This patch fixes the problem by only queueing a new tick task if we haven't
queued one already.

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

[Sami, 2013-11-08 17:05:47]

Enne, maybe you could have a look at this while Brian's out? Sorry for the
messed up ascii art; it looks fine if you click on "Edit Issue".

[Sami, 2013-11-13 11:07:58]

Friendly ping?

[enne (OOO), 2013-11-13 20:42:16]

lgtm, but

https://codereview.chromium.org/67023003/diff/1/cc/trees/layer_tree_host_perf...
File cc/trees/layer_tree_host_perftest.cc (right):

https://codereview.chromium.org/67023003/diff/1/cc/trees/layer_tree_host_perf...
cc/trees/layer_tree_host_perftest.cc:49: settings->deadline_scheduling_enabled =
false;
Can you put this in a different patch?

[Sami, 2013-11-14 11:15:22]

Thanks!

On 2013/11/13 20:42:16, enne wrote:
> lgtm, but
> 
>
https://codereview.chromium.org/67023003/diff/1/cc/trees/layer_tree_host_perf...
> File cc/trees/layer_tree_host_perftest.cc (right):
> 
>
https://codereview.chromium.org/67023003/diff/1/cc/trees/layer_tree_host_perf...
> cc/trees/layer_tree_host_perftest.cc:49: settings->deadline_scheduling_enabled
=
> false;
> Can you put this in a different patch?

Good idea, done.

[commit-bot: I haz the power, 2013-11-14 11:15:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skyostil@chromium.org/67023003/100001

[commit-bot: I haz the power, 2013-11-14 17:10:40]

Commit queue rejected this change because the description was changed
between the time the change entered the commit queue and the time it
was ready to commit. You can safely check the commit box again.

[commit-bot: I haz the power, 2013-11-14 17:47:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skyostil@chromium.org/67023003/100001

[commit-bot: I haz the power, 2013-11-14 17:50:21]

Change committed as 235178