Cut property cascading if display:none is found

[upsuper]

The display: none optimization mentioned in bug 1422615.

---

This change is 

[highfive]

Heads up! This PR modifies the following files:

• @bholley: ports/geckolib/glue.rs, components/style/values/specified/mod.rs, components/style/style_resolver.rs, components/style/properties/properties.mako.rs, components/style/traversal.rs and 2 more
• @canaltinova: components/style/values/specified/mod.rs, components/style/style_resolver.rs, components/style/properties/properties.mako.rs, components/style/traversal.rs, components/style/properties/computed_value_flags.rs and 1 more
• @emilio: ports/geckolib/glue.rs, components/style/values/specified/mod.rs, components/style/style_resolver.rs, components/style/properties/properties.mako.rs, components/style/traversal.rs and 2 more

[highfive]

Warning

• These commits modify style code, but no tests are modified. Please consider adding a test!

[upsuper]

r? @emilio

[upsuper]

try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fd097f526d918b4274bfd287f4442d4db9822e0

talos comparison:
without this patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=e58f647dd77c&newProject=try&newRevision=cb3e916eed78&framework=1
with this patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=e58f647dd77c&newProject=try&newRevision=0afe6071baa4&framework=1

The largest regression tpaint win32 pgo is down from 28% to 24%.

comparison between w/o patch and w/ patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=cb3e916eed78&newProject=try&newRevision=0afe6071baa4&framework=1

There aren't many "certain" result in this comparison, but as can be seen, it takes less time on most of the tests after this patch.

[upsuper]

@emilio If you still think we probably shouldn't take this... As far as we can find better places to optimize it, I guess I'm fine. Maybe a several percent optimization isn't really worth this relatively complicated change.

[emilio]

Yeah, I'd prefer to hold this off for a bit until there's no better optimization possible I think... Not sure what @heycam or @SimonSapin think.

[bors-servo]

☔ The latest upstream changes (presumably #19662) made this pull request unmergeable. Please resolve the merge conflicts.

[upsuper]

I'd actually like to revive this PR. I think the idea here is straightforward, the mechanism isn't really that complicated, and it does lead to decent performance improvement based on previous measurement.

[bors-servo]

☔ The latest upstream changes (presumably #19696) made this pull request unmergeable. Please resolve the merge conflicts.

[upsuper]

So here is a set of new try pushes for this optimization:

• base: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b74386f34322f5c4bc8e2e4abee25a66bdf981ed
• stylo-chrome w/o patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0b8e59e7a388ed4de3e4e296b645d639df3a4aef
• stylo-chrome w/ patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc05b084ee46cd2c385938582550b06a7b30366f

Comparisons:

• base vs. stylo-chrome w/o patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b74386f34322&newProject=try&newRevision=0b8e59e7a388&framework=1
• base vs. stylo-chrome w/ patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b74386f34322&newProject=try&newRevision=dc05b084ee46&framework=1
• stylo-chrome w/o patch vs. stylo-chrome w/ patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=0b8e59e7a388&newProject=try&newRevision=dc05b084ee46&framework=1

As can be seen from the last comparison, there is a high confidence ~4% improvement on tpaint win64 (as well as several low confidence improvement among the board including ~4% improvement on tpaint win32). And comparing the first and the second comparison, it can be seen that the regression on tpaint win64 is down from ~25% to ~20%, and tpaint win32 from ~28% to ~23%.

I think this is something significant that we should seriously consider taking.

[emilio]

Another thing I don't love about this patch is that it relies on the optimization to avoid keeping around display: none pseudo styles to be correct, otherwise there are missing checks...

[emilio]

I still think this is too error-prone and too complex, even if it happens to be correct in its current form.

[bholley]

It seems like xidorn has shown pretty conclusively that this issue is responsible for a sizeable part of our stylo-chrome regression (this is work that gecko doesn't do but stylo does, and eliminating the work fixes about a fifth of the regression). Can you help propose another way to address this issue?

[upsuper]

We have identified a bigger problem that is bug 1409672. I expect fix to that bug would reduce the improvement we see here since we may not be restyling display:none elements this often after that. We can measure again when that's done.

[upsuper]

This patch doesn't apply cleanly anymore, and fixing that seems to be non-trivial, so I'm closing this. If we still want to take it, we can do this in a new pr I guess.