cc: Set tile manager memory policy in initializeRenderer.

cc: Set tile manager memory policy in initializeRenderer.

The combination of software compositing and impl-side painting is
currently broken because no one calls EnforceManagedMemoryPolicy after the
TileManager is created.  Add a call in initializeRenderer.

This also results in allocating impl-side-painting tiles in test code,
and this flushed out some bugs in TileManager destruction; I also fixed those.

BUG=236535, 230194
NOTRY=true

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

[aelias_OOO_until_Jul13, 2013-04-29 23:36:29]

PTAL.  This will need a real fix but this avoids the white tab condition in the
short term.

[ccameron, 2013-04-29 23:58:46]

Calling SetManagedMemoryPolicy shouldn't be necessary -- there should be a
default policy in place (see managed_memory_policy_ in the ctor of the LTHI).

There should be no necessary side-effects of the Set call. The GPU memory
manager sends the policy to each new tab with a delay (in theory as long as a
few frames) -- we need an initial policy regardless of SW v GPU.

https://codereview.chromium.org/14061028/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/14061028/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1403:
ManagedMemoryPolicy::CUTOFF_ALLOW_REQUIRED_ONLY));
I'd suggest 0 and NOTHING for non-visible tabs (cause otherwise you'll end up
with a lot of memory being use when there are lots of backgrounded tabs).

[slavi, 2013-04-30 00:30:54]

lgtm

[aelias_OOO_until_Jul13, 2013-04-30 00:31:29]

There is a side-effect, it calls EnforceManagedMemoryPolicy which affects the
newly created TileManager.  I just changed the patch to make that call instead,
thanks for the feedback.

[aelias_OOO_until_Jul13, 2013-04-30 04:26:20]

Some of the cc_unittests were depending on the accidental behavior of 0 memory
limit, so I made that explicit in the test code.

[ccameron, 2013-04-30 18:52:00]

This lgtm, except for the assert that was removed -- that shouldn't be the case
outside of unit tests (maybe the tests should be updated... if it's easy. If
not, then maybe just file a bug & reference in the comment).

https://codereview.chromium.org/14061028/diff/16001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (left):

https://codereview.chromium.org/14061028/diff/16001/cc/trees/thread_proxy.cc#...
cc/trees/thread_proxy.cc:611:
DCHECK_GT(layer_tree_host_impl_->memory_allocation_limit_bytes(), 0u);
This assert seems important to me. We shouldn't be trying to draw a frame with
no memory available (the GpuMemoryManager always gives out at least some memory)

[aelias_OOO_until_Jul13, 2013-04-30 19:42:10]

I spent another half hour trying to find a cleaner fix but didn't find anything
better so far, filed http://crbug.com/236916 and linked to it in the comment.

[ccameron, 2013-04-30 19:43:04]

On 2013/04/30 19:42:10, aelias wrote:
> I spent another half hour trying to find a cleaner fix but didn't find
anything
> better so far, filed http://crbug.com/236916 and linked to it in the comment.

Fair enough. Thanks for looking into it.

[aelias_OOO_until_Jul13, 2013-04-30 23:59:37]

Building on top of Dana's  https://codereview.chromium.org/14273026 I found a
clean fix after all.  Because the TileManager's destruction code is now properly
exercised, this turned out a bug in ~TileManager and another in
WorkerPool::Shutdown; I fixed these as part of the same patch [+reveman].

[reveman, 2013-05-01 01:39:32]

lgtm

[commit-bot: I haz the power, 2013-05-01 03:45:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aelias@chromium.org/14061028/31001

[commit-bot: I haz the power, 2013-05-01 03:45:20]

Change committed as 197565