c20fc8daf56eb348fa4a9355a9e33b0ebc468699 |
|
19-Jun-2012 |
Luca Zanolin <zano@google.com> |
Clone the list of listeners before notifing any event. This is required, otherwise the listener cannot remove it-self from the list of listeners during the notification. Bug: 6692355 Change-Id: I07762feb4f9b97ec4b6148d2f604d53e266b84d7
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
66ef1a201ea9df71a8ec9b2d1aaab1eb1180ae40 |
|
02-Jun-2012 |
Chet Haase <chet@google.com> |
Skip LayoutTransition animations on objects of size (0,0) LayoutTransition runs changing animations on all objects that change between now and the next layout. This works in most normal situations, but when a container is becoming visible, or being added to its container, or other first-time situations, then some of the views and parent hierarchy may be of size (0,0). The user really shouldn't need to see an animation up from these nonsense values, so we just skip running the animation on these objects and simply place the objects where they need to go. Issue #6597648 view should not animate up from size (0,0) Change-Id: I2c355a68bf1ce3b41fbec01ad95c78d83562ba32
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
ab3a776827365b6bb413052a5e093bbc87265728 |
|
23-May-2012 |
Chet Haase <chet@google.com> |
Avoid running layout transitions on unattached views and windows LayoutTransition causes artifacts in some situations where a window is just becoming visible or a container is just being added to the view tree when animations are kicked off in LayoutTransition due to the normal automatic mechanism of running animations when views are added/removed/etc. The problem is that containers in these situations may have children with positions and sizes of (0, 0), causing the animation to animate from this default/nonsense value to whatever is appropriate for the views when they are first laid out and drawn. The end result is correct, but the animation is superfluous and silly. The fix is to avoid running any kind of transition animation on windows that are not currently visible or containers that are not currently atached to the view hierarchy. This should avoid the situation by only allowing the animations to run after the containers and windows are visible and set up correctly. Issue #6544410 issue with layout transition when first showing the activity Change-Id: I737b2598887ef806dec3b02a483a8e8ff2c3d4e2
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
17cf42cb85c22b50ecfa8d21efc992f99d20fc45 |
|
17-Apr-2012 |
Chet Haase <chet@google.com> |
Fix logic of animator start/cancel/end callbacks The callbacks for animators in some corner cases were not being called correctly. For example, startDelayed animators that were started and then ended didn't send out the proper events. This CL fixes that logic. Specifically: - An animator that is end()'d will implicitly start() itself and then assign an end value. This was already the case, but listeners were not getting notified. Now this situation causes callbacks to listeners for both the start and end events. - startDelayed animators that are end()'d or cancel()'d prior to finishing the startDelay phase will send out events (start and cancel/end, as appropriate) to listeners. Change-Id: I40a0f2fdb19d9ec7c3726a91363686c6ecb7d915
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
7dd4a536a125d5e9573e82c39581bf9ee3922424 |
|
16-Apr-2012 |
Chet Haase <chet@google.com> |
Adding new CHANGING transition to LayoutTransition. LayoutTransition used to depend on child views being added/removed or shown/hidden in the transition container. These evens would trigger animations to fade the child view as well as those to animate the side-affected changes to sibling views. This CL enables a new feature in LayoutTransition that enables animating any changes to the layout of the children in the container whenever a layout occurs. For example, you can change the LayoutParams of a child view and call requestLayout() to automatically animate those changes. This capability is not enabled by default. To enable, call the new LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method. Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
a553113a1f88e112b0999c12c7c2e8d724ed7fa8 |
|
02-Feb-2012 |
Chet Haase <chet@google.com> |
Fix bug in LayoutTransition that caused views to stay invisible 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
0d29936ec3b5545a415e8d032150ea987aab36e3 |
|
26-Jan-2012 |
Chet Haase <chet@google.com> |
Fix bug in LayoutTransition for INVISIBLE views 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
cf06d7390cf35aec4f54b705ba4dfdb96fb1c01a |
|
02-Jan-2012 |
Rajdeep Dua <rajdeep@google.com> |
Bug fix for android.animation.LayoutTransition getStartDelay (int transitionType) Bug Id : 5813366 Change-Id: Icc482ad820a91a1896c61db67bb6b95cc2ae4c5b
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
8a22e59311ab797aeb10682b4c9e036ded95a429 |
|
11-Nov-2011 |
Chet Haase <chet@google.com> |
Fix leak in LayoutTransition 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
1a76dcd6d1e30f92668b5df309398d545cef9ace |
|
06-Oct-2011 |
Chet Haase <chet@google.com> |
Fix issue #5367164: memory leak in LayoutTransition 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
d56c6951755a902a354e13e5fa05fb0984132cc6 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Add end functionality to LayoutTransition This new hidden API is called by ViewRootImpl when there is a pending transition but the parent window is not visible. Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
e115ffeb3a05f440c0062ad9b3954b7fefef4b00 |
|
11-Aug-2011 |
Chet Haase <chet@google.com> |
Fix behavior of custom animations for LayoutTransition. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
abb7d66049c176459779a22810b3931d263f68e6 |
|
18-Jul-2011 |
Chet Haase <chet@google.com> |
Merge "Fixed animation ordering bug in LayoutTransition."
|
eb1d851e0e6c2dc1de0ec7990ccf7d29dda41a9a |
|
18-Jul-2011 |
Chet Haase <chet@google.com> |
Fixed animation ordering bug in LayoutTransition. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
622e05c4d2f7c7542ab9cdd30c31813cb6cdb103 |
|
16-Jul-2011 |
Chet Haase <chet@google.com> |
Fix leak in LayoutTransition 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
cca2c9807206f320bd41bf8656a227e4f249e4ba |
|
20-May-2011 |
Chet Haase <chet@google.com> |
Add ability to transition parent hierarchy in layout transitions 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
c54ed966f78b9ee8117931859d62faa6f11fe018 |
|
06-May-2011 |
Chet Haase <chet@google.com> |
Minor javadoc enhancements Change-Id: Ic24bb0e1e669989f0cae3a9b8fa064b38c8e7948
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
e8e45d32fd1f67fed1b70d0fc19d2f91a76f128e |
|
03-Mar-2011 |
Chet Haase <chet@google.com> |
Cancel LayoutTransition animations selectively 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
add6577a0196258e5a48c5deefcdb12e05c935b3 |
|
10-Feb-2011 |
Chet Haase <chet@google.com> |
Fix animation and layoutTransition issues. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
0dfc39842459daea98e2b551bbecd16d1baca439 |
|
28-Jan-2011 |
Chet Haase <chet@google.com> |
Fixed LayoutTransition bug moving multiple views 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
daf98e941e140e8739458126640183b9f296a2ab |
|
10-Jan-2011 |
Chet Haase <chet@google.com> |
Use optimized display lists for all hwaccelerated rendering 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
9c0874408cfc6f6f4e4561973ca5ae52a5982db7 |
|
13-Jan-2011 |
Chet Haase <chet@google.com> |
Supress layout requests while a LayoutTransition is running. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
2954cd91ab1fef14c8aed5173c160ce00558cd3a |
|
09-Jan-2011 |
Chet Haase <chet@google.com> |
Add start/endTransition events for CHANGE transitions 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
9e90a9953b65ae575ec8db3989857e0c145724b1 |
|
05-Jan-2011 |
Chet Haase <chet@google.com> |
Reuse display lists at the java level. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
cbda9104d029a8420786bd17725e8b1fb0c4c188 |
|
17-Dec-2010 |
Ben Komalo <benkomalo@google.com> |
Fix incorrect anonymous AnimatorListenerAdapter. Change-Id: I0384a437089d11dda03d0657235404ea96e8b19d
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
e64ea87f966e995f5e1a77f991b9da0ed21ffab0 |
|
14-Dec-2010 |
Chet Haase <chet@google.com> |
Fix artifact with concurrent add/remove LayoutTransitions 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
2794eb3b02e2404d453d3ad22a8a85a138130a07 |
|
13-Oct-2010 |
Chet Haase <chet@google.com> |
Remove generics from Animator APIs 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
83d6e8213230fb0805aa019d266842253baeb114 |
|
14-Oct-2010 |
Romain Guy <romainguy@google.com> |
Revert "Remove generics from Animator APIs" This reverts commit 41f041d9986f8a5d45b6cb0b86e881c81a412168.
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
41f041d9986f8a5d45b6cb0b86e881c81a412168 |
|
13-Oct-2010 |
Chet Haase <chet@google.com> |
Remove generics from Animator APIs 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
e0ee2e9f3102c3c14c873a75a7b04e49787e0fb9 |
|
07-Oct-2010 |
Chet Haase <chet@google.com> |
New TimeInterpolator interface for android.animation package. 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
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
5d6d7b9c3d76ba0bf72906d54c2ef366be149a23 |
|
05-Oct-2010 |
Chet Haase <chet@google.com> |
Changed LayoutTransition to disable animations when set to null Change-Id: Ic4d67135a273ea816c3d15bce05da611bd6bae53
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
5e25c2c14593caee5638603120553ae1ec530f85 |
|
16-Sep-2010 |
Chet Haase <chet@google.com> |
Add ability to automate animated transitions on View show/hide Change-Id: Id6ff92c8fd06c3f5fb30c41b020b4de4f567154f
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
634a20acf713ffe0d4a67c0b888cf1e9782890e7 |
|
09-Sep-2010 |
Chet Haase <chet@google.com> |
Fix bug with LayoutTransition when layouts are just coming on line Change-Id: Ia7061d8ec138f8f7aea822596f46b3549a996700
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
a18a86b43e40e3c15dcca0ae0148d641be9b25fe |
|
07-Sep-2010 |
Chet Haase <chet@google.com> |
Rename several animation classes Change-Id: I6a4544875090db485163c8d56de8718f56d267c7
/frameworks/base/core/java/android/animation/LayoutTransition.java
|
21cd1389d2ef218b20994b617c57af120841a57f |
|
02-Sep-2010 |
Chet Haase <chet@google.com> |
Add transition effects for layout changes on ViewGroups Change-Id: Ibefcca5692450188fbcec608f3f7e36be1213b21
/frameworks/base/core/java/android/animation/LayoutTransition.java
|