Duration scale based on screen size was using the area of the screen
excluding system bars to compare with our reference device's screen
size. This caused the following issues:
1) On baseline device (i.e N5) a scaling factor that is not 1 will be
applied to the duration.
2) Scaling on the same device will be different in landscape vs.
portrait, as the system bars take different amounts of space in
different orienations.
This CL fixes both of the above issues.
Bug: 20309042
Change-Id: I9d1d0a471d968bee1330b80f0f69a0066d6a1860
In order to preserve the same look and feel of an animation across different
devices, we need to maintain the same angular velocity for the animation in
users' field of view. Since the animation path may span different angles on
different devices, we need to therefore adjust the duration accordingly.
Change-Id: Ia37f213e5a894a046edbb1a45a4ced04e406d85d
The Choreographer carefully schedules animation updates to occur
after input but before traversals occur. This ensures that the
effects of animations are perceived immediately in the next frame.
The start time of animation is usually set the moment the animator
first runs. The start time serves as a reference for timing the
remainder of the animation.
Setting the start time during the animation callback works well except
when traversals take a long time to complete. In that case, we may
end up drawing the initial frame of the animation then skipping several
following frames (because a lot of time has already passed since the
animation start time was set), effectively shortening the duration
of the animation.
To resolve this issue, we introduce a new COMMIT phase within the
Choreographer. The COMMIT callback runs after traversals complete
and may provide an updated frame time that more accurately reflects
the time when the frame finished drawing.
In the case where an animation is just starting, we note the fact
that its initial start time has not yet been committed (the user
hasn't actually seen anything on screen yet). Then, during the
COMMIT phase, we adjust the animation start time to better reflect
the time when the animation's first frame was drawn, effectively
causing the animation actually start after the expensive traversal
operations occurred such that no frames will be skipped.
Bug: 17258911
Change-Id: I279603d01fd4ed1de8f51a77c62f4fec5e9b746a
Support different interpolators on every keyframe by running
interpolators on proportional duration instead of raw fraction.
Bug: 19928396
Change-Id: Ifb8c3a3b56785582cd6b0121d7bfb44534866300
A recent change to ValueAnimator caused infinitely repeating animators with
duration 0 to be ended immediately. BatterySaver mode can cause animators
to have 0 duration, which means that apps depending on animator update events
no longer receive those events due to this behavior change.
The fix is to restore the previous behavior of allowing repeating animators
to continue, regardless of duration.
Issue #19113776 Fix infinite-repeating, zero-duration animator behavior
Change-Id: I4d1c7afb6d06ca45ef41db73c160f6a6d5754e24
A recent fix to seeking behavior injected a couple of issues that need
to be addressed:
- the start time should be updated when seeking so that future calculations
that depend on it (such as the next animation frame) will use the updated
start time based on this seek request. This allows, for example, seeking
into a running animator so that that animator will update its current fraction
to the new seeked value.
- calling reverse() on an unstarted animation would incorrectly set the initial
frame of the animation to the end value for one frame before the reverse animation
actually began.
Issue #18567716 No icons in folders in battery saving mode
Issue #18511989 Search bar flashes when icon is picked up and dropped
Change-Id: Ie30b7e797468c6ccb3d17d4fb3aba6b9849436b0
A recent change to seeking behavior altered the logic of
setCurrentPlayTime() (which is called when animations are first
started) to set the current animated fraction to 0 for 0-duration
animations. This fix ensures that 0-duration animations snap to
their end value (fraction == 1) instead, matching the behavior
prior to the seeking fix.
Issue #18542543 Animations with 0 duration stay in initial state when calling setCurrentPlayTime(0)
Change-Id: I9916d962cf46453a9e3e1207f58baf16f4a5830a
The animation scaled was not being factored in early enough in the
activity lifecycle. Also, setCurrentPlaytTime() was not accounting for
the scaled duration correctly. Finally, added setCurrentFraction() as
a more general-purpose seeking facility.
Issue #18222006 Animator duration scale ignored in some situations
Issue #17951668 add ability to seek fraction, not just time
Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
Bug 17978210
When Properties are used with PropertyValuesHolders or
ObjectAnimators, the reflection lookup for getters and
setters is unnecessary.
Fixed problem in which static maps were being protected
by instance locks.
Fixed problem where we were repeatedly doing a
reflection lookup on methods that don't exist.
Change-Id: Ic0a1b62357f3aaaa4c900fef6087583ad0e964b6
For now, only animators use it but we can consider migrating
drawable cache to it as well.
Bug: 17456416
Change-Id: I571b96856805edb171f0fc52e6bff5a365f46b70
When Battery Saver mode is enabled, we set the animation duration
scale factor to 0 to effectively disable all animations. Later
when it is disabled, we reset the animation duration scale
factor to 1.
This change ensures that we reapply the duration scale factor
whenever the animation is started instead of only applying it
once when the duration is set (usually when the animation is
created). This ensures that the correct scale factor is applied
even when it changes after the animation has been initialized.
Previously, certain animations would continue to be suppressed
even after Battery Saver mode was disengaged. This wasn't much
of an issue when the duration scale was initially implemented as
a developer setting but now that it is exposed via Battery Saver
the artifacts caused by this bug have become visible to users.
Bug: 17887431
Change-Id: I91ba5ca0505d02ac389a31d067e38886112fa0c8
Complex animated vector drawables can be expensive to load due to
sub-optimal parsing of the String-based pathData. Suffering that penalty
every time the same drawable is loaded (such as material-themed
ProgressBars) is painful.
The new approach caches constant state of both the VectorDrawable (including
the pathData geometry) and the animators (which includes potentially expensive
path-based interpolators).
issue #17366831 Material ProgressBar taking 200+ms to inflate
Change-Id: Iba3b541e24cfce8c07f5aa9fe6aa7d7b92b2fe1c
Bug 16984007
Animated Vector Drawables were using the viewport dimensions for
calculating the allowable animation error. Instead of using viewport
dimensions, it is better to use the intrinsic dimensions. Using
the viewport dimensions meant that a small viewport (e.g. 1x1)
would mean that animation paths within would only have an accuracy
of 50% of the dimensions of the drawable.
Change-Id: Id0152eabb4effd1e50c644eea7a371b38baeb7c1
Bug: 17317184
Unfortunately this will disable *all* RT animations in a scene,
but we don't have more selective targetting currently
Change-Id: I57e1c0ae43957f45229473bdcdaf34c05825fab7
Bug: 16161431
Also re-writes RevealAnimator to avoid using any listeners internally,
removing the logic around shadowing the update listeners.
Change-Id: I6ed8126398eed971a87f20bccb7584c9acafbb6c
This avoids NullPointerException crash when changing values without
first canceling a running animator.
Issue #16245303 KeyframeSet crash on null keyframe or evaluator
Change-Id: I50ce5223310fe87e3382c446e2d36d93ae38a8fe
Basically extended the ValueAnimator to support a new type: pathType.
Add the PathDataEvaluator internally to interpolate path data.
Update test to show the path morphing.
Change-Id: I89db0199cbc12e3041790a6115f3f50b80213cdb
