Hardcode scrollbar rendering for Android

Hardcoded scrollbar for Android
    
This class a quick hack scrollbar for Android for M25.
Need to disable WebKit-side scrollbar for now because sublayer
scrollbars aren't coordinated in the compositor, and the update latency is
too long when impl-side painting is enabled. We should remove this hack
after implementing the coordinator for sublayer scrollbars.

BUG=173302

[trchen, 2013-02-05 10:17:26]

So again I introduced a hardcoded scrollbar that is similar to what we did for
M18, because we can't use WebKit-side scrollbar for performance issue. (scroll
offset not coordinated, and we're observing some needless invalidation as well)

The scrollbar is a quick hack, but should suit our need for a usable M25
release. PTAL, thanks!

[danakj, 2013-02-05 17:55:02]

Some style nits, the new files are mostly in chromium style, but still have
webkit style isms.

I don't like this, but I guess that shouldn't be a shock :) At the least, I
think the scrollbar should be a layer (multiple layers?) and append quads
through the standard mechanisms. If this is for sublayer scrollbars, why does it
only put quads at the front of the root renderpass?

I strongly dislike #ifdef ANDROID in the code other than setting flags on
LayerTreeSettings. This makes unit tests break on android bots, and makes it
hard/impossible to unit test code touched by the ifdefs.

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.cc
File cc/hardcoded_scrollbar.cc (right):

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.cc#...
cc/hardcoded_scrollbar.cc:107: {
{ on previous line

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h
File cc/hardcoded_scrollbar.h (right):

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:1: // Copyright 2011 The Chromium Authors. All rights
reserved.
2013

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:27: HardcodedScrollbar(LayerTreeHostImpl*
layer_tree_host_impl);
1 space before this

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:34: LayerTreeHostImpl* layer_tree_host_impl_;
1 space

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:45: public:
1 space

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:46: inline HardcodedScrollbar(LayerTreeHostImpl*) { }
no space between {}s

https://codereview.chromium.org/12147005/diff/3001/cc/hardcoded_scrollbar.h#n...
cc/hardcoded_scrollbar.h:47: inline void Animate(base::TimeTicks) { }
variables should still get names i believe

https://codereview.chromium.org/12147005/diff/3001/cc/layer_tree_host_impl.cc
File cc/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/12147005/diff/3001/cc/layer_tree_host_impl.cc...
cc/layer_tree_host_impl.cc:248: m_hardcodedScrollbar.Animate(monotonicTime);
why isn't this in animateScrollbars?

[jamesr, 2013-02-05 17:59:36]

Why is it not sufficient to override the thumb painting behavior of the existing
scrollbar class?

[trchen, 2013-02-05 20:33:51]

On 2013/02/05 17:59:36, jamesr wrote:
> Why is it not sufficient to override the thumb painting behavior of the
existing
> scrollbar class?

We used to doubt that scrollbars are causing unnecessary invalidation on the
main layer. I just synced up with xianzhu, he confirmed it was a wrong guess.

So we might not need this quick hack scrollbar after all. aelias@ is suggesting
that implementing proper coordinator for sublayer scrollbars shouldn't be that
difficult. I'll try if I can finish it by tonight then we can abandon this hack.