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 upstylo: Bug 1374233 - Clamp interpolated values for properties which need to be restricted #17783
Conversation
highfive
commented
Jul 19, 2017
|
Heads up! This PR modifies the following files:
|
highfive
commented
Jul 19, 2017
|
r? @nox |
|
So my first issue with this is: even if we clamp at conversion-time, what about the result of interpolation? When does that get clamped? |
|
cc @hiikezoe |
|
We don't change the result of interpolation. All we need to do is make sure we put the correct non-negative result into ServoComputedValues (by uncompute() and then cascade it to ServoComputedValues), with Animation/Transition cascade level, so we can see the correct animation on the screen. The out of range interpolated values are still needed to be preserved during calculating AnimationValue in the case for additive or accumulative animations. |
|
|
||
| impl AnimatedValueAsComputed for T { | ||
| #[inline] | ||
| fn restrict_value(self, restriction_type: Restriction) -> Self { |
This comment has been minimized.
This comment has been minimized.
nox
Jul 19, 2017
Member
AFAIK there is never a need for such a method given Animatable methods can clamp directly.
| /// Restriction types. | ||
| #[derive(Copy, Clone, Debug, PartialEq)] | ||
| #[cfg_attr(feature = "servo", derive(HeapSizeOf))] | ||
| pub enum Restriction { |
This comment has been minimized.
This comment has been minimized.
| }} | ||
| } | ||
|
|
||
| impl<Angle, Factor, Length, DropShadow> ToAnimatedValue for Filter<Angle, Factor, Length, DropShadow> |
This comment has been minimized.
This comment has been minimized.
| color: ToAnimatedValue::from_animated_value(animated.color), | ||
| horizontal: ToAnimatedValue::from_animated_value(animated.horizontal), | ||
| vertical: ToAnimatedValue::from_animated_value(animated.vertical), | ||
| blur: convert_and_clamp_nonnegative_animated_value!(animated.blur) |
This comment has been minimized.
This comment has been minimized.
| @@ -61,3 +62,18 @@ impl Animatable for LineHeight { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| impl AnimatedValueAsComputed for LineHeight { | |||
This comment has been minimized.
This comment has been minimized.
| @@ -50,3 +51,16 @@ impl Animatable for BackgroundSize { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| impl AnimatedValueAsComputed for BackgroundSize { | |||
This comment has been minimized.
This comment has been minimized.
| use values::computed::Angle as ComputedAngle; | ||
| use values::computed::BorderCornerRadius as ComputedBorderCornerRadius; |
This comment has been minimized.
This comment has been minimized.
nox
Jul 19, 2017
Member
Please no, make a submodule border just like there is one in computed and specified.
This comment has been minimized.
This comment has been minimized.
Why wasn't the computed value clamped itself, then? |
|
Per our talk on irc, I will try to add new types for those non-negative or greater-than-or-equal-to-one, to avoid additional conditional clamping. |
|
|
|
I've finished re-writing my patches locally (by introducing some non-negative types and greater-than-or-equal-to-one types, and updating some existing types, e.g. LineHeight), so will update this PR soon. |
4f0f67d
to
e066336
|
r? @nox again. Thanks. |
|
@bors-servo try |
stylo: Bug 1374233 - Clamp interpolated values for properties which need to be restricted Some properties only accept non-negative values, or values greater than or equal to one. It is possible to produce an negative interpolated values while using negative timing functions, so we have to apply a restriction to these values to avoid getting invalid values. For example, line-height must be non-negative, but the output progress of some timing functions (e,g. cubic-bezier(0.25, -2, 0.75, 1)) may be a negative value, so the interpolated result of line-height is also negative. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix Bug 1374233. - [X] These changes do not require tests because we have tests in Gecko side already. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17783) <!-- Reviewable:end -->
|
|
|
There are some conflicts now, but I'd like to rebase my patches after making sure the design is accepted or knowing what should I fix. |
|
@emilio, nox is still on PTO, so do you feel comfortable with reviewing these patches? |
|
Looks fine over all. There's a fair amount of boilerplate (disclaimer: I don't know how previous versions of the patch were). Most of it could go away with I wonder if some kind of This also needs a rebase. @nox does this patch address your comments properly? I'm not aware of the full discussion. I know you're on PTO, but it'd be nice if you could take a quick look. Thanks! |
| <%def name="impl_simple_wrapper_setter(ident, gecko_ffi_name)"> | ||
| #[allow(non_snake_case)] | ||
| pub fn set_${ident}(&mut self, v: longhands::${ident}::computed_value::T) { | ||
| ${set_gecko_property(gecko_ffi_name, "v.0")} |
This comment has been minimized.
This comment has been minimized.
emilio
Aug 2, 2017
Member
We have something to implement stuff with conversions. Perhaps we should implement From and remove this mako code instead, wdyt?
This comment has been minimized.
This comment has been minimized.
|
|
||
| #[inline] | ||
| fn from_computed_value(computed: &Self::ComputedValue) -> Self { | ||
| GreaterThanOrEqualToOneNumber(Number::from_computed_value(&computed.0)) |
This comment has been minimized.
This comment has been minimized.
| impl Animatable for NonNegativeNumber { | ||
| #[inline] | ||
| fn add_weighted(&self, other: &Self, self_portion: f64, other_portion: f64) -> Result<Self, ()> { | ||
| self.0.add_weighted(&other.0, self_portion, other_portion).map(NonNegativeNumber) |
This comment has been minimized.
This comment has been minimized.
emilio
Aug 2, 2017
Member
So, we're not clamping here, and I think that's the intention, right? If so, some comments about it would be nice.
| no_viewport_percentage!(GreaterThanOrEqualToOneNumber); | ||
|
|
||
| impl Parse for GreaterThanOrEqualToOneNumber { | ||
| fn parse<'i, 't>(context: &ParserContext, input: &mut Parser<'i, 't>) -> Result<Self, ParseError<'i>> { |
This comment has been minimized.
This comment has been minimized.
emilio
Aug 2, 2017
Member
Can we remove Number::parse_at_least_one and Number::parse_non_negative now?
This comment has been minimized.
This comment has been minimized.
BorisChiou
Aug 2, 2017
Author
Contributor
Not all non-negative properties are animated, so I didn't replace the type of all non-negative properties with NonNegativeNumber. I will try to check it.
This comment has been minimized.
This comment has been minimized.
BorisChiou
Aug 2, 2017
•
Author
Contributor
OK. I can do it, but if you don't mind, I'd like to remove Number::parse_at_least_one() and Number::parse_non_negative() in a follow-up PR to keep this not too complicated because it seems I have to update more types from Number to NonNegativeNumber.
|
|
||
| #[inline] | ||
| fn from_animated_value(animated: Self::AnimatedValue) -> Self { | ||
| T { horizontal: NonNegativeAu::from_animated_value(animated.horizontal), |
This comment has been minimized.
This comment has been minimized.
| use values::computed::Angle as ComputedAngle; | ||
| use values::computed::BorderCornerRadius as ComputedBorderCornerRadius; |
This comment has been minimized.
This comment has been minimized.
|
|
|
I just tried to use |
…neNumber. NonNegativeNumber: for -moz-box-flex, flex-grow, and flex-shrink. GreaterThanOrEqualToOneNumber: for stroke-miterlimit. MozReview-Commit-ID: Kgbt99BPdVA
e066336
to
8651acd
|
gecko try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2db4c2a8d83bd0d837350505cb5046edb029f0c The test failures on the try is not related to these patches, so the overall status looks good now. |
|
@bors-servo try |
stylo: Bug 1374233 - Clamp interpolated values for properties which need to be restricted Some properties only accept non-negative values, or values greater than or equal to one. It is possible to produce an negative interpolated values while using negative timing functions, so we have to apply a restriction to these values to avoid getting invalid values. For example, line-height must be non-negative, but the output progress of some timing functions (e,g. cubic-bezier(0.25, -2, 0.75, 1)) may be a negative value, so the interpolated result of line-height is also negative. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix Bug 1374233. - [X] These changes do not require tests because we have tests in Gecko side already. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17783) <!-- Reviewable:end -->
|
I rebased the patches and use |
|
|
|
r=me if geckotry is green. |
|
Thanks for the review. I just push these commits to gecko try again. (Gecko try tree is closed now, so I will put the try link later.) |
|
@bors-servo r=nox |
|
|
|
@bors-servo p=1 |
stylo: Bug 1374233 - Clamp interpolated values for properties which need to be restricted Some properties only accept non-negative values, or values greater than or equal to one. It is possible to produce an negative interpolated values while using negative timing functions, so we have to apply a restriction to these values to avoid getting invalid values. For example, line-height must be non-negative, but the output progress of some timing functions (e,g. cubic-bezier(0.25, -2, 0.75, 1)) may be a negative value, so the interpolated result of line-height is also negative. --- - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix Bug 1374233. - [X] These changes do not require tests because we have tests in Gecko side already. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17783) <!-- Reviewable:end -->
|
|
|
That's #17168; you can retry. |
|
@bors-servo retry |
|
|
|
|
BorisChiou commentedJul 19, 2017
•
edited by larsbergstrom
Some properties only accept non-negative values, or values greater than or equal to one. It is possible to produce an negative interpolated values while using negative timing functions, so we have to apply a restriction to these values to avoid getting invalid values.
For example, line-height must be non-negative, but the output progress of some timing functions (e,g. cubic-bezier(0.25, -2, 0.75, 1)) may be a negative value, so the interpolated result of line-height is also negative.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errorsThis change is