Currently, if a scroller is composited, its scrollbars will get layers in CC. If it's non-composited, its scrollbars will be painted directly into the scroller's backing canvas (see these slides for a more detailed break down of how scrollbars work today: https://docs.google.com/a/chromium.org/presentation/d/1lHuKG6ROJDCBQnQvPfWPiOZPpTXLZQCARTQgsHPFRHk/edit?usp=sharing).

Much of the pain of this double implementation is well handled, paint code is set in one place and event handling is done entirely on the main thread. We just have some indirection and plumbing to make it work in both places.

However, animations for overlay scrollbars are only available on the CC side. This means non composited scrollers don't get animations for scrollbars (scrollbars in a non-composited scroller on Android will never disappear). Duplicating the animation logic to the main thread would be a maintenance burden and bad for performance.

It seems that with SPv2, since compositing decisions happen in CC, we should be able to create CC scrollbars even for scrollers that need to repaint on each scroll. In that case, we could make sure all scrollbars are always animated. It might even make sense to move the event handling logic from Blink into CC.