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
Bug: 63909536
Bug: 63908092
Test: TODO
If ImageDecoder.decodeDrawable is called with an animated image Source
(currently GIF or WebP), return an object of a new (hidden) Drawable
subclass. The new Drawable animates, and it implements Animatable (TODO:
implement Animatable2) so users have some control over the animation.
In addition to the normal features of Drawable, this new one supports
many of the features of ImageDecoder, including scaling, cropping and
PostProcess, which enables circle masks/rounded corners and other
arbitrary after-effects. It does *not* support decoding directly to a
Hardware Bitmap, since it cycles through frames and reuses the same
bitmap memory. But it could be made to use shared memory (TODO?).
TODO: Use a better number for the native allocation registry
TODO: Use the RenderThread to drive the animation, and remove decoding
on the UI thread.
TODO: Add support for modifying the loop count
Android.bp:
- build new AnimatedImageDrawable.cpp
AndroidRuntime.cpp:
- register new native methods
AnimatedImageDrawable.java
AnimatedImageDrawable.cpp:
- new Drawable that handles animated images
Canvas.h, SkiaCanvas.h/.cpp
- New virtual method and implementation for drawing SkAnimatedImages
RecordingCanvas.h/.cpp
- Stub implementation of drawing SkAnimatedImages
ImageDecoder.h/cpp
- Allow code sharing with AnimatedImageDrawable.cpp
- postProcess
- access the ImageDecoder struct
Depends on https://skia-review.googlesource.com/c/skia/+/94660 in Skia.
Change-Id: Ie2ec98d9c52deda4d439c6ef8e5dea2861bb93a3
Avoid one memcpy in Canvas::drawGlyphs for all pipelines.
Test: CTS passed with exception of SweepTests#testBasicDraws
shadowtext, which fails with and without this CL.
Change-Id: I0841232dc7a6173eb3b03f939dbde15a84186296
The PaintUtils helper is now shared between all pipelines and was
missing a quick reject test for drawLoopers which are used in
view.setShadowLayer and supported in the Skia pipelines.
Bug: 35809097
Test: added hwui unit test and verified in DocumentsUI app
Change-Id: I3c4a988f1c42b7f421f78ac3659af1daee910ea2
This API is difficult to support for printing and has other negative
effects as it does not respect the current matrix/clip.
Test: compile
Bug: 14650725
Change-Id: I71f9bd687d446c7ce8910d755421aad8e09458db
on a per RenderNode basis. With Skia renderer we
see 30% speed improvement in Invalidate Tree UI Jank test,
when SkiaDisplayList objects are reused.
Test: manually built and run on angler-eng.
Change-Id: Ie4ec50ddb2015150e3ec678dde7ebed0c8d90067
bug:30537130
BeginLayerOps were being rejected in a way that allowed the associated
EndLayerOps to still be recorded. This was a violation of DisplayList
content expectations, and caused crashes in FrameBuilder when trying to
play these DisplayLists back.
Change-Id: I531b840aa5c4ffb1ee458da3f4b366978eaeafbe
This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
This CL introduces staging properties to VectorDrawable, which holds
properties coming from UI thread. When staging properties are changed,
they are marked dirty, and the staging properties then get pushed to
RenderThread at sync point. In cases where no staging property has
been changed, at sync point we sync the render thread properties back
to staging properties to reflect the latest render thread animation
value change.
Also, update Vector Drawable bitmap only when it's dirty
Bug: 27343970
Bug: 27385912
Bug: 27263667
Bug: 27927674
Bug: 27774383
Change-Id: Ia864f5400a53a08dbfb284fae581fb1aac4fff87
Fixes: 27825042
TextureView's matrix may not be set at record time - delay using it
until on RenderThread, when deferring the op.
Change-Id: Icf8b55d656e304ec049ca803b042dc2359482db2
bug:27810783
Previous drawColor->drawPaint conversion failed to preserve unbounded
nature of drawColor from old pipeline.
Change-Id: Ifd7a7b9d645f0887e252e48ca95d3195ee31615f
bug:26591194
Also, revert to using current clip bounds as drawColor/drawPaint bounds
for simplicity in new pipeline.
Change-Id: I1a6b3f9716b564b46df41d57dfe14475fdd24de0
bug:27381362
Also rejects ops with empty clip at record time, and short circuits clip
intersection, when one is empty.
Change-Id: I842612da14ad8fd9f1ba5e9e4fd027ba4e08d365
Bug: 27072626
Or at least fix this one and make it harder to leak
going forward. static_asserts are cool, use them liberally
Also makes allocation via LA (slightly) faster by fixing create*
variants to use rvalue references & std::forward, preventing
an accidental pass-by-value
Change-Id: I18fd696a93dd6ea49c8d8c587d4c8bee56dbfdf5
