Paint invalidation of local attachment backgrounds

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

Committed: https://crrev.com/a2907993ffbc7f8e21b2dce12c2ff5d541afca7e
Cr-Commit-Position: refs/heads/master@{#433093}

[Xianzhu, 2016-11-12 20:52:11]

Description was changed from

==========
Paint invalidation of local attachment backgrounds

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

This CL specially handles background invalidation on scrolling contents
layer with a new flag
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.

BUG=660156
==========

to

==========
Paint invalidation of local attachment backgrounds

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

This CL specially handles background invalidation on scrolling contents
layer with a new flag
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.

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

[Xianzhu, 2016-11-12 20:52:16]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-12 20:52:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-12 20:54:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-12 20:54:37]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Xianzhu, 2016-11-12 23:27:06]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-12 23:27:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-12 23:40:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-12 23:40:20]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[Xianzhu, 2016-11-13 01:46:29]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-13 01:46:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-13 02:59:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-13 02:59:19]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Xianzhu, 2016-11-14 22:54:49]

Description was changed from

==========
Paint invalidation of local attachment backgrounds

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

This CL specially handles background invalidation on scrolling contents
layer with a new flag
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.

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

to

==========
Paint invalidation of local attachment backgrounds

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

This CL specially handles background invalidation on scrolling contents
layer with a new flag
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.

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

[Xianzhu, 2016-11-15 05:03:00]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-15 05:03:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 05:06:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-15 05:06:35]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Xianzhu, 2016-11-16 18:02:55]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-16 18:03:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-16 19:49:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-16 19:49:23]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Xianzhu, 2016-11-16 22:20:13]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org

[chrishtr, 2016-11-17 00:12:54]

Is the main purpose of this CL avoiding special-casing with RLS? Or performance?
Or general
code complexity? Or a mix of all of them?

