Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upRefactor the cascade #9929
Refactor the cascade #9929
Conversation
highfive
commented
Mar 8, 2016
|
Heads up! This PR modifies the following files:
|
|
@bors-servo try |
Try I’ll edit this PR with more stuff later, but for now I want some try results.
|
|
|
@bholley Alright, the last commit has the refactoring discussed today or IRC, but I’m really not confident that it’s correct or that our current test suite covers edge cases where is might not be correct. Still, let’s see what happens with: @bors-servo try |
Try I’ll edit this PR with more stuff later, but for now I want some try results. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9929) <!-- Reviewable:end -->
|
|
| // Like calling to_computed_value, which wouldn't type check. | ||
| if style.border.border_${side}_style.none_or_hidden() && | ||
| style.border.border_${side}_width != Au(0) { | ||
| Arc::make_mut(&mut style.border).border_${side}_width = Au(0); |
This comment has been minimized.
This comment has been minimized.
pcwalton
Mar 10, 2016
Contributor
Pushing the Arc::make_mut() into the if condition like you did here may improve cascading performance significantly, FWIW. Thanks!
This comment has been minimized.
This comment has been minimized.
|
r? @pcwalton There’s at least one bug causing these two failures, but I don’t understand why these tests produce the results they do with this PR :(
|
|
@bors-servo: r+ Nice idea and any simplification here is helpful, since this is performance-critical code and the i-cache burden is significant. |
|
|
|
@bors-servo: r- Tests are failing. But r=me when they're fixed. |
|
|
|
@SimonSapin: #9012 - nothing new about it. |
|
Ok, I’ll remember to try more variations of github search. @pcwalton try passed, please r? the bug fixes, I’m not super confident in them. |
|
Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions. components/style/properties.mako.rs, line 6681 [r5] (raw file): Comments from the review on Reviewable.io |
|
Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions. components/style/properties.mako.rs, line 6681 [r5] (raw file): Comments from the review on Reviewable.io |
|
Looks good, r=me. |
|
@bors-servo r=pcwalton |
|
|
Refactor the cascade Converting the specified value of some properties into a computed value depends on the value of other properties. For example, the `em` unit of any length depends on the `font-size` property. Previously, we would do a first pass over applicable declarations to build up a `values::computed::Context` struct with a number of fields for each such piece of data from other properties. This simplies the struct by instead having it contain the set of computed values (for a given element) that is being populated and classify properties into "early" and "other", such that the only dependencies can be from "other" to "early". We iterate applicable_declarations twice, first cascading "early" properties then "other". Unfortunately, it’s not easy to check that this classification is correct. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9929) <!-- Reviewable:end -->
|
|
|
@bors-servo retry |
|
The failed test was #9724. |
|
|
|
|
|
@bors-servo retry |
Refactor the cascade Converting the specified value of some properties into a computed value depends on the value of other properties. For example, the `em` unit of any length depends on the `font-size` property. Previously, we would do a first pass over applicable declarations to build up a `values::computed::Context` struct with a number of fields for each such piece of data from other properties. This simplies the struct by instead having it contain the set of computed values (for a given element) that is being populated and classify properties into "early" and "other", such that the only dependencies can be from "other" to "early". We iterate applicable_declarations twice, first cascading "early" properties then "other". Unfortunately, it’s not easy to check that this classification is correct. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9929) <!-- Reviewable:end -->
|
|
| .${property.ident} = computed_value; | ||
| % endif | ||
|
|
||
| % if property.name in DERIVED_LONGHANDS: | ||
| % if not style_struct.inherited: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
SimonSapin
Mar 22, 2016
Author
Member
It’s not needed since derive_from_* functions don’t take a computed_value parameter anymore. Computed values (as known "so far") are already available through e.g. context.style.box_.display, whereas context.display was previously the specified value, so when the computed value was needed it had to be passed separately.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
SimonSapin
Mar 23, 2016
Author
Member
Yes. In this function non-inherited styles are cached so we don’t need to run the cascade for them again. let computed_value = …; is in a larger block above is in % if style_struct.inherited: (without not).
Before this PR, computed_value was needed unconditionally, so this % if not style_struct.inherited: block (with not) defined it for the rest of the cases. Now that computed_value is not used in the derive_from_* call anymore, this second let computed_value = …; statement would be dead code.
SimonSapin commentedMar 8, 2016
Converting the specified value of some properties into a computed value depends on the value of other properties. For example, the
emunit of any length depends on thefont-sizeproperty.Previously, we would do a first pass over applicable declarations to build up a
values::computed::Contextstruct with a number of fields for each such piece of data from other properties.This simplies the struct by instead having it contain the set of computed values (for a given element) that is being populated and classify properties into "early" and "other", such that the only dependencies can be from "other" to "early". We iterate applicable_declarations twice, first cascading "early" properties then "other". Unfortunately, it’s not easy to check that this classification is correct.