sync compositor: Queue up pending frame futures

sync compositor: Queue up pending frame futures

Allow pending frame future to be queued up.

Alternatives considered:
* Block on previous frame future before setting new one. Android already
  does this for us, so this would only decrease parallelism without
  reducing latency.
* Signal previous frame with empty frame. This is incorrect, as the
  display compositor will then draw the previous frame, which is wrong.

BUG=636164
Committed: https://crrev.com/1dd070326ef41fe0f2e7e68e0036687a90ba7f3a
Cr-Commit-Position: refs/heads/master@{#427477}

[boliu, 2016-10-25 15:59:37]

boliu@chromium.org changed reviewers:
+ dcheng@chromium.org

[boliu, 2016-10-25 15:59:37]

PTAL. two aspects..

I didn't use a UnguessableToken. Renderer side is already well ordered, so just
ended up using a queue. But I don't know the security implications.

And used emplace for my first time. Not sure if I did that and all the other stl
magic correctly :p

[boliu, 2016-10-25 17:30:37]

cc tobiasjs

[dcheng, 2016-10-25 18:38:17]

This CL LGTM, but a question for something I missed previously.

https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
File content/browser/android/synchronous_compositor_browser_filter.h (right):

https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
content/browser/android/synchronous_compositor_browser_filter.h:66: using
FrameFutureMap = std::map<int, FrameFutureQueue>;
Btw, is routing_id for a SynchronousCompositor guaranteed to be unique? I know
that in other parts of the system we need a process ID + routing ID for
uniqueness.

[boliu, 2016-10-25 20:02:32]

https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
File content/browser/android/synchronous_compositor_browser_filter.h (right):

https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
content/browser/android/synchronous_compositor_browser_filter.h:66: using
FrameFutureMap = std::map<int, FrameFutureQueue>;
On 2016/10/25 18:38:17, dcheng wrote:
> Btw, is routing_id for a SynchronousCompositor guaranteed to be unique? I know
> that in other parts of the system we need a process ID + routing ID for
> uniqueness.

Yeah, this object is owned by RenderProcessHostImpl. So one Filter per renderer
process, and the routing id is unique for a particular renderer process.

I think places that need both process and routing id are objects that is
actually global, or at least spans multiple renderer processes

[dcheng, 2016-10-25 20:05:40]

On 2016/10/25 20:02:32, boliu wrote:
>
https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
> File content/browser/android/synchronous_compositor_browser_filter.h (right):
> 
>
https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
> content/browser/android/synchronous_compositor_browser_filter.h:66: using
> FrameFutureMap = std::map<int, FrameFutureQueue>;
> On 2016/10/25 18:38:17, dcheng wrote:
> > Btw, is routing_id for a SynchronousCompositor guaranteed to be unique? I
know
> > that in other parts of the system we need a process ID + routing ID for
> > uniqueness.
> 
> Yeah, this object is owned by RenderProcessHostImpl. So one Filter per
renderer
> process, and the routing id is unique for a particular renderer process.
> 
> I think places that need both process and routing id are objects that is
> actually global, or at least spans multiple renderer processes

OK, thanks for the clarification. Maybe a comment on the map wouldn't hurt =)

[boliu, 2016-10-25 20:42:27]

On 2016/10/25 20:05:40, dcheng wrote:
> On 2016/10/25 20:02:32, boliu wrote:
> >
>
https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
> > File content/browser/android/synchronous_compositor_browser_filter.h
(right):
> > 
> >
>
https://codereview.chromium.org/2449973002/diff/1/content/browser/android/syn...
> > content/browser/android/synchronous_compositor_browser_filter.h:66: using
> > FrameFutureMap = std::map<int, FrameFutureQueue>;
> > On 2016/10/25 18:38:17, dcheng wrote:
> > > Btw, is routing_id for a SynchronousCompositor guaranteed to be unique? I
> know
> > > that in other parts of the system we need a process ID + routing ID for
> > > uniqueness.
> > 
> > Yeah, this object is owned by RenderProcessHostImpl. So one Filter per
> renderer
> > process, and the routing id is unique for a particular renderer process.
> > 
> > I think places that need both process and routing id are objects that is
> > actually global, or at least spans multiple renderer processes
> 
> OK, thanks for the clarification. Maybe a comment on the map wouldn't hurt =)

Done

[boliu, 2016-10-25 20:42:33]

The CQ bit was checked by boliu@chromium.org

[boliu, 2016-10-25 20:42:35]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/2449973002/#ps20001
(title: "comment")

[commit-bot: I haz the power, 2016-10-25 20:43:15]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-25 21:23:23]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-10-25 21:27:48]

Description was changed from

==========
sync compositor: Queue up pending frame futures

Allow pending frame future to be queued up.

Alternatives considered:
* Block on previous frame future before setting new one. Android already
  does this for us, so this would only decrease parallelism without
  reducing latency.
* Signal previous frame with empty frame. This is incorrect, as the
  display compositor will then draw the previous frame, which is wrong.

BUG=636164
==========

to

==========
sync compositor: Queue up pending frame futures

Allow pending frame future to be queued up.

Alternatives considered:
* Block on previous frame future before setting new one. Android already
  does this for us, so this would only decrease parallelism without
  reducing latency.
* Signal previous frame with empty frame. This is incorrect, as the
  display compositor will then draw the previous frame, which is wrong.

BUG=636164

Committed: https://crrev.com/1dd070326ef41fe0f2e7e68e0036687a90ba7f3a
Cr-Commit-Position: refs/heads/master@{#427477}
==========

[commit-bot: I haz the power, 2016-10-25 21:27:49]

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