It seems like it's making things more complicated to support this case. Am I
wrong, or is this
an important case to optimize?

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp (right):

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:90: if (rightDelta
!= bottomDelta) {
Why this new conditional?

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:168: bool
BoxPaintInvalidator::backgroundPositionsInLayoutOverflowRect() {
backgroundGeometryDependsOnLayoutOverflowRect() ?

[Xianzhu, 2016-11-17 17:02:21]

Description was changed from

==========
Paint invalidation of local attachment backgrounds

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

This CL specially handles background invalidation on scrolling contents
layer with a new flag
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.

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

to

==========
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 a new flag
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
==========

[Xianzhu, 2016-11-17 17:04:01]

On 2016/11/17 00:12:54, chrishtr wrote:
> Is the main purpose of this CL avoiding special-casing with RLS? Or
performance?
> Or general
> code complexity? Or a mix of all of them?
> 
> It seems like it's making things more complicated to support this case. Am I
> wrong, or is this
> an important case to optimize?

Added the following paragraphs in description:

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.

[Xianzhu, 2016-11-17 17:37:53]

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp (right):

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:90: if (rightDelta
!= bottomDelta) {
On 2016/11/17 00:12:54, chrishtr wrote:
> Why this new conditional?

This is avoid duplicated invalidation if oldRect or newRect is empty. Changed to
a more explicit way.

https://codereview.chromium.org/2498823002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:168: bool
BoxPaintInvalidator::backgroundPositionsInLayoutOverflowRect() {
On 2016/11/17 00:12:54, chrishtr wrote:
> backgroundGeometryDependsOnLayoutOverflowRect() ?

This name is much better. Done.

[chrishtr, 2016-11-17 20:42:36]

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(left):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:1261:
if (scrollSize != m_scrollingContentsLayer->size() ||
Why this change?

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp (right):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:192:
m_box.mustInvalidateFillLayersPaintOnHeightChange(
This part seems to be new in this CL. What is it for?

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:226: if
(m_box.isLayoutView() &&
Where did the implementation of 226-234 used to be?  This is if painting
of background was not onto the scrolling contents layer, which invalidated
somehow..

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:242:
oldLayoutOverflow.isEmpty() || newLayoutOverflow.isEmpty()) {
Maybe move line 242 up and use the condition to set
shouldFullyInvalidateOnScrollingContentsLayer to true?

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.h (right):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.h:33: bool
shouldFullyInvalidateBackgroundOnLayoutOverflowChange(const LayoutRect&,
Document these two arguments

[Xianzhu, 2016-11-17 23:36:31]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[Xianzhu, 2016-11-17 23:36:41]

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(left):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:1261:
if (scrollSize != m_scrollingContentsLayer->size() ||
On 2016/11/17 20:42:36, chrishtr wrote:
> Why this change?

This fully invalidated the scrolling contents layer when it's resized, which
would defeat the the new code in BoxPaintInvalidator.

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp (right):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:192:
m_box.mustInvalidateFillLayersPaintOnHeightChange(
On 2016/11/17 20:42:36, chrishtr wrote:
> This part seems to be new in this CL. What is it for?

Previously we always fully invalidated the scrolling contents layer with
following code:
1. in CompositedLayerMapping (when the layer is resized),
2. oldcode line 139-141 which forces full paint invalidation for
background-attachment:local on layout overflow change,
3. in ObjectPaintInvalidator::setBackingNeedsPaintInvalidationInRect() when
anything is invalidated on the container layer.

Now this allows us to do incremental invalidation of background on the scrolling
contents layer.

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:226: if
(m_box.isLayoutView() &&
On 2016/11/17 20:42:36, chrishtr wrote:
> Where did the implementation of 226-234 used to be?  This is if painting
> of background was not onto the scrolling contents layer, which invalidated
> somehow..

See my last comment.

The LayoutView condition is wrong. Removed it. Added new tests to cover the case
(CompositedLayoutViewGradientResize and NonCompositedLayoutViewGradientResize).

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.cpp:242:
oldLayoutOverflow.isEmpty() || newLayoutOverflow.isEmpty()) {
On 2016/11/17 20:42:36, chrishtr wrote:
> Maybe move line 242 up and use the condition to set
> shouldFullyInvalidateOnScrollingContentsLayer to true?

Just noticed I already had the conditions in
shouldFullyInvalidateBackgroundOnLayoutOverflowChange(). Removed the conditions
here.

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/paint/BoxPaintInvalidator.h (right):

https://codereview.chromium.org/2498823002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/paint/BoxPaintInvalidator.h:33: bool
shouldFullyInvalidateBackgroundOnLayoutOverflowChange(const LayoutRect&,
On 2016/11/17 20:42:36, chrishtr wrote:
> Document these two arguments

Done.

[commit-bot: I haz the power, 2016-11-17 23:38:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chrishtr, 2016-11-18 00:48:40]

lgtm

Nice work!

backgroundChangedSinceLastPaintInvalidation is not actually new in this CL,
please adjust
the description before committing.

[Xianzhu, 2016-11-18 00:52:23]

Description was changed from

==========
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 a new flag
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
==========

to

==========
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
==========

[Xianzhu, 2016-11-18 00:52:39]

On 2016/11/18 00:48:40, chrishtr wrote:
> lgtm
> 
> Nice work!
> 
> backgroundChangedSinceLastPaintInvalidation is not actually new in this CL,
> please adjust
> the description before committing.

Done.

[commit-bot: I haz the power, 2016-11-18 01:42:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-18 01:42:23]

Dry run: Try jobs failed on following builders:
  linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)

[Xianzhu, 2016-11-18 02:26:16]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2016-11-18 02:27:45]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-18 04:16:42]

Description was changed from

==========
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
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-11-18 04:16:44]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-11-18 04:18:31]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/a2907993ffbc7f8e21b2dce12c2ff5d541afca7e
Cr-Commit-Position: refs/heads/master@{#433093}
==========

[commit-bot: I haz the power, 2016-11-18 04:18:33]

Patchset 8 (id:??) landed as
https://crrev.com/a2907993ffbc7f8e21b2dce12c2ff5d541afca7e
Cr-Commit-Position: refs/heads/master@{#433093}