Improved how the various callbacks are managed and sequenced
to reduce code duplication.
Added a heuristic to avoid postponing traversals until
the next vsync frame if we did not actually do any drawing during
the previous frame. This helps in the very common case where
drawing occurs in response to input.
Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
Starting several animations will place separate events onto the
animation queue, which may cause the active animations to get
processed more than once in any frame when one of those start messages
is processed.
This change moves the logic of starting pending animations into
the animation frame processing itself. Now when a start event is
processed, it only calls the animation frame logic if there are
unstarted animations pending.
Issue #6172602 Inconsistent animation callbacks
Change-Id: I3a546f0c849f42b2dd998f099fcdfafd7d780ad9
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
This class has existed since ICS, but was hidden. This change
just makes it public API.
Also, cleaned up some internal javadocs.
Change-Id: Id69408446ced183e01d2b065a67397eb305d9665
LayoutTransition side-effects the alpha property on View to fade views
in and out. This works fine if the layout transition is always used on
those views' container. But if you fade out a disappearing view and then
set the transition to null on the container and set that view to VISIBLE,
there is no transition logic to restore the alpha value to 1 (opaque).
The fix is to always restore alpha to its pre-animation value when fading
the view out.
Also, added extra info to alpha and the various View transform properties
to help hierarchyviewer debugging.
Issue #5958434: LayoutTransition temporary disablement may leave some views invisible
Change-Id: I3c21b0e7334dc29c10c5e372b589f0e2b59c2883
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
This is an update to a previous CL; this approach uses the WindowManager
to store the animator scale settings, instead of SystemProperties.
Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
Change-Id: I3d5fbc956695c88d01c30820259da3e107ffd8a3
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
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
