Speed up the visited cascade by only running it for the properties that are
actually visited dependent. (These are only the properties where the separate
set of visited styles is even read at all, so running the rest is wasted work.)
MozReview-Commit-ID: 5B7wYtuH974
To support visited styles, we match and cascade a separate set of styles any
time we notice that an element has a relevant link.
The visited rules and values are held in `ComputedStyle` alongside the
regular rules and values, which simplifies supporting various APIs like
`cascade_primary_and_pseudos` which expect easy access to previously matched
rules.
To simplify passing the additional values around, an additional reference to the
visited `ComputedValues` is placed inside the regular `ComputedValues`.
MozReview-Commit-ID: 2ebbjcfkfWf
If we add/remove important rules, we may need to update a list of all important
rules (in Gecko) which overrides animation properties. Therefore, we need to
set a flag if we update the primary rules which includes important ones.
If we have animations on this element, we update its effect properties, and
also send a task to update cascade results.
Calling get_properties_overriding_animations() might cases some impact
on performance because we need to walk the rule tree, so if possible, we could
just store this set into TNode to avoid finding the properties for both old
and new rules each time. This could be a future work if necessary.
We add one FFI, Servo_GetProperties_Overriding_Animation, which calls
StrongRuleNode::get_properties_overriding_animations() to get a LonghandIdSet,
which may override animation properties running on compositor.
This enum type used to contain the result of parsing
one CSS source declaration (`name: value;`) and expanding shorthands.
Enum types are as big as the biggest of their variant (plus discriminant),
which was quite big because some shorthands
expand to many longhand properties.
This type was returned through many functions and methods,
wrapped and rewrapped in `Result` with different error types.
This presumably caused significant `memmove` traffic.
Instead, we now allocate an `ArrayVec` on the stack
and pass `&mut` references to it for various functions to push into it.
This type is also very big, but we never move it.
We still use an intermediate data structure because we sometimes decide
after shorthand expansion that a declaration is invalid after all
and that we’re gonna drop it.
Only later do we push to a `PropertyDeclarationBlock`,
with an entire `ArrayVec` or nothing.
In future work we can try to avoid a large stack-allocated array,
and instead writing directly to the heap allocation
of the `Vec` inside `PropertyDeclarationBlock`.
However this is tricky:
we need to preserve this "all or nothing" aspect
of parsing one source declaration,
and at the same time we want to make it as little error-prone as possible
for the various call sites.
`PropertyDeclarationBlock` curently does property deduplication
incrementally: as each `PropertyDeclaration` is pushed,
we check if an existing declaration of the same property exists
and if so overwrite it.
To get rid of the stack allocated array we’d need to somehow
deduplicate separately after pushing multiple `PropertyDeclaration`.
We need another flag that represents allow-negative-number for SMIL, so
this enum will also comprise the another parsing mode that allows negative number.
Fix variable serialization bug on shorthand alias properties
<!-- Please describe your changes on the following line: -->
-moz-transform were having a problem with variable serialization. It wasn't printing transform's value and transform wasn't printing -moz-transform's if their value was a variable. This PR fixes that.
Reduces stylo -moz-transform failures to 2: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fd3a57873e5e98dfcb173eef4b13822a66fdf6a
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/16607)
<!-- Reviewable:end -->
Text style is always resolved via ServoStyleSet::ResolveStyleForText, either
from the frame constructor initially, or from
ServoRestyleManager::ProcessPostTraversalForText.
So text-only adjustments should go there instead. Since that doesn't call into
cascade(), all the code that passes `pseudo` there is dead code we can remove.
MozReview-Commit-ID: jpbBYpLlUL
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Ports the Gecko fixup for text-combine-upright writing mode to Servo. In
addition, this passes the current pseudo element (if any) down to the cascade
for use during the fixup process.
MozReview-Commit-ID: BkHd4AvSsOt
1. We add a new arm to TransitionProperty, TransitionProperty::Unsupported,
which contains an Atom, so it's better to remove the Copy trait from
TransitionProperty.
2. TransitionProperty::Unsupported(Atom) represents any non-animatable, custom,
or unrecognized property, and we use Atom to store the ident string for
serialization.
stylo: Add glue for contain property
In gecko, `size` and `content` values aren't implemented yet. So I had to disable these parts with mako. We will need to update the property and the glue once these are implemented in gecko.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1354998](https://bugzilla.mozilla.org/show_bug.cgi?id=1354998)
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so tha
t we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/16467)
<!-- Reviewable:end -->
scriptlevel is a property that affects how font-size is inherited. If scriptlevel is
+1, for example, it will inherit as the script size multiplier times
the parent font. This does not affect cases where the font-size is
explicitly set.
However, this transformation is not allowed to reduce the size below
scriptminsize. If this inheritance will reduce it to below
scriptminsize, it will be set to scriptminsize or the parent size,
whichever is smaller (the parent size could be smaller than the min size
because it was explicitly specified).
Now, within a node that has inherited a font-size which was
crossing scriptminsize once the scriptlevel was applied, a negative
scriptlevel may be used to increase the size again.
This should work, however if we have already been capped by the
scriptminsize multiple times, this can lead to a jump in the size.
For example, if we have text of the form:
huge large medium small tiny reallytiny tiny small medium huge
which is represented by progressive nesting and scriptlevel values of
+1 till the center after which the scriptlevel is -1, the "tiny"s should
be the same size, as should be the "small"s and "medium"s, etc.
However, if scriptminsize kicked it at around "medium", then
medium/tiny/reallytiny will all be the same size (the min size).
A -1 scriptlevel change after this will increase the min size by the
multiplier, making the second tiny larger than medium.
Instead, we wish for the second "tiny" to still be capped by the script
level, and when we reach the second "large", it should be the same size
as the original one.
We do this by cascading two separate font sizes. The font size (mSize)
is the actual displayed font size. The unconstrained font size
(mScriptUnconstrainedSize) is the font size in the situation where
scriptminsize never applied.
We calculate the proposed inherited font size based on scriptlevel and
the parent unconstrained size, instead of using the parent font size.
This is stored in the node's unconstrained size and will also be stored
in the font size provided that it is above the min size.
All of this only applies when inheriting. When the font size is
manually set, scriptminsize does not apply, and both the real and
unconstrained size are set to the explicit value. However, if the font
size is manually set to an em or percent unit, the unconstrained size
will be set to the value of that unit computed against the parent
unconstrained size, whereas the font size will be set computing against
the parent font size.
MozReview-Commit-ID: 820BIWqno3L
