Bug 1332969: stylo: Synchronously do a style update when the device changes

[emilio]

Ideally this would be lazy, but eventually we're going to need to restyle in
RebuildAllStyleData anyway, which would require us to have the style up to date,
so no need to complicate our lives.

r? @heycam or @upsuper or @bholley

---

This change is 

[highfive]

Heads up! This PR modifies the following files:

• @bholley: components/style/gecko/data.rs

[highfive]

Warning

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

[bholley]

Why do we need to mark the stylesheets as having changed if the device changes? It seems like we need to recascade the DOM and reevaluate media queries, but stylesheets_changed does more work, no?

[emilio]

We need to reconstruct the style data because different rules may match.

We can definitely be more granular in the future, but that mechanism isn't there right now.

[emilio]

s/may match/may apply/

[bholley]

We need to reconstruct the style data because different rules may match.

Oh ok. So We should put a RESTYLE_SELF | RESTYLE_DESCENDANTS hint on the root then.

We can definitely be more granular in the future, but that mechanism isn't there right now.

My understanding is that the servo architecture already differentiates between "stylesheets changed" and "device changed". What machinery is missing?

[emilio]

I didn't want to do the restyle stuff after I've finished all the medialist work, because gecko has its own control about which media queries have matched and not, and can provide us with an adequate restyle hint if we do the right thing.

Servo does indeed have the concept of "setting a new device", but there are fundamental differences between a servo device and a Gecko device that don't allow us to do that for gecko.

Concretely, in gecko right now the device is represented by the pres context and effectively unique. There's no easy way to compare against a previous state of the pres context (and I think its not bad, but we can't just reuse that piece of code so easily)

[bholley]

Ok - Just add a comment indicating that Gecko doesn't use that machinery?

[bholley]

Oh, and just so that I understand - if Gecko does provide us with such a restyle hint, will it avoid invoke RebuildAllStyleData? Because otherwise we're still going to dirty everything.

I guess I'm probably enough context here that it makes sense for heycam to review it, since he reviewed the media query stuff.

[emilio]

Nope, RebuildAllStyleData receives a hint and a change hint.

[heycam]

Here is how it works in Gecko.

To respond to window resizes, we call nsPresContext::MediaFeatureValuesChanged(nsRestyleHint(0), nsChangeHint(0)). For certain other changes, like dppx changes (via the pref, or dragging the window to another screen) and theme changes, we pass in some non-zero hints.

In nsPresContext::MediaFeatureValuesChanged, we call nsStyleSet::MediumFeaturesChanged which returns true if the set of matching @media rules has changed. It does that by calling MediumFeaturesChanged on each nsCSSRuleProcessor (the object that represents the result of cascading all the sheets at a given cascade level). We can do this "has the set of rules changed" check quickly, because we cache the result of @media rule matching in an nsMediaQueryResultCacheKey object on each nsCSSRuleProcessor, and can just re-evaluate each of the features stored on that cache key. If we return false from nsStyleSet::MediumFeaturesChanged, and we didn't have any non-zero hints passed in, and it's not the case that { we ever used vw/vh/etc. units in the document, and the window was resized }, then we don't do any work. If any of the nsCSSRuleProcessor::MediumFeaturesChanged methods is about to return true, it also re-builds its cascade data (i.e., equivalent to the work done when stylesheets_changed = true).

It's quite important for performance that we can quickly evaluate whether the current set of matched @media rules has changed, and to avoid doing any restyling in those cases.

[heycam]

Oh, and when nsStyleSet::MediumFeaturesChanged does return true, we add eRestyle_Subtree to the restyle hint we pass to RebuildAllStyleData.

[emilio]

@heycam asked me to comment on this PR.

So the thing is that right now we try to reconstruct the style and device data lazily. This changes that so it's sychronous.

The background of this is that right now we might fail to flush the device on time. There are two ways to solve it.

1. Flush the device and stylesheets before processing restyles. That works, but below is why I think it's not worth it.
2. Do this sync flush when the device changes.

The reason why I want to go with (2), is because the RebuildAllStyleData call may/uses to require a restyle, so we need to have the style up-to-date anyway.

[emilio]

@bholley: I think we should still land this, I think @heycam is on PTO, so feel free to take the review.

[bholley]

I think we should redo this infrastructure per [1]. However, if you think this PR makes things more correct in the interim, I'm ok with landing it.

@bors-servo delegate+

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1334732

[bors-servo]

✌️ @emilio can now approve this pull request

[emilio]

Yes, I believe this is the right thing to do in the meantime.

@bors-servo r=bholley

[bors-servo]

📌 Commit d29fade has been approved by bholley

[bors-servo]

⌛ Testing commit d29fade with merge 227c576...

[bors-servo]

💔 Test failed - windows-gnu-dev

[emilio]

@bors-servo retry

[bors-servo]

⌛ Testing commit d29fade with merge 73bb759...

[bors-servo]

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css, mac-rel-wpt1, mac-rel-wpt2, windows-gnu-dev, windows-msvc-dev