Cleanup ScrollableArea scrolling API

Cleanup ScrollableArea scrolling API

This CL attempts to consolidate the various scroll methods in ScrollableArea
and associated classes into a more rational set. A summary of the changes:

-Consolidated most scrolling to happen through setScrollPosition

-Added an enum ScrollType since the behavior of a scroll varies slightly based
on whether the scroll is initiated programmatically, by the user, or comes
from a compositor update.

-Renamed scroll to userScroll to make it more clear that this method is for
scroll gestures originating from user generated events.

-Call updateCompositorScrollAnimations on RootFrameViewport since the new
control flow causes us to use RootFrameViewport's scroll animators in the
programmatic case.

-Removed unused methods in ScrollAnimatorMac

-Route instant programmatic scrolls through ProgrammaticScrollAnimator rather
than ScrollAnimator. In general, made the two classes more symmetric w.r.t
each other. e.g updating ScrollableArea now takes same path through
notifyPositionChanged -> ScrollableArea::scrollPositionChanged for both
classes.

-Moved scroll position truncation to happen in scrollPositionChanged rather
than ScrollAnimators.

BUG=

[bokan, 2015-06-02 11:28:56]

Patchset #1 (id:1) has been deleted

[bokan, 2015-06-02 11:29:11]

Patchset #1 (id:20001) has been deleted

[bokan, 2015-06-02 11:29:25]

Patchset #1 (id:40001) has been deleted

[bokan, 2015-06-02 11:29:36]

Patchset #1 (id:60001) has been deleted

[bokan, 2015-06-02 11:29:51]

Patchset #1 (id:70001) has been deleted

[bokan, 2015-06-02 11:30:03]

Patchset #1 (id:90001) has been deleted

[bokan, 2015-06-02 13:36:37]

Patchset #1 (id:110001) has been deleted

[bokan, 2015-06-02 15:36:07]

Patchset #1 (id:130001) has been deleted

[bokan, 2015-06-02 16:16:45]

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

[bokan, 2015-06-02 16:16:46]

Hey Steve, WDYT?

Compare the picture in this CL (http://bokan.ca/new-scrollablearea.png) vs what
exists now:
https://docs.google.com/presentation/d/1vmnIwRdJP25J2j6MbEADJeYmDNP88Bp6BxLuV...

There's still some work to do but I think this is a step in the right direction.
Some things that still bug me:

We clamp in inconsistent places with inconsistent methods

Scroll origin adjustments for RTL seem to be inconsistent between FrameView and
DPLSA (I don't know much about RTL yet though so I maybe I just don't get how
it's arranged). I had to hack around this a bit here.

The scroll and handleWheel methods should be unified and moved out of
ScrollableArea to a place where all they do is translate the granularity,
orientation, etc. into a scroll delta and call
ScrollableArea::setScrollPosition. 

In general, in follow-up patches I'd like to start moving as much logic back
into ScrollableArea and out of the derived classes as possible. Thoughts?

[skobes, 2015-06-02 18:24:32]

On 2015/06/02 16:16:46, bokan wrote:
> Hey Steve, WDYT?
> 
> Compare the picture in this CL (http://bokan.ca/new-scrollablearea.png) vs
what
> exists now:
>
https://docs.google.com/presentation/d/1vmnIwRdJP25J2j6MbEADJeYmDNP88Bp6BxLuV...

This looks awesome!  Haven't reviewed in detail yet but I really like the
simplified picture.

This CL is quite large.  Is there any way to break it up into smaller pieces, or
is everything interdependent?

> In general, in follow-up patches I'd like to start moving as much logic back
> into ScrollableArea and out of the derived classes as possible. Thoughts?

I agree with this goal, that being said you may not want to spend too much time
refactoring the FrameView implementation, assuming root layer scrolling is
eventually going to land. :)

[bokan, 2015-06-02 18:33:09]

> This CL is quite large.  Is there any way to break it up into smaller pieces,
or
> is everything interdependent?
> 

I kept it all together as I've heard in the past some reviewers prefer holistic
CL. Much of it is interdependent, but I think I can split out at least some of
it. I'll put up a new patch.

> > In general, in follow-up patches I'd like to start moving as much logic back
> > into ScrollableArea and out of the derived classes as possible. Thoughts?
> 
> I agree with this goal, that being said you may not want to spend too much
time
> refactoring the FrameView implementation, assuming root layer scrolling is
> eventually going to land. :)

I don't mean to do any refactoring there. I mean to unify the implementation
with DPLScrollableArea and move it to ScrollableArea (or make it work through
DPLSA). I'm thinking of things like how clamping and RTL paths diverge between
these two classes.

[skobes, 2015-06-02 18:47:20]

On 2015/06/02 18:33:09, bokan wrote:
> I don't mean to do any refactoring there. I mean to unify the implementation
> with DPLScrollableArea and move it to ScrollableArea (or make it work through
> DPLSA). I'm thinking of things like how clamping and RTL paths diverge between
> these two classes.

Yeah unifying divergent behavior between FrameView and DPLSA is part of what we
are trying to do with root layer scrolling.  I'm just saying, don't think of it
as hoisting things from FrameView into ScrollableArea.  Rather, fix whatever
prevents DPLSA from being the sole implementation, and treat FrameView as
eventual dead code.