I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 386a1b9fe5ffc5fefbf20678068573ea195043f0
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 926f8442fbd17c7ffa7f72b6b4a515a28b9aa18b
And propagate the new flag to servo if mRestyleForCSSRuleChanges is set.
MozReview-Commit-ID: HRZ5duYgciF
--HG--
extra : rebase_source : 65528ea0dfa21e84bb9184a849c72a5c322e306b
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
--HG--
extra : rebase_source : 314408062e719e9f52df9a6726e2f3dad817bbef
This allows us to access metadata using `match` instead of comparison with
atoms, which makes it doable to get the pseudo-element flags in the future.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
MozReview-Commit-ID: KgGjFePmhyS
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
--HG--
extra : rebase_source : 57614aed13d2c088fe129ecf3fabf9869d5a6d50
This does not remove the eager rebuilds we're doing yet.
I'm not completely happy with the ad-hoc manner in which we end up doing
rebuilds. I considered doing something where we'd make stylist a non-public
member of PerDocumentStyleDataImpl and have a getter that updates the stylist on
get, with maybe a separate non-flushing getter for special situations, if those
arise. But that requires that we make various cases where we currently have a
non-mut PerDocumentStyleDataImpl use a mut one. Maybe that would be the right
tradeoff...
I'm also not sure whether the naming is right here. Maybe we should just talk
about needing a stylesheet flush, not a stylist rebuild, in ServoStyleSet?
MozReview-Commit-ID: 9C7BG5ygm79
--HG--
extra : rebase_source : b70ff0fe5300fed11b36e4c71c1d78b51aa6488b
I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
--HG--
extra : rebase_source : b02d516ea164fc567110338411bf6ba251d53dab
In a later patch, we'll want to queue up some tasks to run when the
Servo traversal is one, and the ServoStyleSet seems like the natural
place to store those tasks. We could probably find the ServoStyleSet
by chasing a bunch of pointers from the task-adding call sites, but
it seems simpler just to make it available directly.
MozReview-Commit-ID: AJoFZEoNaGm
--HG--
extra : rebase_source : 78389d72ba6dfb4301ba75bd39bbdc51d13cb4d5
In a later patch, we'll want to queue up some tasks to run when the
Servo traversal is one, and the ServoStyleSet seems like the natural
place to store those tasks. We could probably find the ServoStyleSet
by chasing a bunch of pointers from the task-adding call sites, but
it seems simpler just to make it available directly.
MozReview-Commit-ID: AJoFZEoNaGm
--HG--
extra : rebase_source : d8afe0c2cdf1ea4b1681c6e57aea48c9efddea00
AnimationValue::FromString compute the AnimationValue from a string.
MozReview-Commit-ID: CX8wairpnfN
--HG--
extra : rebase_source : 05dbaa84bf40463a0021bd538d7baba5d591f992
The function uses document's default computed values if the parent style
is not specified.
MozReview-Commit-ID: ICd3phAi0C6
--HG--
extra : rebase_source : 343dee682096b75cd7f905db7207823f7e3624b5
Also this patch add nsIAtom as an argument to ResolveTransientStyle() to call
the new function ResolveServoTransientStyle easier. The only call site of the
ResolveTransientStyle() has already nsIAtom* there.
MozReview-Commit-ID: IwxqZbaCSpB
--HG--
extra : rebase_source : b94a3a8723fe53f38eb6144a5926dec3d7796e72
This argument will be used to control whether we are restyling in preparation
for reframing a subtree, which can avoid generating any change hints, as we
aren't preserving the frames that they would otherwise apply to.
MozReview-Commit-ID: DkLVCUnNGt
--HG--
extra : rebase_source : cb3537cea26cb9805b2ec1556cf5ca6eb9d38ab8
This base value will be used for additive, accumulative animations
and also SMIL.
MozReview-Commit-ID: LHV8ZnxSzjb
--HG--
extra : rebase_source : 507a8dd74961e7f439b90fd4c5f90a98706aa434
The next patch moves nsCSSFontFaceRule into a separate header, which
somehow affects lots of header dependencies. I'm not completely sure
why this happens, though.
MozReview-Commit-ID: KuXbsaX0NUd
--HG--
extra : rebase_source : cef91018964b5488c5031df8aada90aa7fa0ad51