Mac: Clean up ui::Compositor recycling

Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
Committed: https://crrev.com/1f260a62accfc82c4bc7d7578bb3edb9116a1056
Cr-Commit-Position: refs/heads/master@{#406787}

[ccameron, 2016-07-20 23:43:58]

Description was changed from

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a frame to come in (reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
==========

to

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
==========

[ccameron, 2016-07-20 23:43:59]

ccameron@chromium.org changed reviewers:
+ enne@chromium.org

[ccameron, 2016-07-20 23:44:15]

Cleanup from fallout from cleanup.

[enne (OOO), 2016-07-20 23:53:48]

https://codereview.chromium.org/2167003002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/browser_compositor_view_mac.mm (right):

https://codereview.chromium.org/2167003002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/browser_compositor_view_mac.mm:136:
g_spare_recyclable_compositors.Get().pop_front();
Did you want to delete the remaining spare compositors here, if they exist? Or
the case where there is more than one is only when there is an outstanding
cleanup task?

[ccameron, 2016-07-20 23:59:34]

https://codereview.chromium.org/2167003002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/browser_compositor_view_mac.mm (right):

https://codereview.chromium.org/2167003002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/browser_compositor_view_mac.mm:136:
g_spare_recyclable_compositors.Get().pop_front();
On 2016/07/20 23:53:48, enne wrote:
> Did you want to delete the remaining spare compositors here, if they exist? Or
> the case where there is more than one is only when there is an outstanding
> cleanup task?

There will only be >0 when there is an outstanding cleanup task -- we want to
avoid doing the cleanup here, cause if we're here, we probably just created a
window/tab that is going to want to paint (and is going to be doing that in a
nested loop -- we'd rather not hit the dtor inside that nested loop).

[enne (OOO), 2016-07-21 00:04:50]

lgtm

[ccameron, 2016-07-21 05:49:04]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2016-07-21 05:49:19]

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-07-21 06:29:44]

Description was changed from

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
==========

to

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
==========

[commit-bot: I haz the power, 2016-07-21 06:29:45]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-21 06:32:02]

Description was changed from

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028
==========

to

==========
Mac: Clean up ui::Compositor recycling

Tab switch was often janky because we would end up creating and
destroying a ui::Compositor during tab-switch. Fix this by posting a
task to free the "spare" ui::Compositors. This fix has two effects.

First, this doesn't destroy the compositor while the browser compositor
is potentially waiting for a from the switched-to-tab to come in
(reducing contention).

Second, by posting a task to free up compositors, it allows us to be in
transient states where we have more than one "spare" ui::Compositor,
which indeed happens when opening a new tab.

BUG=630028

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

[commit-bot: I haz the power, 2016-07-21 06:32:03]

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