Limit outstanding surface draw swaps to max_frames_pending.

Limit outstanding surface draw swaps to max_frames_pending.

Avoid queueing up too many swaps on the GPU.

BUG=

Committed: https://crrev.com/032174589b8ff1a6ee7a0643b9490aa9c17b4703
Cr-Commit-Position: refs/heads/master@{#296111}

[jbauman, 2014-09-19 00:19:55]

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

[jamesr, 2014-09-22 22:03:35]

Hmm, how can this get ahead of the browser compositor scheduler?  Of course the
mojo embedding needs to be hooked up to a real scheduler at some point but I'm
surprised the content embedding doesn't just work since the display is slaved to
the existing browser compositor which should have a functional scheduler.

[jbauman, 2014-09-22 22:07:26]

On 2014/09/22 22:03:35, jamesr wrote:
> Hmm, how can this get ahead of the browser compositor scheduler?  Of course
the
> mojo embedding needs to be hooked up to a real scheduler at some point but I'm
> surprised the content embedding doesn't just work since the display is slaved
to
> the existing browser compositor which should have a functional scheduler.

Swaps from non-root surfaces don't go through the browser compositor, so they
trigger display draws directly. These draws can cause too many swaps to be
queued up.

[jamesr, 2014-09-22 22:41:26]

Ah, I see.  Can those be modeled as damage on the root surface for now so the
normal browser compositor scheduling works?  I don't like having dueling
schedulers in place, they get really hard to reason about, and fully integrating
a cc::Scheduler into surfaces is a fair chunk of work (I think, haven't actually
tried)

[jbauman, 2014-09-22 23:59:03]

On 2014/09/22 22:41:26, jamesr wrote:
> Ah, I see.  Can those be modeled as damage on the root surface for now so the
> normal browser compositor scheduling works?  I don't like having dueling
> schedulers in place, they get really hard to reason about, and fully
integrating
> a cc::Scheduler into surfaces is a fair chunk of work (I think, haven't
actually
> tried)

That would mess up the damage rects (particularly with multiply-nested surfaces,
but also in general), so I don't think that's a good way to move forward. Also
currently the only scheduler in single-threaded mode is a PostTask in
ui::Compositor, so I'm not too worried about the interactions there.

[jamesr, 2014-09-23 00:03:49]

Mm, true.

lgtm

[jbauman, 2014-09-23 00:19:02]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-09-23 00:19:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/578383004/1

[chromium-reviews, 2014-09-23 00:26:18]

On Mon, Sep 22, 2014 at 7:59 PM, <jbauman@chromium.org> wrote:

> On 2014/09/22 22:41:26, jamesr wrote:
>
>> Ah, I see.  Can those be modeled as damage on the root surface for now so
>> the
>> normal browser compositor scheduling works?  I don't like having dueling
>> schedulers in place, they get really hard to reason about, and fully
>>
> integrating
>
>> a cc::Scheduler into surfaces is a fair chunk of work (I think, haven't
>>
> actually
>
>> tried)
>>
>
> That would mess up the damage rects (particularly with multiply-nested
> surfaces,
> but also in general), so I don't think that's a good way to move forward.
> Also
> currently the only scheduler in single-threaded mode is a PostTask in
> ui::Compositor, so I'm not too worried about the interactions there.
>

The PostTask-mode will be going away soonish, to be replaced with a
scheduler in single-thread mode, in case that's of importance here. I'm not
sure if it is.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2014-09-23 00:48:06]

Committed patchset #1 (id:1) as 2f40aa4f459d432f9da9aba16b5710404a1af15d

[commit-bot: I haz the power, 2014-09-23 00:48:42]

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