[Master/Overview CL] Make PageScaleFactor work for oopif subframe.

Make PageScaleFactor work for oopif subframe.

Ooopif sub-frames render in a separate process, with a separate
LayerTree and compositor. The current CC framework expects page scale
to be a main-frame concept, but at present all the subframe really
needs is a correct value for the raster scale.

This can be accomplised in CC by always including the layer tree's
page scale factor in the raster scale if there's no PageScaleLayer,
which is always the case for an oopif sub-frame.

This CL includes the basic plumbing to push notification of page scale
changes, via the deltas from GesturePinchUpdate, to all the page's
RenderViews.

*** This CL is proof-of-concept, and needs work before it is landed.
See the TODO's within.

BUG=654917
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

[wjmaclean, 2016-10-14 19:01:54]

Description was changed from

==========
Make PageScaleFactor work for oopif subframe.

Ooopif sub-frames render in a separate process, with a separate
LayerTree and compositor. The current CC framework expects page scale
to be a main-frame concept, but at present all the subframe really
needs is a correct value for the raster scale.

This can be accomplised in CC by always including the layer tree's
page scale factor in the raster scale if there's no PageScaleLayer,
which is always the case for an oopif sub-frame.

This CL includes the basic plumbing to push notification of page scale
changes, via the deltas from GesturePinchUpdate, to all the page's
RenderViews.

*** This CL is proof-of-concept, and needs work before it is landed.
See the TODO's within.

BUG=654917
==========

to

==========
Make PageScaleFactor work for oopif subframe.

Ooopif sub-frames render in a separate process, with a separate
LayerTree and compositor. The current CC framework expects page scale
to be a main-frame concept, but at present all the subframe really
needs is a correct value for the raster scale.

This can be accomplised in CC by always including the layer tree's
page scale factor in the raster scale if there's no PageScaleLayer,
which is always the case for an oopif sub-frame.

This CL includes the basic plumbing to push notification of page scale
changes, via the deltas from GesturePinchUpdate, to all the page's
RenderViews.

*** This CL is proof-of-concept, and needs work before it is landed.
See the TODO's within.

BUG=654917
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[wjmaclean, 2016-10-14 19:03:53]

Description was changed from

==========
Make PageScaleFactor work for oopif subframe.

Ooopif sub-frames render in a separate process, with a separate
LayerTree and compositor. The current CC framework expects page scale
to be a main-frame concept, but at present all the subframe really
needs is a correct value for the raster scale.

This can be accomplised in CC by always including the layer tree's
page scale factor in the raster scale if there's no PageScaleLayer,
which is always the case for an oopif sub-frame.

This CL includes the basic plumbing to push notification of page scale
changes, via the deltas from GesturePinchUpdate, to all the page's
RenderViews.

*** This CL is proof-of-concept, and needs work before it is landed.
See the TODO's within.

BUG=654917
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Make PageScaleFactor work for oopif subframe.

Ooopif sub-frames render in a separate process, with a separate
LayerTree and compositor. The current CC framework expects page scale
to be a main-frame concept, but at present all the subframe really
needs is a correct value for the raster scale.

This can be accomplised in CC by always including the layer tree's
page scale factor in the raster scale if there's no PageScaleLayer,
which is always the case for an oopif sub-frame.

This CL includes the basic plumbing to push notification of page scale
changes, via the deltas from GesturePinchUpdate, to all the page's
RenderViews.

*** This CL is proof-of-concept, and needs work before it is landed.
See the TODO's within.

BUG=654917
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[wjmaclean, 2016-10-14 19:03:53]

wjmaclean@chromium.org changed reviewers:
+ creis@chromium.org, vollick@chromium.org

[wjmaclean, 2016-10-14 19:06:15]

This CL is still very experimental, and certainly needs more testing on my part,
but if you're interested in the approach, or want to do a quick sanity check,
here it is.

vollick@ - Do the CC changes seem reasonable?

creis@ - Other than perhaps converting this to use the deltas, and removing the
static float in RVI::OnSetPageScaleFactor(), does the basic approach seem ok to
you?

[wjmaclean, 2016-10-14 19:13:18]

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

[Charlie Reis, 2016-10-14 19:13:33]

