cc: Remove SetMemoryPolicy from OutputSurface and Display.

cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004, 606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/aa5c49175702f57438c939a7e4796ff19de4b681
Cr-Commit-Position: refs/heads/master@{#417778}

[danakj, 2016-09-08 03:32:27]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[danakj, 2016-09-08 03:32:32]

The CQ bit was checked by danakj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-08 03:32:51]

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

[danakj, 2016-09-08 03:33:04]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[danakj, 2016-09-08 03:33:32]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[danakj, 2016-09-08 03:34:20]

Actually bo, can you review the webview bits please (in webview/ and content/)?

[danakj, 2016-09-08 03:35:02]

danakj@chromium.org changed reviewers:
+ boliu@chromium.org, fsamuel@chromium.org

[danakj, 2016-09-08 03:35:03]

+fsamuel for mus parts

[commit-bot: I haz the power, 2016-09-08 03:43:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-08 03:43:58]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[boliu, 2016-09-08 03:47:43]

lgtm

although crbug.com/499004 isn't actually about removing SetMemoryPolicy from
LTHI, but rather remove the webview-specific logic to drop tiles when memory is
set to 0 (iirc)

[Fady Samuel, 2016-09-08 22:52:48]

lgtm

[danakj, 2016-09-08 23:17:20]

The CQ bit was checked by danakj@chromium.org to run a CQ dry run

[danakj, 2016-09-08 23:17:34]

Fixed the compile issue, ui/compositor needs to use the new setting name.

[commit-bot: I haz the power, 2016-09-08 23:17:51]

Dry run: 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-09-08 23:27:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-08 23:27:40]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[enne (OOO), 2016-09-09 22:46:17]

lgtm % nits

https://codereview.chromium.org/2321883002/diff/20001/cc/trees/layer_tree_set...
File cc/trees/layer_tree_settings.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/cc/trees/layer_tree_set...
cc/trees/layer_tree_settings.cc:19: // These limits inherited from
CompositorOutputSurface without
I don't know that this comment makes sense given that you've already moved it
from CompositorOutputSurface.  I get that you want to document that this is
arbitrary, but so is the gpu memory policy?

Maybe just remove this? Also, you use a different resource limit than there?

https://codereview.chromium.org/2321883002/diff/20001/content/renderer/gpu/re...
File content/renderer/gpu/render_widget_compositor.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/content/renderer/gpu/re...
content/renderer/gpu/render_widget_compositor.cc:504: // These limits inherited
from CompositorOutputSurface without
Similarly, I don't think this comment adds anything.  Why can't this just
inherit the default settings?

https://codereview.chromium.org/2321883002/diff/20001/ui/compositor/composito...
File ui/compositor/compositor.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/ui/compositor/composito...
ui/compositor/compositor.cc:187: // TODO(sohanjg): Revisit this memory usage in
tile manager.
I'm not sure this TODO is adding much.

[danakj, 2016-09-09 22:50:28]

blimp

[danakj, 2016-09-09 22:55:43]

https://codereview.chromium.org/2321883002/diff/20001/cc/trees/layer_tree_set...
File cc/trees/layer_tree_settings.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/cc/trees/layer_tree_set...
cc/trees/layer_tree_settings.cc:19: // These limits inherited from
CompositorOutputSurface without
On 2016/09/09 22:46:16, enne wrote:
> I don't know that this comment makes sense given that you've already moved it
> from CompositorOutputSurface.  I get that you want to document that this is
> arbitrary, but so is the gpu memory policy?
> 
> Maybe just remove this? Also, you use a different resource limit than there?

ok it was more for blame breadcrumbs but if u dont like it, it's gone.

https://codereview.chromium.org/2321883002/diff/20001/content/renderer/gpu/re...
File content/renderer/gpu/render_widget_compositor.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/content/renderer/gpu/re...
content/renderer/gpu/render_widget_compositor.cc:504: // These limits inherited
from CompositorOutputSurface without
On 2016/09/09 22:46:16, enne wrote:
> Similarly, I don't think this comment adds anything.  Why can't this just
> inherit the default settings?

Oh, ya I got halfway on that, it was my intent. Inheriting now.

https://codereview.chromium.org/2321883002/diff/20001/ui/compositor/composito...
File ui/compositor/compositor.cc (right):

