Forward compositor tasks to the Blink scheduler

Forward compositor tasks to the Blink scheduler

Forward compositor tasks to the Blink scheduler so that they can be
prioritized over other work as necessary. We now route input and
compositor tasks through the same scheduler queue to preserve their
relative ordering.

BUG=391005
Committed: https://crrev.com/1c8d7094bc17cfc3ec05bc710ca6e76c463f519e
Cr-Commit-Position: refs/heads/master@{#294572}

[Sami, 2014-09-10 17:11:44]

skyostil@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2014-09-11 00:25:58]

You probably already know this, but tasks posted from the compositor thread to
the main thread have to preserve order with all input events in order to provide
correctness.  Are all input-related tasks routed to the scheduler currently so
it can preserve this FIFO?  Where is the tracking for this being performed?

[Sami, 2014-09-11 10:32:40]

On 2014/09/11 00:25:58, jamesr wrote:
> You probably already know this, but tasks posted from the compositor thread to
> the main thread have to preserve order with all input events in order to
provide
> correctness.  Are all input-related tasks routed to the scheduler currently so
> it can preserve this FIFO?  Where is the tracking for this being performed?

Let me see if I got that -- you mean these two task categories:

  1) the tasks posted from the input event filter on the compositor thread to
the main thread (in response to IPC)
  2) any tasks posted from the compositor thread to the main thread

I didn't realize there is a strict ordering requirement for these since they are
triggered by different things (input vs. cc/scheduler), but now that you mention
it I can imagine cases where the ordering matters (e.g., main thread should get
input before rAF).

Since all input events flow through (1), we can preserve the ordering with (2)
by posting them to the same scheduler queue. Is there another category of input
related tasks I'm missing?

[Sami, 2014-09-11 11:01:01]

I've changed the patch to route both types of tasks to the same queue.

[jamesr, 2014-09-11 19:51:20]

On 2014/09/11 10:32:40, Sami wrote:
> On 2014/09/11 00:25:58, jamesr wrote:
> > You probably already know this, but tasks posted from the compositor thread
to
> > the main thread have to preserve order with all input events in order to
> provide
> > correctness.  Are all input-related tasks routed to the scheduler currently
so
> > it can preserve this FIFO?  Where is the tracking for this being performed?
> 
> Let me see if I got that -- you mean these two task categories:
> 
>   1) the tasks posted from the input event filter on the compositor thread to
> the main thread (in response to IPC)
>   2) any tasks posted from the compositor thread to the main thread

Yes, exactly.  There are a couple scenarios but they all boil down to making
sure that the main thread sees input events and the side effects of input events
(like scrolling) in the same order that they originated in the browser.  If I
tap, scroll, tap, with the scroll handled on the compositor thread, the main
thread needs to see the scroll at the correct place relative to the two taps or
it'll hit test the wrong place.

> 
> I didn't realize there is a strict ordering requirement for these since they
are
> triggered by different things (input vs. cc/scheduler), but now that you
mention
> it I can imagine cases where the ordering matters (e.g., main thread should
get
> input before rAF).

That too.

> 
> Since all input events flow through (1), we can preserve the ordering with (2)
> by posting them to the same scheduler queue. Is there another category of
input
> related tasks I'm missing?

I think that'll do it. All input events (those with the InputMsg class, which
are the IPCs that we think need to be strictly FIFO although that is a bit of a
fuzzy science) should be in (1) and having them in the same queue should
preserve order.  If you wanted you could store them in separate queue data
structures *if* you kept around additional bookkeeping to make sure you service
them in the order posted, although I'm not sure what benefit that would provide.

[jamesr, 2014-09-11 19:51:27]

On 2014/09/11 11:01:01, Sami wrote:
> I've changed the patch to route both types of tasks to the same queue.

Thanks, lgtm.

[Sami, 2014-09-12 10:24:00]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-12 10:24:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/547693003/20001

[commit-bot: I haz the power, 2014-09-12 10:55:31]

Committed patchset #2 (id:20001) as 5b877f7246597faf8d2f2fe358a6488a6c6e1d9f

[commit-bot: I haz the power, 2014-09-12 10:57:36]

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