creis@chromium.org changed reviewers:
+ kenrb@chromium.org

[commit-bot: I haz the power, 2016-10-14 19:13:49]

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

[Charlie Reis, 2016-10-14 19:15:56]

creis@chromium.org changed reviewers:
+ lfg@chromium.org
- kenrb@chromium.org

[Charlie Reis, 2016-10-14 19:16:52]

creis@chromium.org changed reviewers:
+ kenrb@chromium.org

[Charlie Reis, 2016-10-14 19:17:46]

[+lfg, kenrb, site-isolation-reviews]

Thanks for looking for a way forward!

On 2016/10/14 19:06:15, wjmaclean wrote:
> This CL is still very experimental, and certainly needs more testing on my
part,
> but if you're interested in the approach, or want to do a quick sanity check,
> here it is.
> 
> vollick@ - Do the CC changes seem reasonable?
> 
> creis@ - Other than perhaps converting this to use the deltas, and removing
the
> static float in RVI::OnSetPageScaleFactor(), does the basic approach seem ok
to
> you?

I feel like Lucas or Ken might be a better reviewer in this area than me, though
I'm happy to look over it a bit later in the review.

[Ian Vollick, 2016-10-14 19:40:31]

https://codereview.chromium.org/2417783005/diff/1/cc/layers/picture_layer_imp...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/2417783005/diff/1/cc/layers/picture_layer_imp...
cc/layers/picture_layer_impl.cc:1253: (!layer_tree_impl()->PageScaleLayer() ||
IsAffectedByPageScale())
So we take the current page scale factor if we don't have a page scale layer at
all (which is true for subframes today), or we know we're affected by it? (And
the rest of your CL ensures that the page scale is plumbed so that
current_page_scale_factor will have what you need?)

This does seem plausible, but please get the opinion of people that know more
about raster scale.

[wjmaclean, 2016-10-14 19:46:59]

On 2016/10/14 19:40:31, Ian Vollick wrote:
>
https://codereview.chromium.org/2417783005/diff/1/cc/layers/picture_layer_imp...
> File cc/layers/picture_layer_impl.cc (right):
> 
>
https://codereview.chromium.org/2417783005/diff/1/cc/layers/picture_layer_imp...
> cc/layers/picture_layer_impl.cc:1253: (!layer_tree_impl()->PageScaleLayer() ||
> IsAffectedByPageScale())
> So we take the current page scale factor if we don't have a page scale layer
at
> all (which is true for subframes today), or we know we're affected by it? (And
> the rest of your CL ensures that the page scale is plumbed so that
> current_page_scale_factor will have what you need?)
> 
> This does seem plausible, but please get the opinion of people that know more
> about raster scale.

Gah, just found a problem with this :-( ... but I think the basic idea is valid,
so I'll try and see if I can fix it ...

[commit-bot: I haz the power, 2016-10-14 19:57:14]

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

[commit-bot: I haz the power, 2016-10-14 19:57:15]

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

[wjmaclean, 2016-11-02 20:32:01]

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

[commit-bot: I haz the power, 2016-11-02 20:32:44]

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

[wjmaclean, 2016-11-02 20:42:33]

wjmaclean@chromium.org changed reviewers:
- vollick@chromium.org

[commit-bot: I haz the power, 2016-11-02 21:03:53]

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

[commit-bot: I haz the power, 2016-11-02 21:03:55]

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...)

[wjmaclean, 2016-11-03 13:53:19]

Patchset #13 (id:230001) has been deleted

[wjmaclean, 2016-11-03 14:27:43]

Patchset #13 (id:250001) has been deleted

[wjmaclean, 2016-11-03 14:40:11]

Patchset #13 (id:270001) has been deleted

[wjmaclean, 2016-11-03 15:08:34]

Patchset #13 (id:290001) has been deleted

[wjmaclean, 2016-11-03 15:39:09]

Patchset #13 (id:310001) has been deleted

[wjmaclean, 2016-11-03 16:34:12]

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

[commit-bot: I haz the power, 2016-11-03 16:34:49]

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-11-03 18:40:46]

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

[commit-bot: I haz the power, 2016-11-03 18:40:47]

Dry run: This issue passed the CQ dry run.