| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Ic24bb0e1e669989f0cae3a9b8fa064b38c8e7948
|
|
|
|
| |
Change-Id: I8bd3005f363afb52e6624806efb3e04c4a56ee18
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I2bc52ca16507d8d20004d2d6823e587791272aac
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/|
| |
| | |
* commit '02be2f1d874078f227af34fcac7863eca1f35653':
docs: fix some typos
|
| |
| |
| |
| | |
Change-Id: I2dc9855f8fe87234d4337351e8bac6c382fb74d2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
| |
Change-Id: I52cdd29616f7f30784c0f8352c035493c8d413dc
|
| |
|
| |
|
|
|
|
| |
Change-Id: I4c7bd9d4843c355efd9c89059462f19600c3be45
|
|
|
|
| |
Change-Id: I4407468599061ff35c68589988fb1e897de28c69
|
|
|
|
| |
Change-Id: Iaaf5a38388ceccdd0d1f3766523788f54f1dc8d2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Iee74b475960d623fa757349e4053bd7c58cf5734
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I0384a437089d11dda03d0657235404ea96e8b19d
|
|
|
|
| |
Change-Id: I0ea077d9434ac3e22e8600f22ca4a24a6a46965c
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
| |
Change-Id: Ic5f5f40ee39787403977fb372b335dc21cf07243
|
|
|
|
| |
Change-Id: I15c1acc468ff17a1ebd1bc28288d0ac7113748b2
|
|
|
|
| |
Change-Id: Id1b1ab8e15d9af9fa38946cc5c673062a4b5a72d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I5664bee6d27b32a70ca7d335e7fbe0af39a240bd
|
|/
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This approach is only for the common cases of void-return,
single-argument float/int methods.
Change-Id: Ifb31535a6f717b85417eced93c579be6e461e039
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I316a48273a9cbb428a965e4b849b3e5e9e8202f1
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
copying them
Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a
|
|\ |
|