Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState, newPaintInvalidationContainer);
    PaintInvalidationState childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
Committed: https://crrev.com/468ca56ab508342df50c7ee16ac4f4e767a1614b
Cr-Commit-Position: refs/heads/master@{#381875}

[Xianzhu, 2016-03-16 23:42:21]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(childPaintInvalidationState);
  }

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
ForcedHorriblySlowRectMappings because we need to track correct
paintInvalidationContainer (for normal objects and stacked objects) in
PaintInvalidationState, instead of being passed in from
LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
ForcedHorriblySlowRectMappings because we need to track correct
paintInvalidationContainer (for normal objects and stacked objects) in
PaintInvalidationState, instead of being passed in from
LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[Xianzhu, 2016-03-17 01:15:21]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
ForcedHorriblySlowRectMappings because we need to track correct
paintInvalidationContainer (for normal objects and stacked objects) in
PaintInvalidationState, instead of being passed in from
LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
ForcedHorriblySlowRectMappings because we need to track correct
paintInvalidationContainer (for normal objects and stacked objects) in
PaintInvalidationState, instead of being passed in from
LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[Xianzhu, 2016-03-17 01:16:04]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
ForcedHorriblySlowRectMappings because we need to track correct
paintInvalidationContainer (for normal objects and stacked objects) in
PaintInvalidationState, instead of being passed in from
LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
  contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[Xianzhu, 2016-03-17 16:49:16]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
  contains the correct paintInvalidationContainer);
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
  contains the correct paintInvalidationContainer);
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[Xianzhu, 2016-03-17 16:49:40]

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

[Xianzhu, 2016-03-17 16:51:41]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded();
- Let the paintInvalidationState parameter is for the current object (which
  contains the correct paintInvalidationContainer);
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[chrishtr, 2016-03-17 20:44:54]

lgtm

https://codereview.chromium.org/1804963005/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/PaintInvalidationState.h (right):

https://codereview.chromium.org/1804963005/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/PaintInvalidationState.h:96: const
LayoutObject& m_layoutObject;
This name is not so clear. Add a comment or consider a better name.

[Xianzhu, 2016-03-17 21:11:43]

https://codereview.chromium.org/1804963005/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/PaintInvalidationState.h (right):

https://codereview.chromium.org/1804963005/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/PaintInvalidationState.h:96: const
LayoutObject& m_layoutObject;
On 2016/03/17 20:44:54, chrishtr wrote:
> This name is not so clear. Add a comment or consider a better name.

Renamed to m_currentObject.

I'm working on another patch to move all fast-path paint invalidation geometry
mapping code into PaintInvalidationState, and cleanup LayoutObject's geometry
mapping methods with optional PaintInvalidationState parameters. With the patch,
the meaning of m_currentObject will be clearer.

[Xianzhu, 2016-03-17 21:12:37]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2016-03-17 21:12:37]

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/1804963005/#ps80001
(title: " ")

[commit-bot: I haz the power, 2016-03-17 21:13:09]

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

[commit-bot: I haz the power, 2016-03-17 22:28:26]

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

[commit-bot: I haz the power, 2016-03-17 22:28:28]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...)

[Xianzhu, 2016-03-17 22:59:23]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2016-03-17 22:59:23]

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/1804963005/#ps100001
(title: " ")

[commit-bot: I haz the power, 2016-03-17 22:59:50]

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

[commit-bot: I haz the power, 2016-03-18 00:56:25]

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

[commit-bot: I haz the power, 2016-03-18 00:56:26]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Xianzhu, 2016-03-18 01:35:40]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2016-03-18 01:36:01]

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

[commit-bot: I haz the power, 2016-03-18 02:37:44]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

[commit-bot: I haz the power, 2016-03-18 02:37:46]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-03-18 02:38:59]

Description was changed from

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199
==========

to

==========
Avoid paintInvalidationContainer parameter of invalidatePaintIfNeeded()

Change the original flow:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationContainer = ...;
    invalidatePaintIfNeeded(parentPaintInvalidationState,
newPaintInvalidationContainer);
    PaintInvalidationState
childPaintInvalidationState(parentPaintInvalidationState);
    invalidatePaintOfSubtreesIfNeeded(childPaintinvalidationState);
  }

to:
  invalidateTreeIfNeeded(parentPaintInvalidationState)
  {
    newPaintInvalidationState(parentPaintInvalidationState); // Which updates
paintInvalidationContainer, but not geometry info for children.
    invalidatePaintIfNeeded(newPaintInvalidationState);
    newPaintInvalidationState.updatePaintOffsetAndClipForChildren();
    invalidatePaintOfSubtreesIfNeeded(newPaintInvalidationState);
  }

This is like how PaintPropertyTreeBuilderContexts are inherited and updated:
copy from parent first, then update in multiple steps. We may use the state
for different purposes after different steps.

The benefits are:
- Avoid additional paintInvalidationContainer in invalidatePaintIfNeeded()
  by letting paintInvalidationState parameter contain the correct
  paintInvalidationContainer for the current object;
- We move the logic to find the paintInvalidationContainer from LayoutObjects
  into PaintInvalidationState which knows more information;
- This is a preparation for the next step works to avoid some
  ForcedHorriblySlowRectMappings because we need to track correct
  paintInvalidationContainer (for normal objects and stacked objects) in
  PaintInvalidationState, instead of being passed in from
  LayoutBoxModelObject::invalidateTreeIfNeeded();

BUG=591199

Committed: https://crrev.com/468ca56ab508342df50c7ee16ac4f4e767a1614b
Cr-Commit-Position: refs/heads/master@{#381875}
==========

[commit-bot: I haz the power, 2016-03-18 02:39:00]

Patchset 6 (id:??) landed as
https://crrev.com/468ca56ab508342df50c7ee16ac4f4e767a1614b
Cr-Commit-Position: refs/heads/master@{#381875}