Don't let PaintInvalidationLocationChange shadow other reasons

Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068
Committed: https://crrev.com/e5ad1cf0775659d2db94a9fd7fe5825453109bba
Cr-Commit-Position: refs/heads/master@{#391751}

[Xianzhu, 2016-05-04 17:36:50]

Description was changed from

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation.

BUG=602068
==========

to

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068
==========

[Xianzhu, 2016-05-04 18:15:08]

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

[Xianzhu, 2016-05-04 18:15:09]

I've checked all layout test failures locally, and they all contain paint
invalidation reason changes. Will include rebaselines in the next patch.

[chrishtr, 2016-05-04 23:17:36]

https://codereview.chromium.org/1951043002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutObject.cpp (right):

https://codereview.chromium.org/1951043002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutObject.cpp:1525: return
PaintInvalidationLocationChange;
It looks like no code actually checks for PaintInvalidationLocationChange now.
Does it
make sense to keep it as an enum value?

[Xianzhu, 2016-05-04 23:25:46]

https://codereview.chromium.org/1951043002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutObject.cpp (right):

https://codereview.chromium.org/1951043002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutObject.cpp:1525: return
PaintInvalidationLocationChange;
On 2016/05/04 23:17:36, chrishtr wrote:
> It looks like no code actually checks for PaintInvalidationLocationChange now.
> Does it
> make sense to keep it as an enum value?

I think like some other enum values, it might be not meaningful for the program,
but it's still useful for debugging.

[chrishtr, 2016-05-04 23:27:42]

lgtm

[chrishtr, 2016-05-04 23:27:44]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2016-05-04 23:28:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1951043002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1951043002/20001

[Xianzhu, 2016-05-05 02:34:50]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2016-05-05 02:34:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/1951043002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2016-05-05 02:35:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1951043002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1951043002/60001

[commit-bot: I haz the power, 2016-05-05 03:57:04]

Description was changed from

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068
==========

to

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068
==========

[commit-bot: I haz the power, 2016-05-05 03:57:06]

Committed patchset #4 (id:60001)

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

Description was changed from

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068
==========

to

==========
Don't let PaintInvalidationLocationChange shadow other reasons

Previously PaintInvalidationLocationChange reason shadowed other
paint invalidaiton reasons, confusing debugging paint invalidation.
For example, when an object is inserted or becomes visible,
its position may also changes from zero to non-zero, and
we mark its paint invalidation reason as "location change" instead
of "object insertion" or "become visible".

This CL not only helps paint invalidation debugging, but also reduces
churns in future changes in paint invalidation (especially when we
enable paint offset caching).

BUG=602068

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

[commit-bot: I haz the power, 2016-05-05 03:58:17]

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