If possible, it's better to avoid doing interpolation and uncomputation for those properties which override animation level [1]. In Gecko, we do these by calling EffectCompositor::MaybeUpdateCascadeResults() to get the !important properties; however, UpdateCascadeResults() may not be thread-safe because we need to revise data of EffectSet, so I didn't add it into GetServoAnimationRule() in bug 1317209. If bug 1340445 could let us store the element-specific storage, we can try to fix it. [1] http://searchfox.org/mozilla-central/rev/ea31c4b64f34a29415a69fb768f8051495547315/dom/animation/EffectCompositor.cpp#488

(In reply to Boris Chiou [:boris] from comment #0) > If possible, it's better to avoid doing interpolation and uncomputation for > those properties which override animation level [1]. In Gecko, we do these > by calling EffectCompositor::MaybeUpdateCascadeResults() to get the > !important properties; however, UpdateCascadeResults() may not be > thread-safe because we need to revise data of EffectSet, so I didn't add it > into GetServoAnimationRule() in bug 1317209. If bug 1340445 could let us > store the element-specific storage, we can try to fix it. To be clear, in gecko we don't throttle animations overridden by something at all. See bug 1300982. MaybeUpdateCascadeResults() is used as a trigger to pull animations on the compositor back to the main thread.

If I understand comment 1 correctly, we can achieve gecko parity without this. I think that means this is nice-to-have but wouldn't block shipping, so setting P4. Feel free to correct if I've got that wrong.