summaryrefslogtreecommitdiffstats
path: root/core/java/android/animation
Commit message (Collapse)AuthorAgeFilesLines
* Add 'Property' objectChet Haase2011-06-085-91/+363
| | | | | | | | | | | | | | | | | | | | 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
* Add ability to transition parent hierarchy in layout transitionsChet Haase2011-05-241-115/+199
| | | | | | | | | 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
* Minor javadoc enhancementsChet Haase2011-05-061-0/+12
| | | | Change-Id: Ic24bb0e1e669989f0cae3a9b8fa064b38c8e7948
* Fix bitfield bug with vertex shader selectionChet Haase2011-04-221-3/+3
| | | | Change-Id: I8bd3005f363afb52e6624806efb3e04c4a56ee18
* Fix bug with values in cloned animators.Chet Haase2011-04-041-5/+3
| | | | | | | | | | | | | | 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
* Cancel LayoutTransition animations selectivelyChet Haase2011-03-021-23/+85
| | | | | | | | | | | | | | | | | 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
* Add ViewPropertyAnimator for easy animation of View propertiesChet Haase2011-02-251-0/+16
| | | | Change-Id: I2bc52ca16507d8d20004d2d6823e587791272aac
* Merge "Fix bug with bad state in animators"Chet Haase2011-02-231-0/+1
|\
| * Fix bug with bad state in animatorsChet Haase2011-02-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | am 02be2f1d: am 2788e4f9: docs: fix some typosScott Main2011-02-231-1/+1
|\ \ | |/ |/| | | | | * commit '02be2f1d874078f227af34fcac7863eca1f35653': docs: fix some typos
| * docs: fix some typosScott Main2011-02-231-1/+1
| | | | | | | | Change-Id: I2dc9855f8fe87234d4337351e8bac6c382fb74d2
* | Fix invalidation bug with View bounds propertiesChet Haase2011-02-164-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Fix when >2 keyframes supplied"Chet Haase2011-02-152-6/+6
|\ \
| * | Fix when >2 keyframes suppliedChet Haase2011-02-112-6/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix animation and layoutTransition issues.Chet Haase2011-02-092-13/+38
|/ | | | | | | | | | | | 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
* Fixed LayoutTransition bug moving multiple viewsChet Haase2011-01-281-9/+36
| | | | | | | | | | | | | | | | | | 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
* Use optimized display lists for all hwaccelerated renderingChet Haase2011-01-241-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Doc change: animation devguide topicRobert Ly2011-01-191-2/+17
| | | | Change-Id: I52cdd29616f7f30784c0f8352c035493c8d413dc
* Add a method for clearing all animations on a thread.Patrick Dubroy2011-01-161-0/+12
|
* Fix latent bug with reinitializing an ObjectAnimator.Patrick Dubroy2011-01-161-1/+2
|
* Fix animation bugs caused by weak referencePatrick Dubroy2011-01-161-59/+32
| | | | Change-Id: I4c7bd9d4843c355efd9c89059462f19600c3be45
* Remove obsolete DoubleEvaluatorChet Haase2011-01-165-55/+11
| | | | Change-Id: I4407468599061ff35c68589988fb1e897de28c69
* fix sdk build breakage; remove invalid @note tagScott Main2011-01-141-1/+2
| | | | Change-Id: Iaaf5a38388ceccdd0d1f3766523788f54f1dc8d2
* Allow old view hierarchy to be GC'ed more quickly during rotation.Patrick Dubroy2011-01-141-32/+58
|
* Supress layout requests while a LayoutTransition is running.Chet Haase2011-01-121-14/+38
| | | | | | | | | | | | | | | | | 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
* Rename RGBEvaluator to ArgbEvaluatorChet Haase2011-01-113-3/+3
| | | | Change-Id: Iee74b475960d623fa757349e4053bd7c58cf5734
* Add start/endTransition events for CHANGE transitionsChet Haase2011-01-091-0/+20
| | | | | | | | | 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
* Reuse display lists at the java level.Chet Haase2011-01-051-5/+5
| | | | | | | | 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
* Fix incorrect anonymous AnimatorListenerAdapter.Ben Komalo2010-12-161-4/+8
| | | | Change-Id: I0384a437089d11dda03d0657235404ea96e8b19d
* Fix minor animation and doc issuesChet Haase2010-12-161-2/+11
| | | | Change-Id: I0ea077d9434ac3e22e8600f22ca4a24a6a46965c
* Merge "Adding TimeAnimator capability (hidden for now)"Chet Haase2010-12-142-7/+85
|\
| * Adding TimeAnimator capability (hidden for now)Chet Haase2010-12-142-7/+85
| | | | | | | | | | | | | | | | | | | | 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
* | Fix artifact with concurrent add/remove LayoutTransitionsChet Haase2010-12-131-6/+19
|/ | | | | | | | | | | | 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
* Add ability to reuse bitmaps when loading new contentChet Haase2010-12-091-2/+2
| | | | Change-Id: Ic5f5f40ee39787403977fb372b335dc21cf07243
* Add space after property name in error messageMakoto Onuki2010-12-071-1/+1
| | | | Change-Id: I15c1acc468ff17a1ebd1bc28288d0ac7113748b2
* Remove broken doc link to removed methodChet Haase2010-12-071-12/+8
| | | | Change-Id: Id1b1ab8e15d9af9fa38946cc5c673062a4b5a72d
* Change cancel/end behavior of animations to be synchronousChet Haase2010-12-075-114/+114
| | | | | | | | | | | | | | | | | 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
* Merge "Add methods to AnimatorSet that take collections"Chet Haase2010-12-011-1/+41
|\
| * Add methods to AnimatorSet that take collectionsChet Haase2010-12-011-1/+41
| | | | | | | | Change-Id: I5664bee6d27b32a70ca7d335e7fbe0af39a240bd
* | Animators can now have dimension and color values.Chet Haase2010-12-011-51/+75
|/ | | | | | | | | 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
* animation bugfix plus xml resources for new View propertiesChet Haase2010-11-301-3/+2
| | | | | | | | | | | | 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
* various fixes for animations and javadocsChet Haase2010-11-232-17/+48
| | | | | | | | 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
* Adding JNI methods as a faster reflection mechanismChet Haase2010-11-042-13/+126
| | | | | | | This approach is only for the common cases of void-return, single-argument float/int methods. Change-Id: Ifb31535a6f717b85417eced93c579be6e461e039
* Fixed problem with setting updated values on existing animatorsChet Haase2010-11-031-0/+10
| | | | | | | | 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
* optimizing for primitive types in animationsChet Haase2010-11-039-428/+730
| | | | | | | | | | | | | | | | | 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
* Performance optimizations for animations and toolkitChet Haase2010-11-013-21/+41
| | | | Change-Id: I316a48273a9cbb428a965e4b849b3e5e9e8202f1
* Use ThreadLocal for static Animator variables.Chet Haase2010-10-271-47/+92
| | | | | | | | | | 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
* Expose (internally only) the number of animations currently running.Brad Fitzpatrick2010-10-221-1/+13
| | | | | | | This will be used for StrictMode to annotate violations with whether or not they janked up an animation. Change-Id: I5bc691f49b74c45279cd2ae044d2a81dcf1204a9
* Optimizing display lists by referencing pointers to resources instead of ↵Chet Haase2010-10-212-2/+2
| | | | | | copying them Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a
* Merge "Remove errant minus sign"Chet Haase2010-10-141-2/+2
|\