https://codereview.chromium.org/2321883002/diff/20001/ui/compositor/composito...
ui/compositor/compositor.cc:187: // TODO(sohanjg): Revisit this memory usage in
tile manager.
On 2016/09/09 22:46:16, enne wrote:
> I'm not sure this TODO is adding much.

yaa.. also the #if cuz this class is not used on android..

[danakj, 2016-09-09 22:56:21]

nits

[Khushal, 2016-09-09 22:58:21]

On 2016/09/09 22:50:28, danakj wrote:
> blimp

lgtm thanks!

[danakj, 2016-09-09 22:58:39]

danakj@chromium.org changed reviewers:
+ wez@chromium.org

[danakj, 2016-09-09 22:58:40]

+wez for blimp/

[Khushal, 2016-09-09 22:58:41]

https://codereview.chromium.org/2321883002/diff/60001/blimp/client/support/co...
File blimp/client/support/compositor/blimp_layer_tree_settings.cc (right):

https://codereview.chromium.org/2321883002/diff/60001/blimp/client/support/co...
blimp/client/support/compositor/blimp_layer_tree_settings.cc:105:
cc::ManagedMemoryPolicy& memory_policy = settings->gpu_memory_policy;
o_o

[enne (OOO), 2016-09-09 22:59:01]

Re: breadcrumbs.  I think blame would show your patch and could show where it
came from.  Well, and now these comments also have enough breadcrumbs.  I think
in general I'm against historical breadcrumbs, as otherwise everything in cc
would be like "comes from
Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp".

[danakj, 2016-09-09 23:02:35]

On Fri, Sep 9, 2016 at 3:59 PM, enne@chromium.org via
codereview.chromium.org <reply@chromiumcodereview-hr.appspotmail.com> wrote:

> Re: breadcrumbs. I think blame would show your patch and could show where
> it
> came from. Well, and now these comments also have enough breadcrumbs. I
> think
> in general I'm against historical breadcrumbs, as otherwise everything in
> cc
> would be like "comes from
> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp".
>

lol too true.


>
> https://codereview.chromium.org/2321883002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2016-09-09 23:02:36]

The CQ bit was checked by danakj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 23:03:05]

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

[danakj, 2016-09-09 23:18:26]

danakj@chromium.org changed reviewers:
+ wez@chromium.org

[danakj, 2016-09-09 23:18:27]

danakj@chromium.org changed reviewers:
+ wez@chromium.org

[danakj, 2016-09-09 23:18:27]

Oops didn't actually add wez/ for blimp. But I'll TBR since Khushal reviewed it.

[danakj, 2016-09-09 23:18:28]

Oops didn't actually add wez/ for blimp. But I'll TBR since Khushal reviewed it.

[danakj, 2016-09-09 23:18:37]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[danakj, 2016-09-09 23:45:57]

The CQ bit was unchecked by danakj@chromium.org

[danakj, 2016-09-09 23:46:03]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-09-09 23:46:04]

The patchset sent to the CQ was uploaded after l-g-t-m from
fsamuel@chromium.org, boliu@chromium.org, enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2321883002/#ps80001
(title: "nits")

[commit-bot: I haz the power, 2016-09-09 23:46:31]

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-09-10 00:28:44]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[commit-bot: I haz the power, 2016-09-10 00:28:45]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-09-10 00:32:32]

Description was changed from

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Remove SetMemoryPolicy from OutputSurface and Display.

This method is plumbed through the Display but nothing ever actually
goes there. The only usage of this is:
1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
but it does so from SynchronousCompositorOutputSurface by calling the
OutputSurfaceClient (LayerTreeHostImpl) directly.
2) CompositorOutputSurface sets a limit when using software compositing.

Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
and have LayerTreeHostImpl use the software limits directly when given
a software output surface. And remove the plumbing through Display and
replace it with a NOTREACHED.

This means we don't have to support the method at all on the
"OutputSurfaceClient" that Display uses, only the one that
LayerTreeHostImpl uses.

Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
only used by WebView now. crbug.com/499004 suggests that the WebView
usage could also be replaced with something else. WebView seems to
only be changing the bytes part of the limit, so probably the method
only needs to take that, and I feel like the implementation in
LayerTreeHostImpl could probably be cleaned up some more yet also.

R=enne
TBR=wez
BUG=499004,606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/aa5c49175702f57438c939a7e4796ff19de4b681
Cr-Commit-Position: refs/heads/master@{#417778}
==========

[commit-bot: I haz the power, 2016-09-10 00:32:33]

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