Brian Birtles 7f6947284e Bug 1188251 part 12 - Use RestyleType::Layer in UpdateCascade; r=dholbert
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.
2015-08-18 16:11:55 +09:00
..
2015-08-17 17:15:24 -07:00
2015-08-17 16:54:21 -07:00