Clean up viewport scrolling methods in CC

Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.

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

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

[bokan, 2016-09-30 23:57:55]

Description was changed from

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's
not clear which is which. This caused the regression in the CL and is generally
problematic because the semantics aren't clear. I've created
Viewport::MainScrollLayer to designate
which viewport layer is used for scrolling and replaced uses in the code that
are semantically using the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

BUG=651515
==========

to

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's
not clear which is which. This caused the regression in the CL and is generally
problematic because the semantics aren't clear. I've created
Viewport::MainScrollLayer to designate
which viewport layer is used for scrolling and replaced uses in the code that
are semantically using the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

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

[bokan, 2016-09-30 23:58:48]

Description was changed from

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's
not clear which is which. This caused the regression in the CL and is generally
problematic because the semantics aren't clear. I've created
Viewport::MainScrollLayer to designate
which viewport layer is used for scrolling and replaced uses in the code that
are semantically using the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

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

to

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.


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

[bokan, 2016-09-30 23:58:48]

bokan@chromium.org changed reviewers:
+ boliu@chromium.org

[bokan, 2016-10-01 00:01:15]

Description was changed from

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.


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

to

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.


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

[bokan, 2016-10-01 00:01:56]

Hi Bo,

This is a first step to relanding my patch. I'd like to land this first, rebase
my patch over it and then it should be able to reland with minimal changes to
the original CL, just changing the layer returned from the new
Viewport::MainScrollLayer. ptal.

[boliu, 2016-10-01 00:10:38]

I don't really know this code. Did you want me to test it, or...?

[bokan, 2016-10-01 00:23:01]

On 2016/10/01 00:10:38, boliu wrote:
> I don't really know this code. Did you want me to test it, or...?

No, I tested it. Sorry, thought you k we these parts. I'll ask someone else,
thanks.

[bokan, 2016-10-01 00:23:17]

bokan@chromium.org changed reviewers:
+ tdresser@chromium.org
- boliu@chromium.org

[bokan, 2016-10-01 00:23:30]

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

[commit-bot: I haz the power, 2016-10-01 00:24:01]

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

[bokan, 2016-10-01 00:24:24]

Tim, ptal. This should make the followup of relanding the original cl easier

[commit-bot: I haz the power, 2016-10-01 00:37:18]

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

[commit-bot: I haz the power, 2016-10-01 00:37:19]

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

[bokan, 2016-10-01 02:03:44]

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

[commit-bot: I haz the power, 2016-10-01 02:04:11]

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-10-01 03:04:05]

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

[commit-bot: I haz the power, 2016-10-01 03:04:06]

Dry run: This issue passed the CQ dry run.

[tdresser, 2016-10-03 12:14:43]

LGTM.

I hadn't previously thought about the fact that it's the inner viewport that
scrolls (currently) but the outer viewport that has the scrollbars.

That's pretty gnarly.

[bokan, 2016-10-03 13:02:45]

bokan@chromium.org changed reviewers:
+ aelias@chromium.org

[bokan, 2016-10-03 13:02:46]

+aelias@ for CC OWNER

[aelias_OOO_until_Jul13, 2016-10-03 19:29:32]

lgtm

[bokan, 2016-10-03 21:11:41]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2016-10-03 21:12:26]

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-10-03 23:01:26]

Description was changed from

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.


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

to

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.


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

[commit-bot: I haz the power, 2016-10-03 23:01:27]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-10-03 23:03:25]

Description was changed from

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.


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

to

==========
Clean up viewport scrolling methods in CC

Currently, CC uses InnerViewportScrollLayer to designate scrolling of the
viewport. This is problematic as there's also non-scrolling uses of
InnerViewportScrollLayer and it's not clear which is which. This caused the
regression in the CL and is generally problematic because the semantics aren't
clear. I've created Viewport::MainScrollLayer to designate which viewport layer
is used for scrolling and replaced uses in the code that are semantically using
the "viewport scrolling representative".

I've also removed some viewport scrolling methods in LayerTreeHostImpl and
replaced them with calls into cc::Viewport.

Note, this patch doesn't actually change any behavior. The original CL that
caused the regression was reverted. The problem was that it missed some viewport
scrolling uses of InnerViewportScrollLayer. This patch makes it easy to change
the layer which represents the viewport. Once it lands I can reland the reverted
CL using the MainScrollLayer method.

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

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

[commit-bot: I haz the power, 2016-10-03 23:03:25]

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