Paint invalidation of local attachment backgrounds

Previously if a local attachment background was painted on the scrolling
contents layer, we called invalidatePaintUsingContainer() with the visual
rect of the object, and in setBackingNeedsPaintInvalidationInRect()
we invalidated the rect on the main layer, and invalidated the whole
scrolling contents layer.

This CL specially handles background invalidation on scrolling contents
layer with LayoutObject::backgroundChangedSinceLastPaintInvalidation()
and a new paint invalidation reason PaintInvalidationBackgroundOnScrollingContentsLayer.
Also supports incremental invalidation of backgrounds on scrolling
contents layer caused by layout overflow change, if possible.

We need this change because now more backgrounds are/will be treated as local
attachment [equivalent] and previous handling of paint invalidation of
them caused too many unnecessary full invalidation on both the container
layer and the scrolling contents layer.

We (will) have more background treated as local attachment because of
the following reasons:
- With rootLayerScrolling, most LayoutViews (except those with fixed background)
  are treated as normal scrolling object with local attachment background.
  Always full invalidation of either container or contents layer is not
  acceptable at least on Android on which hiding/showing the top control
  (which causes resize of the LayoutView) is a key scenario of performance
  and power consumption;
- With composited scrolling with opaque background regardless of LCD text,
  we treat normal solid color backgrounds as local attachment backgrounds.
  Full paint invalidation of scrolling contents layer of them is a big
  regression.

BUG=660156,568847
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2498823002
Cr-Commit-Position: refs/heads/master@{#433093}
21 files changed