| c5eb816f92e81e617cb03d4cdb3805ee084662bd |
|
26-May-2018 |
chaviw <chaviw@google.com> |
Add animation to running animation list before starting.
The animation needs to be added to the animation list before starting
to ensure it's in the list before onAnimationEnd is called. Specifically,
this can happen if the duration is 0 since the animation will complete
very quickly. If that occurs, the animation will be added to the list
after it's been "removed" which means there will continue to be a reference
to that animation even after it's completed.
Also fix a few other issues:
1. Don't create a dim layer if stopDim is called. This causes excess
layers to be created, just so they can be destroyed.
2. Add try/catch to dim layer create so the system doesn't crash if the
layer fails to create.
Test: Enter split screen and move divider so dim layers are show and
hidden. There are no longer excess dim layers being created and leashes
are being properly dereferenced.
Fixes: 80206408
Change-Id: I7198bd5e972fce32633869697a4d26f51e675d48
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| aa763cd35f9a74a93a2fc8cee74e8455e504788e |
|
22-Mar-2018 |
Jorim Jaggi <jjaggi@google.com> |
Early wake-up for transitions (2/2)
On some devices it's very likely that we fall into GL comp during
app transitions. However, SF offsets are chosen in a way such that
the time to finish a frame is just too tight to be completely jank
free when hitting GL composition in SurfaceFlinger. Thus, we
introduce the concept of a separate early offset, and wakeup
SurfaceFlinger at that time if we think that hitting GL comp is
likely, or we already hit GL comp in the last frame.
Test: Open app, check vsync offsets in systrace
Test: Open many dialogs/apps to fall into GPU comp.
Bug: 75985430
Change-Id: I461fdcd573583f3ea0348c8b23cc9945d33f8976
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 4d133725d4b263018555cbba99bb3a2524508707 |
|
09-Feb-2018 |
chaviw <chaviw@google.com> |
Prevent setting negative alpha for dim animations.
When apply in the dim animation is called, the currentPlayTime value can
be greater than the total duration. If that's the case, the alpha
value would be set to a negative value. Instead, if the currentPlayTime is
greater than duration, just set the final alpha value.
Change-Id: I77b7c512cc8832c2a31e20d49c14550da2cff7cd
Fixes: 73152600
Test: No more flashing dim
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| a36dc621ef0b86a0bd46f1d4f5a719a466ba1800 |
|
06-Feb-2018 |
Andreas Gampe <agampe@google.com> |
Frameworks: Annotate trivial @GuardedBy in services/core
Add @GuardedBy for simple functions that require a single lock
and are named XYZLocked.
Derived by errorprone.
Bug: 73000847
Test: m
Test: m javac-check-framework RUN_ERROR_PRONE=true
Change-Id: I6993325b11c71a4ec27c21935fb54a954d95455f
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| d6d971695647e742e24986be396524e8528d2f29 |
|
05-Jan-2018 |
Jorim Jaggi <jjaggi@google.com> |
Make sure app transition are started simultaneously
Test: go/wm-smoke
Test: Lock device in split screen, make sure everything is
absolutely synchronized when unlocking
Bug: 64674361
Change-Id: I25352d7a6b8beb9729310dd525710dca20a78166
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 2d74fafdaf9a5adb74bb336a0052206da629feaa |
|
18-Dec-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix starting of animations
We need to manually process the first animation frame as
mStartTime of ValueAnimator would only be set when processing
the next animation frame.
Test: go/wm-smoke
Test: Add some additional tracing about current playing time and
observe no delay.
Bug: 64674361
Change-Id: Iad753bfb7b86cfd57f265b5084a3d24f967dcaf3
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 32fd84ace1315854b2443ba9c1445837af4bc5eb |
|
20-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free app animations (6/n): Move back-pressure to new animator
SurfaceFlinger was currently only back-pressuring the old
animation system. Move this to the new SurfaceAnimationRunner,
such that every animation frame is presented on screen.
Test: go/wm-smoke
Test: Insert 16ms sleep statement when applying transaction, make
sure animations are still smooth.
Bug:
Change-Id: I510d22c9c4359659e7a061a26b7adad9c265b734
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 2e3c31d0925ecad47e10c7d215b55afd4714b211 |
|
20-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free app animations (5/n): Reimplement skip first frame
Test: go/wm-smoke
Test: Close app, inspect transition with WindowScope, make sure
first frame of animation is skipped
Bug:
Change-Id: I68c135621df47c50696e318c4394da36ce806922
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 980c9de9766668f7d8899067fe34833560197108 |
|
17-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free app animations (3/n): Implement transfering animations
Test: go/wm-smoke
Bug: 64674361
Change-Id: I2170c31c1a95cea049bcc66978bb7737337503b3
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 6c7e56191e7478fb13532dd5133259d449935c7b |
|
12-Dec-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix possible race conditions when cancelling animations
Since the surface is being released by the SurfaceAnimator, it was
possible that SurfaceAnimationRunner was still applying surface
changes on a released surface.
Solve this by introducing a cancel-lock on which all surface
operations are synchronized on.
Bug: 64674361
Test: SurfaceAnimationRunnerTest
Change-Id: I06ee9e8270f492faa1cbfd84a09a68c9a1a09ade
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| a5e105728fb87264b9dc2e66b3703168f8864110 |
|
15-Nov-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free animations (2/2)
Second CL that migrates WSA to use SurfaceAnimator
We start our synchronized app transition journey by showing that
the concept works by using WindowState animations as proof of
concept.
The main class in this CL are SurfaceAnimator and
SurfaceAnimatorRunner. When we start an animation on a Window, we
create a new bufferless surface, called "The Leash", in the
hierarchy and attach the surface of WindowState onto it, while
attaching the leash onto the old surface parent which is still
responsible for z-layering.
Then, we pass off the Leash into SurfaceAnimationRunner, which then
changes the surface properties of Leash in every animation frame,
without holding the WM lock. While it's doing that we can still
update the z-layering of the window, or even relayout the window
of needed - the important surfaces for this are still under WM's
control.
In case the animation is finished the window surface gets
reparented to its original parent, and the leash is abandoned.
Note that the reparenting is done in the same transaction as
processing the animation finish, such that we don't end up with
a flicker in case of a disappearing animation, where the window
surface gets destroyed.
In case the animation needs to be cancelled, WM can revoke control
of the leash by reparenting the window surface. Even if the
cancellation signal is heavily delayed, WM immediately regains
control over the surface by reparenting it within a transaction.
We also introduce the concept of animating a WindowContainer. We
clean up isAnimating:
- isLocalAnimating: is the container itself animating
- isAnimating: is the container or one of its parents animating
- isSelfOrChildAnimating: is local animating or any child
animating.
SurfaceAnimationRunner also needs it's own thread so it's not getting
bogged down by any WM lock contention by processing regular
animation frames. We call that thread android.anim.lf (lockfree).
Now, imagine that SurfaceAnimationAnimator would sit behind an IPC in
another process and instead of animating WindowState, we'd animate
AppWindowToken. Then, synchronized app transitions would be done.
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Test: SurfaceAnimationRunnerTest
Test: WindowContainerTests
Bug: 64674361
Change-Id: Idf59daa90361af57fce1128d19a0c0dbf5971d18
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|
| 21c39a77712d494f0ec8980a39dc99ff98c46c37 |
|
20-Oct-2017 |
Jorim Jaggi <jjaggi@google.com> |
Lock free animations (1/2)
First CL that introduces SurfaceAnimator/LockFreeAnimator
We start our synchronized app transition journey by showing that
the concept works by using WindowState animations as proof of
concept.
The main class in this CL are SurfaceAnimator and
SurfaceAnimatorRunner. When we start an animation on a Window, we
create a new bufferless surface, called "The Leash", in the
hierarchy and attach the surface of WindowState onto it, while
attaching the leash onto the old surface parent which is still
responsible for z-layering.
Then, we pass off the Leash into SurfaceAnimationRunner, which then
changes the surface properties of Leash in every animation frame,
without holding the WM lock. While it's doing that we can still
update the z-layering of the window, or even relayout the window
of needed - the important surfaces for this are still under WM's
control.
In case the animation is finished the window surface gets
reparented to its original parent, and the leash is abandoned.
Note that the reparenting is done in the same transaction as
processing the animation finish, such that we don't end up with
a flicker in case of a disappearing animation, where the window
surface gets destroyed.
In case the animation needs to be cancelled, WM can revoke control
of the leash by reparenting the window surface. Even if the
cancellation signal is heavily delayed, WM immediately regains
control over the surface by reparenting it within a transaction.
We also introduce the concept of animating a WindowContainer. We
clean up isAnimating:
- isLocalAnimating: is the container itself animating
- isAnimating: is the container or one of its parents animating
- isSelfOrChildAnimating: is local animating or any child
animating.
SurfaceAnimationRunner also needs it's own thread so it's not getting
bogged down by any WM lock contention by processing regular
animation frames. We call that thread android.anim.lf (lockfree).
Now, imagine that SurfaceAnimationAnimator would sit behind an IPC in
another process and instead of animating WindowState, we'd animate
AppWindowToken. Then, synchronized app transitions would be done.
Test: go/wm-smoke
Test: SurfaceAnimatorTest
Test: SurfaceAnimationRunnerTest
Test: WindowContainerTests
Bug: 64674361
Change-Id: I10d41f7a289ab2158da3f2f1c3ddd78edd1efc86
Exempt-From-Owner-Approval: Tiny change unrelated to display management.
/frameworks/base/services/core/java/com/android/server/wm/SurfaceAnimationRunner.java
|