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
This new class allows listeners to receive callbacks with elapsed time
that are sent on the same animation updates as other animators in the system.
It will allow simulations that go beyond the current animation system while
handling the actual animation timing system and ensuring that those
simulations sync up with other typical animations.
Change-Id: Iac91c39634218793f6598a7dec5ed71dc9630258
There was a bug with LayoutTransitions where if the animations
were of different duration (such as in the current status bar clock),
it was possible to end up in a bad situation because the previous animation
might outlast the new animation, causing the opposite end result
from what was expected. The fix was to keep track of the current
add/remove animations and to cancel any running ones prior to starting
new ones.
Change-Id: I884ce33ce0671f6ba6153ee3951c8d14c5ed5714
Previously, cancel() and end() calls would simply log a message to
be handled later by the animation handler. This caused problems with
coordinating complex animations, where some start() events for
future animations would occur before end() events for animations already
completed.
The change is to make these events synchronous (and require them to be
called from the appropriate thread), simplifying the code and the usage.
Also, fixed various timing and event bugs in AnimatorSet, and removed
the getter/setter properties from ObjectAnimator, since an earlier change
makes these properties undesirable (because the code will use a faster
JNI approach instead of reflection when it can).
Change-Id: I05c16645c2a31a92048a6031ddb126eb4312a946
You can now use floats, ints, dimensions, or colors as input values
in XML for Animator objects. There is still a 'valueType' attribute
that lets you specify the number values to create the animator with,
though it defaults to floats (or in the case of color inputs, to ints).
Change-Id: I65f1df802db602c33f2a0308a663b6f808148e25
There was a bug around animation duration where it was possible,
for small durations or large inter-frame times, to calculate
fractions outside of the 0-1 range, causing bad value calculations.
Unrelated: new View properties for translation, scale, and rotation
were added in this release. This commit addes XML resources for
those properties.
Change-Id: Ieaf5dd729588adb2a40656aa82beecc3576f4af5
Issues around threading of animations and AnimatorSet bugs are
fixed in this change. Unrelated fixes to javadocs in other
framework classes are also part of the change.
Change-Id: I35f7e03ffdec9143bc2eb155e8f9384798ad35b3
The previous version of PropertyValuesHolder handled construction fine,
but setting new values did not result in things getting completely set
up correctly for interpolation between those new values.
Change-Id: Ibffb16e58b4fe76b8d1cad6f0224ffd4d5404c05
The animator classes caused autoboxing by converting primitive types (by far
the most typical types used in animations) to be converted to their
Object equivalents because of various APIs that required Object
(like getValue() to get the animated value). This change creates
factory methods on some classes instead of the former constructors
so that we can create and return private type-specific subclasses
which operate directly on the primitive types instead.
In particular, float and int are natively supported by the animators
now. Support in the APIs for double and long was removed because it
seemed like these less common types did not justify the extra
baggage of the added API and code.
Change-Id: I6008a3883e3d6dd5225005f45f112af148e5a4ea
Certain fields in Animator are statics, like the list of current animations and the
main handler. However, since there may be >1 UI thread per process, these should really
be ThreadLocal variables, so that they are local to each UI thread. For example,
most animators will cause an invalidation in the view hierarchy, which can only
happen in the UI thread for that view.
Change-Id: I42be61c781ffac97b527f78ce1ffc2e0cdc42999
This will be used for StrictMode to annotate violations with
whether or not they janked up an animation.
Change-Id: I5bc691f49b74c45279cd2ae044d2a81dcf1204a9
Change the manner of constructing Animator-related objects from constructors
via generics to factory methods with type-specific method names. Should
improve the proliferation of warnings due to generics issues and make the
code more readable (less irrelevant angle brackets Floating around).
Change-Id: Ib59a7dd72a95d438022e409ddeac48853082b943
Change the manner of constructing Animator-related objects from constructors
via generics to factory methods with type-specific method names. Should
improve the proliferation of warnings due to generics issues and make the
code more readable (less irrelevant angle brackets Floating around).
Change-Id: I7c1776b15f3c9f245c09fb7de6dc005fdba58fe2
There is a hard-coded limit to the frame rate of animations; this commit increases that rate by changing the inter-frame delay from 30 ms to 10 ms (although the actual delay will be determined by the maximum refresh rate of the system and the system load). For example, the effective maximum on current devices is 55 fps, or a delay of about 16 ms.
Change-Id: Id96a41cef36851e2d9508a98934f4b25595251ea
The new animation package's reliance on the old Interpolator interface (in
android.view.animation) was an eyesore. Adding TimeInterpolator, and having the
old Interpolator interface extend it, allows the new Animator classes to break
the tie to the older animation package completely. However, developers can still
use the older Interpolator-based classes, such as AccelerateInterpolator,
because they all implicitly extend the new TimeInterpolator class.
Change-Id: I41132fa56167ba564f4839113289114d0ea31a92
This adds a new "Energy Wave" widget to the internal widgets and
integrates it into LockScreen.
ValueAnimator needed a slight modification since it expects to
be run inside of Activities with a Looper. Additionally, this adds
an API, removeAllUpdateListeners(), which is needed to properly
recycle ValueAnimator objects.
Some minor code cleanup and UI tweaks after review.
Changed delay timeout from 1.3s to 0.5s.
Change-Id: Ibcf015e61fa8ba79d62f2019f1b29ace7caa00c8
