History log of /frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
4afdd1caa4ff5f0890c3f4d73c6d475f9e06cefd 14-May-2018 Leon Scroggins III <scroggo@google.com> AnimatedImageDrawable: Eliminate unnecessary calls to redraw

Bug: 78866720
Test: Manual + systrace; existing CTS

Previously, we set hasAnimations to true when the AnimatedImageDrawable,
so that we would get a call to redraw. But if the image does not need to
show its next frame yet, the redraw was unnecessary.

Instead, add a new field to TreeInfo::Out, representing the delay time
until the image will need to be redrawn - i.e. when the duration of the
current frame has passed. Each call to prepareTree will post at most one
message to redraw, in time for the earliest animated image to be
redrawn. Post the message for one rendered frame ahead of time, so that
when it is time to show the next frame, the image has already gotten the
message to update.

On a screen with a single animated image, this drops the number of calls
to dispatchFrameCallbacks to as infrequent as possible. It is called
only when we need to draw a new frame of the image. On a screen with
multiple animated images, the calls may be redundant, but they will not
be more frequent than they would be without this change.

Switch to nsecs_t and systemTime internally, matching the rest of HWUI.

Remove mDidDraw and related. Its purpose was to prevent advancing the
animation while the image is not being drawn. But it isn't really
necessary. If it's not drawn, onDraw is not called, which is where we
trigger decoding. And onDraw already has a defense against getting too
far ahead - if its timer indicates that it should skip a frame or show
it very briefly, it will back up its timer. More importantly, mDidDraw
caused a bug, when combined with less frequent redraws. If the display
list containing the drawable doesn't need to be redrawn for other
reasons, the drawable's timer never advanced, so its animation stopped.

Fix software drawing. Compute the milliseconds in the future to draw the
next frame, and add that to SystemClock.uptimeMillis() to compute the
time to pass to scheduleSelf.

Change-Id: I13aab49922fa300f73b327be25561d7120c09ec4
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
eb3b38e22cb29c6a7fccb7031263f50663cc76d0 20-Mar-2018 Leon Scroggins III <scroggo@google.com> Report native allocation size of AnimatedImageDrawable

Bug: 73641604
Test: infeasible

Fix nNativeByteSize's return value to be jlong, instead of long.
Add up the bytes used by the SkAnimatedImage and SkPictures and store
them on the AnimatedImageDrawable for registration.
Note that this is an approximation, and it assumes it will be drawn to a
hardware canvas and animated.
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
5e8447f74dd371bd6e3079c126eff1d5c3df2e4b 05-Mar-2018 Leon Scroggins III <scroggo@google.com> Draw AnimatedImageDrawable mirrored if desired

Bug: 73529437
Test: I27af7c3b2e08fa50bc19e08930d970931ce4b5e9

If isAutoMirrored, and the layout direction is RTL, make
AnimatedImageDrawable draw flipped.

Change-Id: I9a3436ef4cb9df2845a67663a2503c2c1a3dba89
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
d935157f48525d5fe7cc107c2d7aed99564b60bd 06-Feb-2018 Leon Scroggins III <scroggo@google.com> Fix AnimatedImageDrawable drawn in software

Test: Manual, existing CTS, I4e884636801c0a2e920ca9d99f3c38fb034b3774

- Fix a bug where the animation never advanced.
- Rename mFinished to mStarting. It was already being used to indicate
that we were restarting anyway. Now only set it to true in calls to
start().
- Prevent skipping ahead the same way we do in hardware.
- Return kFinished when reaching the last frame of the animation.

This also includes a fix for hardware drawing. The first time start() is
called, there is no need to create a snapshot of the first frame. Just
draw the first frame directly and kick off a decode of the second frame.

Change-Id: I0a6fb909a361dd4c233cfa2d79bc2210d2dcddc8
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
beaf5d919fa7986b96968d2282458aca9dc05b13 26-Jan-2018 Leon Scroggins III <scroggo@google.com> Fixes for animationEnd in AnimatedImageDrawable

Bug: 63908092
Test: Manual

If the animation is running on the render thread, post a message (in
JNI) to call the listener.

Use a weak reference in the native listener so that it does not create
a cycle.

Don't add a listener if it's already in the list. Remove the native
listener when the Java listeners are all removed.

Call onAnimationEnd when the animation is stopped manually.

Change-Id: I5dc070089fb1cf399ac3316292592f614f2738f0
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
1996dbb19cd43d0ffa034cafe460fe27342e584e 30-Jan-2018 Leon Scroggins III <scroggo@google.com> Make AnimatedImageDrawable.start reset

Bug: b/63908092
Test: Manual: Ie18811ba29a1db163aca08472b04ae185e9344f0

If the animation has already started and stopped (via stop()), restart
the animatino on a call to start().

Change-Id: I0a14a1e643f32469fe5519949ee8ef046107e9a8
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
5b7f426ff04820f81877ccb696bf6245dede89e7 26-Jan-2018 Leon Scroggins III <scroggo@google.com> Use a separate thread to decode AnimatedImageDrawable

Bug: 63908092
Test: Manual: Ie18811ba29a1db163aca08472b04ae185e9344f0

Depends on https://skia-review.googlesource.com/#/c/skia/+/101544. That
change removes the Skia class's time checks, and leaving it up to the
client to keep track of the time. In this case, the client wants to keep
track of the time because it only wants to update while it is being
drawn. If it goes off screen (for example), it will just resume where it
left off when it returns on screen. This allows for smooth animations.

If an AnimatedImageDrawable is being drawn to a SkiaRecordingCanvas,
decode on the new (lazily-created) AnimatedImageThread.

When running, always decode one frame ahead on the AnimatedImageThread
so that it will be ready when it is time to display.

During prepareTree, update the time and check whether there is a new
frame ready to draw or the next frame needs to be decoded. In either
case, return true. The next frame to be decoded will be triggered by
onDraw.

Change-Id: If447976e9df417060a950f658dbca9cf7980dd02
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
057c91a20dda36776b7f0bfc60bfce4331d83ab5 24-Jan-2018 Leon Scroggins III <scroggo@google.com> Fix start/pause behavior for AnimatedImageDrawable

Bug: 63908092
Test: HwAccelerationTests

Do not start the animation at creation time

When starting, first update the time, so it doesn't think we skipped a
bunch of frames if we're resuming.

Continue storing the SkPicture when stopped, so that we can continue to
show the same frame, without a jump.

Change-Id: I5ac77f2561fc9f42f8f69ebfbee21fe647cfc75a
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp
2d14213849d6df70d0fa80319ab4ffc08743a683 22-Jan-2018 Derek Sollenberger <djsollen@google.com> Initial implmentation of AnimatedImageDrawables on the RenderThread.

The current implementation schedules the next frame of the images
to be decoded after the current frame completes but potentially
schedules tasks that will result in a no-op execution if a new
frame is not yet needed.

Test: HwAccelerationTest
Change-Id: I0510cb5a1b801abd651327e924deb586af0306d6
/frameworks/base/libs/hwui/hwui/AnimatedImageDrawable.cpp