Most of it is automated by:
%s/eStyleContentType_/StyleContentType::/g
%s/nsStyleContentType/StyleContentType/g
But I removed some parentheses by hand.
Differential Revision: https://phabricator.services.mozilla.com/D1900
MozReview-Commit-ID: 3IcirjIYX5p
The EffectSet count does not exactly represent the count what we really need
for AnimationValueMap, but in most cases it matches. For example;
1) The element has two different keyframes animations
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { transform: rotate(360deg); }
}
In this case the number matches.
2) The element has two animations but both keyframes have the same CSS property
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { opacity: 0.1; }
}
In this case the number doesn't match, moreover it results more memory than we
ever needed, but this case is presumably less common.
3) The element has an animation having keyframes for two different CSS
properties.
@keyframes anim {
from { opacity: 0; transform: rotate(360deg); }
}
In this kind of cases, the number doesn't match. But even so, this patch
reduces the opportunities that the AnimationValueMap tries to allocate a new
memory (i.e. less opportunities on expanding the map).
Note that when the hash map is expanded, we do allocate a new RawTable with the
new size then replace the old one with the new one [1], so I believe this
change will reduce the crash rate to some extent.
[1] https://hg.mozilla.org/mozilla-central/file/15c95df467be/servo/components/hashglobe/src/hash_map.rs#l734
MozReview-Commit-ID: 6tcF9aqXh7a
--HG--
extra : rebase_source : 366989d3a2756f5a5711503a57f42f3b746d93a5
And use the C++ ErrorReporter only to actually output errors.
ErrorReporter was so complicated because well, it was always enabled and had to
do a bunch of caching to not be (more) slow.
But since bug 1452143 it's disabled by default, so we can simplify this setup a
lot.
Also while at it make the error reporting pref a static pref so that we don't
mutate globals from CSS parsing unless we're actually reporting errors.
MozReview-Commit-ID: AuIyvJwt7AU
Pretty much the same setup we have for document.
We have the awkwardness of having to check containing shadow manually for
ShadowRoot because it's not available in TNode (and making it available added a
bit more complexity that wasn't worth it IMO).
MozReview-Commit-ID: CqOh0sLHf6o
Pretty much the same setup we have for document.
We have the awkwardness of having to check containing shadow manually for
ShadowRoot because it's not available in TNode (and making it available added a
bit more complexity that wasn't worth it IMO).
MozReview-Commit-ID: CqOh0sLHf6o
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
And also remove ComputedImageUrl::from_url_value_data.
MozReview-Commit-ID: 5zifQlU7tOz
--HG--
extra : rebase_source : 23631ad2e9144cf30951a3d07421a8e5ae0ba8ec
This is needed to serialize computed URLs correctly from getComputedStyle.
MozReview-Commit-ID: 9wakhqNrszb
--HG--
extra : rebase_source : 7d120ac0917a5e13de4e52b7dfa0d784495fd8f7
Note that we also drop the dead optional aReusableSheets argument from
the async parsing path, since it was always null.
MozReview-Commit-ID: KddpGFdaqEe
This patch basically does:
* Add descriptor setters and generation count to CounterStyleRule in
Servo. (This code is mostly based on the old code inside
nsCSSCounterStyleRule for handling mutation.)
* Use RawServoCounterStyleRule in CounterStyleManager.
* Add ServoCounterStyleRule and remove nsCSSCounterStyleRule.
Test change:
* "fixed" was parsed as and thus serialized to "fixed 1", but Servo
doesn't do so. It preserves whether the number presents. Either way
is probably fine.
MozReview-Commit-ID: EtKTeu32isi
--HG--
extra : rebase_source : ec44f01c581003ce4b6ef69435a05de7f3da5469
This patch does the following things:
* Create a new class ServoFontFaceRule for CSSOM of @font-face rule
which mostly follows how nsCSSFontFaceRule was implemented.
* Remove the old nsCSSFontFaceRule and binding code to create it.
* Have FontFace backed by Servo data via making mRule and mDescriptors
of the class hold RawServoFontFaceRule like ServoFontFaceRule.
To keep this patch small, it effectively just delays the conversion
from Servo data to nsCSSValue from parsing to using. This may cause
worse performance if the font set is flushed repeatedly. Supposing we
don't flush font set very frequently, it may not be a big deal.
We may still want to remove the intermediate nsCSSValue conversion at
some point, and have everything converted to their final form directly
when used, but that can happen in followups.
There are some unfortunate bits from this change:
* We lose style sheet for logging in FontFaceSet. This is probably not
all that worse, because we wouldn't have that before either if the
page doesn't use CSSOM to visit it. But we should figure out some
approach to fix it anyway.
* InspectorFontFace no longer shares the same rule object as CSSOM.
This isn't really a problem if the @font-face rule isn't very mutable.
Unless we want to make the rule returned from InspectorFontFace to be
mutable (i.e. via inspector), not using the same object probably isn't
too bad.
This patch switches the code we use to serialize stuff in FontFace and
CSSFontFaceRule, which leads to some failures in tests. Specifically,
the expected changes including:
* Value of font-family now can be serialized to identifier sequence like
font-family property. The old code always serializes it to string,
but it doesn't seem to have different requirement than the property.
Blink can serialize to identifier as well.
* Family name inside local() is also changed to use the same way as
family names elsewhere (i.e. can be identifier sequence). Blink has
the same behavior as the old code, but I don't think it's a big deal.
* The order of descriptors serialized gets changed. I don't think it
matters at all.
* Empty string as font-family via using string syntax is no longer
considered invalid for FontFace. I don't find it is mentioned anywhere
that it should be specifically treated invalid.
MozReview-Commit-ID: 32Fk3Fi9uTs
--HG--
extra : rebase_source : 6221ec8fc56de357b06dd27e770fb175348a2f77
nsStyleStructList.h was initially made generated in bug 873368 to avoid
manually maintaining boilerplate for if-dispatch, while the if-dispatch
was replaced by jump table in bug 1171842, so the boilerplate went away.
However, in bug 1122781 (before bug 1171842), boilerplate for dependency
check, so it still needs to be generated.
The dependency table is removed in the previous patch, so we no longer
have any boilerplate in the style struct list, and thus it doesn't need
to be generated anymore.
MozReview-Commit-ID: GkbJZ98ojbE
--HG--
extra : rebase_source : a148b97c051bb6c88846cf6ba617c4edef70ca24
extra : source : f1c7d19cde195fb90ac2627d16ed69d020de01b9
This avoids resetting the computed values all the time, and paves the way to
avoid using a StyleSet on XBL bindings / Shadow DOM, which we should really
really do because it's super overkill.
There are some XBL bits that are kind of hacky, in particular the mStylistDirty,
but they'll go away soon, since I want to redo how we store styles in XBL.
The alternative, which was returning an array of indices or something was even
more hacky I think.
MozReview-Commit-ID: 6tEl5gebXVF
Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T