[SPv2] Track paint offset change

[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

Committed: https://crrev.com/4a4980562262f80dfb66739d84c49251164ac373
Cr-Commit-Position: refs/heads/master@{#431591}

[Xianzhu, 2016-11-09 17:24:35]

Description was changed from

==========
[SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.
For paint invalidation this can replace the old workarounds.

BUG=660195
==========

to

==========
[SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.
For paint invalidation this can replace the old workarounds.

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

[Xianzhu, 2016-11-09 17:25:19]

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

[commit-bot: I haz the power, 2016-11-09 17:25:40]

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

[Xianzhu, 2016-11-09 17:46:56]

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

[Xianzhu, 2016-11-09 17:46:57]

Planned to also use this for SlimmingPaintInvalidation, but found that
it's hard to make paint offset right: we would have to keep two paint
offsets, one is relative to the containing transform node, the other
one is relative to the nearest one of paint invalidation container and
the containing transform node. The latter needs much more logic to make
paint offsets of positioned objects (especially under a non-stacking-
context paint invalidation container) fully correct. So I chose not to
track paint offset change for SlimmingPaintInvalidation, but still use
the workarounds. https://codereview.chromium.org/2487273002 is the
partial work.

We can remove paintOffset from ObjectPaintProperties and use
LayoutObject::previousPaintOffset instead. Will address this in
later CLs.

[Xianzhu, 2016-11-09 17:48:01]

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

[commit-bot: I haz the power, 2016-11-09 17:48:23]

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-09 18:49:59]

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

[commit-bot: I haz the power, 2016-11-09 18:50:00]

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

[Xianzhu, 2016-11-09 22:10:24]

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

[commit-bot: I haz the power, 2016-11-09 22:11: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-09 23:21:43]

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

[commit-bot: I haz the power, 2016-11-09 23:21:44]

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

[pdr., 2016-11-10 07:35:32]

Looks great, just a few minor questions/comments.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:702: if
(paintInfo.getGlobalPaintFlags() != GlobalPaintNormalPhase)
Is this just temporary because you're computing the offset in the paint
invalidation walk? For example, we should still compute the paint offset for
GlobalPaintPrinting, right?

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.h (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.h:63: void
checkPaintOffset(const PaintInfo& paintInfo,
Add a comment here:
// SPV2 computes paint offsets during the prepaint tree
// walk (PrePaintTreeWalk). This check verifies that the
// SPV1 paint offset computed during paint matches the
// new SPV2 paint offset.


WDYT about making it more clear at the callsites that this is spv2 debug code?
It's a little verbose but maybe something like:
if (RuntimeEnabledFeatures::slimmingPaintV2Enabled()) {
  DCHECK(ObjectPainter(m_whatever).paintOffsetPrecomputed(paintInfo,
paintOffset));
}

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/PaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidator.cpp:443: //
TODO(crbug.com/533277): This is a workaround for the bug. Remove when we
WDYT about adding a little more info to this comment to make the spv1 and spv2
differences easier to understand?
// This is a workaround for detecting paint offset changes in fixed position
// subtrees and isn't necessary with SPv2 paint offset tracking. See:
crbug.com/533277

[Xianzhu, 2016-11-10 17:41:02]

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

[Xianzhu, 2016-11-10 17:41:10]

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:702: if
(paintInfo.getGlobalPaintFlags() != GlobalPaintNormalPhase)
On 2016/11/10 07:35:32, pdr. wrote:
> Is this just temporary because you're computing the offset in the paint
> invalidation walk? For example, we should still compute the paint offset for
> GlobalPaintPrinting, right?

Added comments to explain this:

// If we are painting selection, drag-image or printing, we'll paint in ways
// different from the normal painting, which may use paint offsets different
// from those calculated during PrePaintTreeWalk.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.h (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.h:63: void
checkPaintOffset(const PaintInfo& paintInfo,
On 2016/11/10 07:35:32, pdr. wrote:
> Add a comment here:
> // SPV2 computes paint offsets during the prepaint tree
> // walk (PrePaintTreeWalk). This check verifies that the
> // SPV1 paint offset computed during paint matches the
> // new SPV2 paint offset.
> 

Done.

> 
> WDYT about making it more clear at the callsites that this is spv2 debug code?
> It's a little verbose but maybe something like:
> if (RuntimeEnabledFeatures::slimmingPaintV2Enabled()) {
>   DCHECK(ObjectPainter(m_whatever).paintOffsetPrecomputed(paintInfo,
> paintOffset));
> }

I like the clearness. How about the new patch that moved the checking in header
file?

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/PaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidator.cpp:443: //
TODO(crbug.com/533277): This is a workaround for the bug. Remove when we
On 2016/11/10 07:35:32, pdr. wrote:
> WDYT about adding a little more info to this comment to make the spv1 and spv2
> differences easier to understand?
> // This is a workaround for detecting paint offset changes in fixed position
> // subtrees and isn't necessary with SPv2 paint offset tracking. See:
> crbug.com/533277

Done.

[commit-bot: I haz the power, 2016-11-10 17:41:27]

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-10 18:41:55]

On 2016/11/09 at 17:46:57, wangxianzhu wrote:
> Planned to also use this for SlimmingPaintInvalidation, but found that
> it's hard to make paint offset right: we would have to keep two paint
> offsets, one is relative to the containing transform node, the other
> one is relative to the nearest one of paint invalidation container and
> the containing transform node. The latter needs much more logic to make
> paint offsets of positioned objects (especially under a non-stacking-
> context paint invalidation container) fully correct. So I chose not to
> track paint offset change for SlimmingPaintInvalidation, but still use
> the workarounds. https://codereview.chromium.org/2487273002 is the
> partial work.
> 
> We can remove paintOffset from ObjectPaintProperties and use
> LayoutObject::previousPaintOffset instead. Will address this in
> later CLs.

Isn't this work required to launch slimmingPaintInvalidation? Because launching
that requires partial property tree tree update.

[chrishtr, 2016-11-10 18:42:00]

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutObject.h (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutObject.h:1687:
m_layoutObject.m_previousPaintOffset = p;
DCHECK(slimmingPaintV2Enabled())

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp:545: // except
for non-root SVG whose paint offset is always zero.
SPv2 fixes the issue of paint offset always being 0?

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:707: // paint offset for
LayoutScrollbarPart.
Is there a bug filed for this?

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/PaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidator.cpp:445: if
(!RuntimeEnabledFeatures::slimmingPaintV2Enabled() &&
How was this fixed for SPv2?

[Xianzhu, 2016-11-10 18:49:48]

Description was changed from

==========
[SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.
For paint invalidation this can replace the old workarounds.

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

to

==========
[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

[Xianzhu, 2016-11-10 18:49:56]

On 2016/11/10 18:41:55, chrishtr wrote:
> On 2016/11/09 at 17:46:57, wangxianzhu wrote:
> > Planned to also use this for SlimmingPaintInvalidation, but found that
> > it's hard to make paint offset right: we would have to keep two paint
> > offsets, one is relative to the containing transform node, the other
> > one is relative to the nearest one of paint invalidation container and
> > the containing transform node. The latter needs much more logic to make
> > paint offsets of positioned objects (especially under a non-stacking-
> > context paint invalidation container) fully correct. So I chose not to
> > track paint offset change for SlimmingPaintInvalidation, but still use
> > the workarounds. https://codereview.chromium.org/2487273002 is the
> > partial work.
> > 
> > We can remove paintOffset from ObjectPaintProperties and use
> > LayoutObject::previousPaintOffset instead. Will address this in
> > later CLs.
> 
> Isn't this work required to launch slimmingPaintInvalidation? Because
launching
> that requires partial property tree tree update.

Actually paint offset tracking for partial property tree update still works for
slimmingPaintInvalidation, because PaintPropertyTreeBuilder is always
independent of SPv1/SPv2. It just doesn't work to track paint offset changes for
paint invalidation purpose. Updated description.

[pdr., 2016-11-10 18:54:11]

LGTM here, but please wait for chrishtr to be happy too

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:702: if
(paintInfo.getGlobalPaintFlags() != GlobalPaintNormalPhase)
On 2016/11/10 at 17:41:10, Xianzhu wrote:
> On 2016/11/10 07:35:32, pdr. wrote:
> > Is this just temporary because you're computing the offset in the paint
> > invalidation walk? For example, we should still compute the paint offset for
> > GlobalPaintPrinting, right?
> 
> Added comments to explain this:
> 
> // If we are painting selection, drag-image or printing, we'll paint in ways
> // different from the normal painting, which may use paint offsets different
> // from those calculated during PrePaintTreeWalk.

I don't think this is a blocking issue for this patch, but I am curious about
your thoughts. I thought we would be able to remove the paint offset argument
from the painter classes in spv2, but because of printing we will still need to
keep it? Are the paint offsets for divs/etc really different for painting?

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.h (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.h:63: void
checkPaintOffset(const PaintInfo& paintInfo,
On 2016/11/10 at 17:41:10, Xianzhu wrote:
> On 2016/11/10 07:35:32, pdr. wrote:
> > Add a comment here:
> > // SPV2 computes paint offsets during the prepaint tree
> > // walk (PrePaintTreeWalk). This check verifies that the
> > // SPV1 paint offset computed during paint matches the
> > // new SPV2 paint offset.
> > 
> 
> Done.
> 
> > 
> > WDYT about making it more clear at the callsites that this is spv2 debug
code?
> > It's a little verbose but maybe something like:
> > if (RuntimeEnabledFeatures::slimmingPaintV2Enabled()) {
> >   DCHECK(ObjectPainter(m_whatever).paintOffsetPrecomputed(paintInfo,
> > paintOffset));
> > }
> 
> I like the clearness. How about the new patch that moved the checking in
header file?

SGTM. Followups are always great.

[commit-bot: I haz the power, 2016-11-10 19:26:17]

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

[commit-bot: I haz the power, 2016-11-10 19:26:17]

Dry run: This issue passed the CQ dry run.

[Xianzhu, 2016-11-10 22:51:50]

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutObject.h (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutObject.h:1687:
m_layoutObject.m_previousPaintOffset = p;
On 2016/11/10 18:42:00, chrishtr wrote:
> DCHECK(slimmingPaintV2Enabled())

Added DCHECK(slimmingPaintInvalidationEnabled()). This is also used to track
paint offset change for partial paint property tree update on SPv1.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPaintInvalidator.cpp:545: // except
for non-root SVG whose paint offset is always zero.
On 2016/11/10 18:42:00, chrishtr wrote:
> SPv2 fixes the issue of paint offset always being 0?

The paint offsets are always 0 intentionally. For SPv2, they always don't change
because they are always zero. The condition is just to make SPv1 and SPv2
behaves in the same for SVG objects to reduce layout test result differences.
The condition was added before this CL.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/ObjectPainter.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:702: if
(paintInfo.getGlobalPaintFlags() != GlobalPaintNormalPhase)
On 2016/11/10 18:54:11, pdr. wrote:
> On 2016/11/10 at 17:41:10, Xianzhu wrote:
> > On 2016/11/10 07:35:32, pdr. wrote:
> > > Is this just temporary because you're computing the offset in the paint
> > > invalidation walk? For example, we should still compute the paint offset
for
> > > GlobalPaintPrinting, right?
> > 
> > Added comments to explain this:
> > 
> > // If we are painting selection, drag-image or printing, we'll paint in ways
> > // different from the normal painting, which may use paint offsets different
> > // from those calculated during PrePaintTreeWalk.
> 
> I don't think this is a blocking issue for this patch, but I am curious about
> your thoughts. I thought we would be able to remove the paint offset argument
> from the painter classes in spv2, but because of printing we will still need
to
> keep it? Are the paint offsets for divs/etc really different for painting?

Yes. For example, during printing/multicol painting, an object may be painted on
multiple fragments with different paint offsets. Perhaps we should always use
the same paint offset calculated in prepaint by using transforms in the case.

Actually these conditions were added we I was trying the patch on SPv1. The
tests failing on SPv1 may also fail on SPv2 with other reasons. I removed the
conditions. We can notice them when fixing SPv2 failures.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/ObjectPainter.cpp:707: // paint offset for
LayoutScrollbarPart.
On 2016/11/10 18:42:00, chrishtr wrote:
> Is there a bug filed for this?

pdr@ just filed crbug.com/664249. Added link here.

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/paint/PaintInvalidator.cpp (right):

https://codereview.chromium.org/2489893002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidator.cpp:445: if
(!RuntimeEnabledFeatures::slimmingPaintV2Enabled() &&
On 2016/11/10 18:42:00, chrishtr wrote:
> How was this fixed for SPv2?

Good question. To answer your question, at first I thought this were incorrect
because we do need to traverse the subtree to check for changed paint offsets.
Then I debugged with the test case
paint/invalidation/percentage-transform-paint-offset.html, and found that the
logic is actually redundant, even for SPv1. Created
https://codereview.chromium.org/2493673005/ to remove the logic. Waiting for try
results. Rebased this CL onto it.

[chrishtr, 2016-11-10 23:03:45]

LGTM modulo https://codereview.chromium.org/2493673005/

[Xianzhu, 2016-11-11 05:40:17]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2016-11-11 05:40:18]

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

[commit-bot: I haz the power, 2016-11-11 05:40:31]

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-11 07:10:50]

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

[commit-bot: I haz the power, 2016-11-11 07:10:52]

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_...)

[pdr., 2016-11-11 07:11:35]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2016-11-11 07:11:48]

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-11 09:08:01]

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

[commit-bot: I haz the power, 2016-11-11 09:08:03]

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

[Xianzhu, 2016-11-11 16:41:42]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2016-11-11 16:41:58]

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-11 17:57:08]

Description was changed from

==========
[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

to

==========
[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

[commit-bot: I haz the power, 2016-11-11 17:57:09]

Committed patchset #5 (id:80001)

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

Description was changed from

==========
[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

to

==========
[SPInvalidation/SPv2] Track paint offset change

This is for paint invalidation and partial paint property tree update.

For SPv2 paint invalidation this can replace the old workarounds. It
doesn't work for SPv1 paint invalidation (even slimmingPaintInvalidation)
because PaintPropertyTreeBuilder disregards paint invalidation
containers when calculating paint offsets.

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

Committed: https://crrev.com/4a4980562262f80dfb66739d84c49251164ac373
Cr-Commit-Position: refs/heads/master@{#431591}
==========

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

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