cc: Re-enable GPU rasterization after content veto.

cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel

Committed: https://crrev.com/91841308fd6b5c3a31e6515aec158996a2fdcb04
Cr-Commit-Position: refs/heads/master@{#405295}

[vmpstr, 2016-06-30 00:50:49]

Description was changed from

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
==========

to

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[vmpstr, 2016-06-30 00:51:48]

Please take a look.

[enne (OOO), 2016-06-30 01:02:24]

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:1058: if ((source_frame_number_ %
kFramePeriodToReeanbleGpuRasterization) == 0 &&
I think it might be safer to say "if the last N frames have been ok, then
reenable" vs just unflipping and peeking at the new value again every N frames.

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:495: enum { kMaxTimesToEnableGpuRasterization = 5 };
Why do you want to have a limit on how many times you reeanble? If you have some
long running page that changes state, I feel like we should change an indefinite
number of times?  If you're worried about changing too much, then change the
number of commits you need before swapping?

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:496: // The number of commits to waitch before
attempting to re-enable gpu
<_<

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:498: enum { kFramePeriodToReeanbleGpuRasterization =
10 };
Reeanble?

[ericrk, 2016-06-30 18:45:59]

ericrk@chromium.org changed reviewers:
+ ericrk@chromium.org

[ericrk, 2016-06-30 18:46:01]

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:1061: content_is_suitable_for_gpu_rasterization_ =
true;
Can we always set this to true? Or do we want to check if the content is
suitable at this point?

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:495: enum { kMaxTimesToEnableGpuRasterization = 5 };
On 2016/06/30 01:02:24, enne wrote:
> Why do you want to have a limit on how many times you reeanble? If you have
some
> long running page that changes state, I feel like we should change an
indefinite
> number of times?  If you're worried about changing too much, then change the
> number of commits you need before swapping?

+1

https://codereview.chromium.org/2108033004/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:498: enum { kFramePeriodToReeanbleGpuRasterization =
10 };
On 2016/06/30 01:02:24, enne wrote:
> Reeanble?

There's a significant cost to switching I'd imagine (re-decode all images,
etc...)... Is 10 frames too little? I'd be more tempted to do this on the order
of at most once a second?

[vmpstr, 2016-06-30 20:35:19]

Please take a look. I've addressed all comments, I think.

[ericrk, 2016-06-30 22:14:58]

lgtm

[vmpstr, 2016-07-13 20:22:24]

The CQ bit was checked by vmpstr@chromium.org

[commit-bot: I haz the power, 2016-07-13 20:24:06]

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-13 20:24:08]

Your CL relies on deprecated CQ feature(s):
 * Specifying master names without "master." prefix is deprecated:
tryserver.blink. For more details, see http://crbug.com/617627.

[vmpstr, 2016-07-13 20:26:03]

Description was changed from

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-07-13 21:35:51]

Description was changed from

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

to

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-07-13 21:35:52]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-07-13 21:36:29]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-13 21:39:11]

Description was changed from

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

to

==========
cc: Re-enable GPU rasterization after content veto.

This patch periodically re-enables GPU rasterization after it is
disabled due to a content veto.

R=enne
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel

Committed: https://crrev.com/91841308fd6b5c3a31e6515aec158996a2fdcb04
Cr-Commit-Position: refs/heads/master@{#405295}
==========

[commit-bot: I haz the power, 2016-07-13 21:39:12]

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