mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
995aea0ff8
When updating the cascade results between transitions and animations, if we detect a change we force an update by taking the following steps: a. Updating the animation generation on the restyle manager b. Updating the animation generation on the collection c. Iterating over all the properties animated by the collection and, for each property that we can animate on the compositor, posting a restyle event with the appropriate change hint (nsChangeHint_UpdateTransformLayer or nsChangeHint_UpdateTransformOpacity) d. Marking the collection as needing refreshes e. Clearing the style rule refresh time so we generate a new style rule in EnsureStyleRuleFor As it turns out, the newly-added AnimationCollection::RequestRestyle(RestyleType::Layer) already performs a, b, d, and e. It also: * Ensures we are observing the refresh driver if need be (should have no effect in this case) * Clears the last animation style update time on the pres context so that subsequent calls to FlushPendingNotifications will update animation style (it seems like we probably should have been doing this for changes to cascade results anyway) * Posts a restyle event with restyle hint eRestyle_CSSTransitions or eRestyle_CSSAnimations * Marks the document as needing a style flush (irrelevant since posting a restyle event does this anyway) The only missing piece that would prevent using RequestRestyle in place of this code when updating cascade results is (c) from the list above. However, (c) should not be necessary since ElementRestyler::AddLayerChangesForAnimation() explicitly checks for out-of-date layer animation generation numbers and adds the appropriate change hints (nsChangeHint_UpdateTransformLayer etc.) to the change list. |
||
---|---|---|
.. | ||
base | ||
build | ||
doc | ||
forms | ||
generic | ||
inspector | ||
ipc | ||
mathml | ||
media | ||
printing | ||
reftests | ||
style | ||
svg | ||
tables | ||
tools | ||
xul | ||
moz.build |