Both animations and drawing need to march to the beat of
the same drum, but the animation system doesn't know
abgout the view system and vice-versa so neither one
can drive the other.
We introduce the Choreographer as a drummer to keep
everyone in time and ensure a magnificent performance.
This patch enabled VSync based animations and drawing by
default. Two system properties are provided for testing
purposes to control the behavior.
"debug.choreographer.vsync": Enables vsync based animation
timing. Defaults to true. When false, animations are
timed by posting delayed messages to a message queue in
the same way they used to be before this patch.
"debug.choreographer.animdraw": Enables the use of the animation
timer to drive drawing such that drawing is synchronized with
animations (in other words, with vsync or the timing loop).
Defaults to true. When false, layout traversals and drawing
are posted to the message queue for execution without any delay or
synchronization in the same way they used to be before this patch.
Stubbed out part of the layoutlib animation code because it
depends on the old timing loop (opened bug 5712395)
Change-Id: I186d9518648e89bc3e809e393e9a9148bbbecc4d
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: I2c9f312cc2bcf4f2d08ac6b5d8f8e495aa4f3597
When a transition occurs, layout change listeners are added to the container
being transitioned as well as every container up the view hierarchy. The
parent views were not having those listeners removed, so every time a transition
ran, more listeners would be added. Adding to that, the use of an ArrayList
as the collection to hold the listeners meant that adding duplicate items
would just increase the size of the list. There's now a sanity-check on the add
call to make sure that the listener does not exist already, but more importantly
we remove all listeners added when the transition ends.
Change-Id: I4ea05adf30765db091124065539b0ffd32729b3b
This new hidden API is called by ViewRootImpl when there is a pending
transition but the parent window is not visible.
Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
Logic in performTraversals() starts a transition running at the
proper time. But when a view's parent window goes away, this transition
may not start at that time because drawing gets canceled. But the
transition still hung off of the ViewRoot, waiting until some later
drawing operation to kick it off. This resulted in some weird animations
like the Recents panel appearing and having a single item animate off of it.
The fix is to delete pending transitions when drawing is skipped.
Change-Id: I3ab7702c16e069644a163424f977350743e2cecc
Previously, setting custom animations on a LayoutTransition would cause
those animations to be run not only for changing views in the container, but
for the parent hierarchy of those views as well. This can lead to unexpected
behavior, as seen in the ApiDemos LayoutAnimations and LayoutAnimationsHideShow.
This change changes the behavior so that the parent hierarchy is animated by
the default animations (which change the bounds and scrollX/Y fields) instead
of custom animations.
Change-Id: I9a04d97fabbc34dc0d5809eb3fd8ac08e0801d7c
Previously, AnimatorSet incorrectly checked whether child animations were
'running' to figure out what to cancel. If a child animation was started, but
sitting in a startDelay phase, it was not 'running', so the right cancel/end
events would not propagate.
The fix is to add a new isStarted() API to Animator, which returns true when
the animator has started (but not yet ended), regardless of whether the animator
has a startDelay or not. It's basically a superset of the existing isRunning()
method, which only returns true when an animator has actually started setting values.
Change-Id: I126814cb6637b58295b6d18d9b155235671f99be
AnimatorSet was incorrectly ignoring cancel() when it was in the
initial startDelay phase. Fix is to change isRunning() to be true if the
animator is also in its delay phase.
Change-Id: I1a8c877de24fa294beea0ba30d495658255b13b3
This bug caused an artifact in Recent Apps where you might see things
pop to their end location before popping back and then animating correctly
into place.
Change-Id: Ia7313ec76cc42162528c3c167b8bc562284b14bc
Static objects were referencing the first LayoutTransition object,
which referenced its target container, which eventually referenced the
Activity. That reference chain never went away.
The fix is to create animators that do not reference any target
object (they are just templates which are loaded with real target
objects when they are started).
Change-Id: Ie29f53bf3b886b8052b6ee3a56647a312d9adeaa
Previously, calling cancel() on an Animator would cause onAnimationCancel
events to be sent to all listeners. This was confusing for listeners
that were keying off this event for performing other actions, when the original
animator wasn't truly canceled (because it wasn't even running, or had already
been canceled earlier). This change hinges listener notification on
the animator actually running; no events are sent otherwise.
Also added the first set of Animator tests to verify that this behavior
is correct.
Change-Id: I81ab56559b5c0343c8dc7880e1c8235f3020975b
This change adds a generic Property facility to the SDK, which allows an
easy way to reference fields (private or otherwise) in a general way.
For example, animations can use this facility to animate 'properties'
on target objects in a way that is more code- and compiler-friendly than
the existing String-based approach (for objects which have implemented
Properties, of course). The animator classes have been updated to use
this new approach (in addition to Strings, which are still more generally
useful for objects which have get/set functions but not Property objects).
The change also includes new Property objects on View (which can now be
used in creating animations on Views).
There is an unrelated change on GLES20RecordingCanvas to change the way we
cache bitmaps, which avoids spurious garbage by using an ArrayList instead of
a HashSet.
Change-Id: I167b43a3fca20e7695b1a23ca81274367539acda
This change compensates for changes in the parent hierarchy of
transitioning views. It automatically animates parents with the same
animations as those used for the CHANGING animations run on the container
children.
Change-Id: I86471d16a9070b024cc09c8f6e0f504a881fa99f
When a ValueAnimator is cloned, we correctly clone the underlying
PropertyValuesHolder objects and assign them to the new object.
However, we then put values into the new property map using the
old values instead of the new ones. This means that the per-property
animated values cannot be retrieved with the property names from
the cloned animator, because the map refers to the values of the
original object, not the cloned object that is actually being animated.
Fix is easy: just put the cloned values (which are already being created)
into the map.
Change-Id: I81282ca1dab6b1767ddc894d57a1110b344b4b0a
A recent change to LayoutTransition caused new layout transitions to
cancel any previously-running animations. This was to handle situations
where a transition adding an item needed transitions removing items to
finish their job first (and vice versa). But canceling *all* running
animations from transitions caused some artifacts, like making the status
bar icons blink or fade in, depending on which one was started last.
The new approach is to cancel just the ones we care about: adding animations
cancel removing animations, and vice versa. Either one cancels 'changing'
animations, which prevents objects from being animated to the old end
locations, since the new transition will animate them to the correct new
end locations.
Change-Id: I68ac351b05365cace6639b6618422395c35c83fd
Bug 3482310: The playing state was not being correctly set to
RUNNING after an animator was start()'d. Instead, we were seeking
to the start value (correct), setting the state to SEEKED (also correct),
but not resetting the playing state to STOPPED. So when the animation
actually started animating values, it didn't recognize that it was
starting a STOPPED animation, so it never set its state to RUNNING,
and never returned true from isRunning().
Change-Id: Iea92dce98f92f60052d8a9a451094b953f9f0c67
When setLeft/Right/Top/Bottom() functions were called on View,
invalidation was only happening at the parent level. When an
app is hardware accelerated, this means that the view's display
list is not being recreated. So views that were changing size due
to these calls were not getting redrawn properly, causing some
artifacts in animations (especially LayoutTransition, which
calls these setters).
Fix is to invalidate the child instead of just the child's bounds
in the parent.
Change-Id: Ic8b2a5db519345dce617f914c2214738f22031b2
When there are more than two keyframes, we treat each keyframe
interval as its own separate period during which to calculate animated
values. To do this, we calculate an intervaleFraction from the overall
elapsed fraction of the entire animation. This intervalFraction is then
used to calculate the animated values in that interval.
However, we failed to actually use the intervalFraction in some code
paths, using the overall fraction instead. This caused a jumping behavior
because we were incorrectly calculating the values during the intervals.
Change-Id: Ia052e1e8b5130ff450ee20c0a3581e3de42399e1
There were some subtle timing issues in animators with ending animations that
were not completely initialized (possibly because a startDelay'd animator
was ended before the delay elapsed).
Also, LayoutTransition had bugs around running a transition on a container
while a previously-started transition was still in progress. This could result
in some minor artifacts or crash bugs, depending on the durations and delays set
on the transition animations.
Change-Id: Ic6a69601f1ce9a55db15fff6b8ed25950b354491
The problem was that there can be >1 animation spawned for each
view in a container, if there are multiple events that trigger
a transition. These animations would potentially clobber object
layout values, causing problems as successive animations tried to use those
clobbered values to set up their own animation values.
The fix is to track the created animations and cancel them as future
animations on those same objects get created. This mechanism used to
be in the code (the bug came about when that mechanism went away), but
was removed because of memory leaks of never removing animations that
were set up but never started. The new approach also caches pending
animations, but runs a second aniamtor to delete the entries in that
collection just in case.
Change-Id: If60c7d188712334dea69d0794dc6b4ce29ca6c09
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
LayoutTransition works by animating layout-related properties
(left, right, top, and bottom). This works great when that animation
is the only thing affecting the layout of the UI. But if there are other things
happening in the application that cause layout to run on that
container or in its parent hierarchy, this can cause the layout properties
on its children to get mis-set during the middle of the transition.
This results in artifacts like animating objects jumping to locations where
they would be were there no animation running.
The fix is to supress layout requests on that container (and its children)
until the transition is complete (then issue a layout request on the container
to make sure that the container has the correct layout data)
Change-Id: I15bf0423a11409f854076f86099233db7fe4edc0
There was already a mechanism for sending out events for LayoutTransition
when animations started or ended, but the implementation only sent out events
for the appearing/disappearing animations. This fix provides callbacks to
listeners for the CHANGE_APPEARING and CHANGE_DISAPPEARING transitions, too.
Change-Id: Icfb8cc1c20d2df3e4a817255e96c9d0e94c1d8c4
Objects are invalidated and reset instead of being nulled out
and recreated. This avoids creating small amounts of garbage for
the display list and canvas objects.
Change-Id: I464fac7ea8944c19ad6d03f13a95d9017e3f4262
