cc: Remove fixed raster scale, stop rasterizing with will-change.

cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=600867
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[vmpstr, 2016-06-15 22:49:33]

Description was changed from

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=
==========

to

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[vmpstr, 2016-06-15 22:54:05]

Please take a look. This patch also removes the use counter stuff. I couldn't
just revert the patch that added use counters, because it was also the patch
that plumbed the will-change property to cc.

[chrishtr, 2016-06-16 04:43:27]

Description was changed from

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=600867
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[chrishtr, 2016-06-16 04:47:32]

Looks great to me. I think we should go ahead and commit this now. We can revert
it if the intent-to-ship fails for some reason.

[danakj, 2016-06-16 18:15:29]

https://codereview.chromium.org/2068413002/diff/20001/cc/layers/picture_layer...
File cc/layers/picture_layer_impl_unittest.cc (right):

https://codereview.chromium.org/2068413002/diff/20001/cc/layers/picture_layer...
cc/layers/picture_layer_impl_unittest.cc:928:
active_layer()->SetHasWillChangeTransformHint(true);
What do you think of the test changes in
https://codereview.chromium.org/1474853002/diff/1/cc/layers/picture_layer_imp...
vs the changes you made here to use will-change?

[vmpstr, 2016-06-17 18:46:59]

I've added more checks in the unittest... Without will change, it's kind of a
boring test since it just creates new tilings at the new ideal scale all the
time. 

Also, a rebase snuck in there... sorry.

[danakj, 2016-06-17 19:01:06]

OK LGTM Thanks

[chrishtr, 2016-06-20 16:05:41]

The intent-to-ship got 3 LGTMs. Ok to commit this.

[chrishtr, 2016-06-20 17:48:39]

lgtm

Blink code LGTM % comment.

https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/UseCounter.h (left):

https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/UseCounter.h:1179:
FixedRasterScaleBlurryContent = 1373,
Please leave these in, for historical matching, with a comment that they are now
unused.

[nyquist, 2016-06-20 17:58:06]

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

[nyquist, 2016-06-20 17:58:06]

blimp lgtm

[vmpstr, 2016-06-20 18:06:21]

vmpstr@chromium.org changed reviewers:
+ sievers@chromium.org

[vmpstr, 2016-06-20 18:06:23]

+sievers for content/. Please take a look.

https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/UseCounter.h (left):

https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/UseCounter.h:1179:
FixedRasterScaleBlurryContent = 1373,
On 2016/06/20 17:48:39, chrishtr wrote:
> Please leave these in, for historical matching, with a comment that they are
now
> unused.

Done. I also removed the layout test, since it's not working/testing anything
anymore.

[no sievers, 2016-06-21 23:07:28]

On 2016/06/20 18:06:23, vmpstr wrote:
> +sievers for content/. Please take a look.
> 
>
https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/frame/UseCounter.h (left):
> 
>
https://codereview.chromium.org/2068413002/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/frame/UseCounter.h:1179:
> FixedRasterScaleBlurryContent = 1373,
> On 2016/06/20 17:48:39, chrishtr wrote:
> > Please leave these in, for historical matching, with a comment that they are
> now
> > unused.
> 
> Done. I also removed the layout test, since it's not working/testing anything
> anymore.

lgtm

[vmpstr, 2016-06-21 23:59:43]

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

[commit-bot: I haz the power, 2016-06-22 00:00:45]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2068413002/60001

[commit-bot: I haz the power, 2016-06-22 00:14:58]

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

[commit-bot: I haz the power, 2016-06-22 00:14:59]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[chrishtr, 2016-06-22 20:19:27]

vmpstr raised a question offline about whether we need to properly plumb the
willChangeTransform
bit to contents layers in cases when we use GraphicsLayer::setContentsTo(..) to
set up a two-layer representation of certain content. I looked into it and these
are the cases when we use it:

1. Directly composited images
2. Certain kinds of scrollbars
3. Plugins
4. Remote frames (OOPIF)
5. Video
6. OffscreenCanvas
7. Accelerated canvas

I don't think this CL should apply to any of those cases, since they are all
cases in which raster behavior should be delegated to special code paths.
vmpstr, do you agree?

[vmpstr, 2016-06-22 20:26:00]

On 2016/06/22 20:19:27, chrishtr wrote:
> vmpstr raised a question offline about whether we need to properly plumb the
> willChangeTransform
> bit to contents layers in cases when we use GraphicsLayer::setContentsTo(..)
to
> set up a two-layer representation of certain content. I looked into it and
these
> are the cases when we use it:
> 
> 1. Directly composited images
> 2. Certain kinds of scrollbars
> 3. Plugins
> 4. Remote frames (OOPIF)
> 5. Video
> 6. OffscreenCanvas
> 7. Accelerated canvas
> 
> I don't think this CL should apply to any of those cases, since they are all
> cases in which raster behavior should be delegated to special code paths.
> vmpstr, do you agree?

That makes sense to me. Thanks for looking into it. I'll start landing this.

[vmpstr, 2016-06-22 20:26:32]

The CQ bit was checked by vmpstr@chromium.org

[vmpstr, 2016-06-22 20:26:32]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
nyquist@chromium.org, chrishtr@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2068413002/#ps80001
(title: "compile fix")

[commit-bot: I haz the power, 2016-06-22 20:27:13]

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

[commit-bot: I haz the power, 2016-06-22 23:13:55]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-06-22 23:16:50]

Description was changed from

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=600867
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG=600867
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[commit-bot: I haz the power, 2016-06-22 23:16:53]

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