Fold ScrollingCoordinatorChromium into ScrollingCoordinator and devirtualize

Fold ScrollingCoordinatorChromium into ScrollingCoordinator and devirtualize

This folds the ScrollingCoordinatorChromium subclass into the base and devirtualizes it. This also removes
most (but not all) of the ScrollingCoordinator functionality that we don't use and
deletes many files in page/scrolling/ that we don't use. There are many more cleanups
possible here - this is just a minimal first cut that doesn't (intentionally) change
any behavior.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=147653

[enne (OOO), 2013-04-04 23:05:59]

This lgtm in general, but I'm sad at the number of conflicts that vollick will
be left with if this lands first.

I think it shouldn't be that bad to put things back in the right place (after a
quick glance at his latest background patch and the changes here), other than:

https://codereview.chromium.org/13665002/diff/1/Source/WebCore/rendering/Rend...
File Source/WebCore/rendering/RenderLayerCompositor.h (left):

https://codereview.chromium.org/13665002/diff/1/Source/WebCore/rendering/Rend...
Source/WebCore/rendering/RenderLayerCompositor.h:236: void
fixedRootBackgroundLayerChanged();
vollick's patch is still using this function, so maybe you could leave it?

[jamesr, 2013-04-04 23:10:34]

The fixed background stuff isn't done in a way that works well with how we do
things.  While this will conflict with vollick's patches, I think we'd be much
better off adding fixed background support starting from scratch rather than
attempting to shoe-horn in something that looks like tilecache and then trying
to trim it down back to something sane.

[enne (OOO), 2013-04-04 23:21:07]

I'm not sure I follow.  Parts of the patch go down the same route as tile cache
but now won't.  The fixed background stuff doesn't look related to tile cache,
unless I'm missing something.

[jamesr, 2013-04-04 23:24:20]

On 2013/04/04 23:21:07, enne wrote:
> I'm not sure I follow.  Parts of the patch go down the same route as tile
cache
> but now won't.  The fixed background stuff doesn't look related to tile cache,
> unless I'm missing something.

The fixed background stuff is tied to the tile cache.  It's not runtime
reachable in chromium.

[enne (OOO), 2013-04-04 23:30:35]

Hrm.  I clearly don't understand that code enough; can you get vollick to sign
off on this too?

[jamesr, 2013-04-04 23:32:45]

On 2013/04/04 23:30:35, enne wrote:
> Hrm.  I clearly don't understand that code enough; can you get vollick to sign
> off on this too?

Definitely, although I don't want to block cleanups forever on deciding how to
add new features.  It's easy to add things back if we want them.  Having big
chunks around that we aren't using slows everything down.

[Ian Vollick, 2013-04-05 00:45:14]

On 2013/04/04 23:32:45, jamesr wrote:
> On 2013/04/04 23:30:35, enne wrote:
> > Hrm.  I clearly don't understand that code enough; can you get vollick to
sign
> > off on this too?
> 
> Definitely, although I don't want to block cleanups forever on deciding how to
> add new features.  It's easy to add things back if we want them.  Having big
> chunks around that we aren't using slows everything down.

The fixed background stuff did not actually seem to be tied to the tile cache,
despite the way the old code looked. Actually, the goal of my patch was to break
the link between tile cache and the background-attachment:fixed optimization.
Seemed to be working great. It's actually a tiny patch. I'll see if I can redo
on top of this patch.

[jamesr, 2013-04-05 01:12:47]

On 2013/04/05 00:45:14, vollick wrote:
> On 2013/04/04 23:32:45, jamesr wrote:
> > On 2013/04/04 23:30:35, enne wrote:
> > > Hrm.  I clearly don't understand that code enough; can you get vollick to
> sign
> > > off on this too?
> > 
> > Definitely, although I don't want to block cleanups forever on deciding how
to
> > add new features.  It's easy to add things back if we want them.  Having big
> > chunks around that we aren't using slows everything down.
> 
> The fixed background stuff did not actually seem to be tied to the tile cache,
> despite the way the old code looked. Actually, the goal of my patch was to
break
> the link between tile cache and the background-attachment:fixed optimization.
> Seemed to be working great. It's actually a tiny patch. I'll see if I can redo
> on top of this patch.

If you can get your patch up somewhere I can take a look at how to merge it in. 
I don't think we really want to blindly copy the fixed background layer, though,
we should consider what design makes most sense.  The counter-scrolling layer
doesn't make as much sense with the way we host the GraphicsLayer hierarchy from
the root (which is pretty different from how WebKit2 handles it).

[jamesr, 2013-04-05 18:57:20]

On 2013/04/05 01:12:47, jamesr wrote:
> On 2013/04/05 00:45:14, vollick wrote:
> > On 2013/04/04 23:32:45, jamesr wrote:
> > > On 2013/04/04 23:30:35, enne wrote:
> > > > Hrm.  I clearly don't understand that code enough; can you get vollick
to
> > sign
> > > > off on this too?
> > > 
> > > Definitely, although I don't want to block cleanups forever on deciding
how
> to
> > > add new features.  It's easy to add things back if we want them.  Having
big
> > > chunks around that we aren't using slows everything down.
> > 
> > The fixed background stuff did not actually seem to be tied to the tile
cache,
> > despite the way the old code looked. Actually, the goal of my patch was to
> break
> > the link between tile cache and the background-attachment:fixed
optimization.
> > Seemed to be working great. It's actually a tiny patch. I'll see if I can
redo
> > on top of this patch.
> 
> If you can get your patch up somewhere I can take a look at how to merge it
in. 
> I don't think we really want to blindly copy the fixed background layer,
though,
> we should consider what design makes most sense.  The counter-scrolling layer
> doesn't make as much sense with the way we host the GraphicsLayer hierarchy
from
> the root (which is pretty different from how WebKit2 handles it).

Ian put a patch up here: https://codereview.chromium.org/13462003/ based on top
of this one.  We'll discuss the design/etc over there.  Regardless, it looks
like it's not all that hard to add back the bits of RLB/RLC if that's how we end
up doing this so I'm going to go ahead with this patch.

[enne (OOO), 2013-04-05 19:35:50]

sgtm

[jamesr, 2013-04-05 19:49:53]

Committed patchset #1 manually as r147653 (presubmit successful).