Skip scheduling sibling invalidation based on direct adjacent count.

Skip scheduling sibling invalidation based on direct adjacent count.

When scheduling sibling invalidation sets for sibling insertion/removal
we schedule sets for N preceding siblings where N is the maximum number
of consecutive direct adjacent combinators, or infinite for indirect
adjacent combinators.

However, the further left of the mutation we schedule, the more direct
adjacent combinators are required to affect siblings following the
mutation. The maximum adjacent number is stored for every sibling
invalidation set, which means we can drop scheduling the set if that
count is too low.

Example:

Selectors:

  .a + div + div + span {}
  .b + span {}
  .c + span {}

Siblings:

  div.x div.a div.b div.c div#remove span

When removing #remove we start scheduling sibling invalidations for
div.c which needs at least one adjacent combinator to reach the span or
any subsequent elements. div.b needs at least two, and so on. For the
case above, we schedule the set for .c, but not for .b since the max
adjacent combinator count for .b is 1 and it needs to be at least 2.
.a needs to have at least 3, which is the case, so we schedule the set
for .a. We never consider the div.x element because the max adjacent
combinator count for the document is 3.

R=esprehn@chromium.org
BUG=624782
Committed: https://crrev.com/6fd5c3b21a538a976c97c92a97645aafec77c572
Cr-Commit-Position: refs/heads/master@{#403530}

[rune, 2016-06-30 13:59:39]

The CQ bit was checked by rune@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-06-30 13:59:49]

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

[rune, 2016-06-30 14:00:07]

ptal

[commit-bot: I haz the power, 2016-06-30 15:12:59]

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

[commit-bot: I haz the power, 2016-06-30 15:13:00]

Dry run: This issue passed the CQ dry run.

[esprehn, 2016-06-30 23:22:01]

esprehn@chromium.org changed reviewers:
+ meade@chromium.org

[esprehn, 2016-06-30 23:22:01]

meade@ Want to review this? :)

[meade_UTC10, 2016-07-01 16:44:06]

On 2016/06/30 23:22:01, esprehn wrote:
> meade@ Want to review this? :)

sure! This all makes sense to me, so lgtm!

[rune, 2016-07-01 17:40:30]

The CQ bit was checked by rune@opera.com

[commit-bot: I haz the power, 2016-07-01 17:40:51]

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-07-01 19:27:22]

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

[commit-bot: I haz the power, 2016-07-01 19:27:23]

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

[rune, 2016-07-01 19:45:59]

The CQ bit was checked by rune@opera.com

[commit-bot: I haz the power, 2016-07-01 19:46:14]

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-07-01 21:06:59]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-01 21:09:26]

Description was changed from

==========
Skip scheduling sibling invalidation based on direct adjacent count.

When scheduling sibling invalidation sets for sibling insertion/removal
we schedule sets for N preceding siblings where N is the maximum number
of consecutive direct adjacent combinators, or infinite for indirect
adjacent combinators.

However, the further left of the mutation we schedule, the more direct
adjacent combinators are required to affect siblings following the
mutation. The maximum adjacent number is stored for every sibling
invalidation set, which means we can drop scheduling the set if that
count is too low.

Example:

Selectors:

  .a + div + div + span {}
  .b + span {}
  .c + span {}

Siblings:

  div.x div.a div.b div.c div#remove span

When removing #remove we start scheduling sibling invalidations for
div.c which needs at least one adjacent combinator to reach the span or
any subsequent elements. div.b needs at least two, and so on. For the
case above, we schedule the set for .c, but not for .b since the max
adjacent combinator count for .b is 1 and it needs to be at least 2.
.a needs to have at least 3, which is the case, so we schedule the set
for .a. We never consider the div.x element because the max adjacent
combinator count for the document is 3.

R=esprehn@chromium.org
BUG=624782
==========

to

==========
Skip scheduling sibling invalidation based on direct adjacent count.

When scheduling sibling invalidation sets for sibling insertion/removal
we schedule sets for N preceding siblings where N is the maximum number
of consecutive direct adjacent combinators, or infinite for indirect
adjacent combinators.

However, the further left of the mutation we schedule, the more direct
adjacent combinators are required to affect siblings following the
mutation. The maximum adjacent number is stored for every sibling
invalidation set, which means we can drop scheduling the set if that
count is too low.

Example:

Selectors:

  .a + div + div + span {}
  .b + span {}
  .c + span {}

Siblings:

  div.x div.a div.b div.c div#remove span

When removing #remove we start scheduling sibling invalidations for
div.c which needs at least one adjacent combinator to reach the span or
any subsequent elements. div.b needs at least two, and so on. For the
case above, we schedule the set for .c, but not for .b since the max
adjacent combinator count for .b is 1 and it needs to be at least 2.
.a needs to have at least 3, which is the case, so we schedule the set
for .a. We never consider the div.x element because the max adjacent
combinator count for the document is 3.

R=esprehn@chromium.org
BUG=624782

Committed: https://crrev.com/6fd5c3b21a538a976c97c92a97645aafec77c572
Cr-Commit-Position: refs/heads/master@{#403530}
==========

[commit-bot: I haz the power, 2016-07-01 21:09:27]

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