commit 3b5387ab6a95e59f6c3f44ba9fd97c986982b33e
author Gabriel Peal <gpeal@users.noreply.github.com> Fri Dec 10 11:38:52 2021 -0800
committer GitHub <noreply@github.com> Fri Dec 10 11:38:52 2021 -0800
tree e20b77b0e35f67ccca8db2e31595c6365d064c5a
parent 6d8fd33a1c992d073c14d6e0d632fe5c8b67836c

Replace LottieAnimationView layer types with internal bitmap rendering (#1952)

This change marks a significant change in the underlying rendering pipeline for Lottie.

Previously, Lottie would always set a layerType on LottieAnimationView. For hardware accelerated animations, this meant that a separate graphics layer was allocated for the animation. The disadvantage with this method is that the texture has to be uploaded separately to the GPU on each frame.

For software rendering, Lottie would depend on Android's view caching mechanism in which View allocates a drawing cache bitmap which it then draws to a canvas. This has the disadvantage of the Bitmap always being the size of the containing View even if it's larger than the drawable.
It also abstracts away the Bitmap so that further optimizations. When software rendering is enabled and it has to be redrawn without getting invalidated then it can skip re-rendering and simply redraw the cached bitmap.
It also upstream the bitmap rendering form LottieAnimationView to LottieDrawable which allows it to be exposed to lottie-compose which is important for the same reasons it is important for the base library and wasn't possible before.

While working on this PR, I tried rendering and then drawing only the bounds of the animation. However, I found that calculating the bounds for the entire animation was slower than drawing the entire bitmap (which is very fast).

Fixes #1387