- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED) or
if the transform has changed (TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
We need a basic representation of animations from which we can derive subclasses
to represent specific cases such as transitions. For now we will retrofit
ElementAnimation for that purpose hence renaming it to StyleAnimation.
This patch removes the "using namespace mozilla::layers" line from
AnimationCommon.cpp since the unified build system concatenates several files
together before compiling making using declarations like this leak into other
files potentially creating ambiguities. Previously, when we were calling
ElementAnimation, 'Animation', there were ambiguities between
mozilla::layers::Animation and this new 'Animation' class. In general, it is
probably a good idea to limit the scope of these using declarations so I've kept
that change.
The loops for adding animations and transitions to a layer in
nsDisplayList::AddAnimationsAndTransitionsToLayer are now identical and so can
be factored out into a common method.
Since it is not possible to implicitly convert from
nsTArray<ElementPropertyTransition> to nsTArray<ElementAnimation> despite
ElementPropertyTransition being a subclass of ElementAnimation a templated
method is used. In the future, as animations and transitions share more and more
code, we should be able to remove the need for templates.
Now that ElementTransitionProperty inherits from ElementAnimation,
ElementTransitions::HasAnimationOfProperty can re-use
ElementAnimation::HasAnimationOfProperty in its definition of
ElementTransitions::HasAnimationOfProperty.
Similarly, in nsDisplayList::AddAnimationsAndTransitionsToLayer we can use this
method rather than drilling down to the appropriate segment by hand.
As part of moving towards more shared data structures for animation, this patch
makes ElementPropertyTransition inherit from ElementAnimation. At the same time
we switch from storing the target property, start/end values, start time, delay,
and timing function on the transition to the corresponding location in
ElementAnimation.
Since nsDisplayList::AddAnimationsAndTransitionsToLayer was already doing this
conversion in order to create animations to pass to the compositor thread, we
can remove the conversion code from there and just use the ElementAnimation data
structures as-is.
A number of assertions are added to verify that transitions are set up as
expected (namely, they have only a single property-animation with a single
segment). As we move to more generic handling of animations and transitions
these assertions should disappear.
As a first step towards making CSS animations and CSS transitions use the same
data structures, this patch aligns their behavior with regards to start time and
delay handling.
Previously, ElementAnimation objects maintained separate mStartTime and mDelay
members whilst ElementPropertyTransition objects maintained a single mStartTime
property that incorporated the delay. This patch adds an mDelay member to
ElementPropertyTransition and stores the delay and start time separately.
Calculations involving ElementPropertyTransition::mStartTime are adjusted to
incorporate mDelay.
I confirmed that the crashtest crashes in the harness without the patch.
--HG--
rename : layout/reftests/backgrounds/blue-32x32.png => layout/style/crashtests/blue-32x32.png
