📝 A Simple Note-Taking App built to demonstrate the use of Modern Android development tools - (Kotlin, Coroutines, State Flow, Hilt-Dependency Injection, Jetpack DataStore, Architecture Components, MVVM, Room, Material Design Components).
Invalidate the software renering bitmap when invalidate is called (#2034)
5.0.2
Bugs Fixed
Prevent a crash when using software rendering before a composition has been set (#2025)
5.0.1
New Features
[Removed API] Removed the setScale(float) APIs from LottieAnimationView and LottieDrawable. The expected behavior was highly ambiguous when paired with other scale types and canvas transformations. For the vast majority of cases, ImageView.ScaleType should be sufficient. For remaining cases, you may apply transformations to Canvas and use LottieDrawable#draw directly.
Added support for the "Rounded Corners" effect on Shape and Rect layers (#1953)
Prior to 5.0, LottieAnimationView would always call setLayerType with either HARDWARE or SOFTWARE. In the hardware case, this would case Android to allocate a dedicated hardware buffer for the animation that had to be uploaded to the GPU separately. In the software case, LottieAnimationView would rely on View's internal drawing cache.
This has a few disadvantages:
The hardware/software distinction happened at the LottieAnimationView level. That means that consumers of LottieDrawable (such as lottie-compose) had no way to
choose a render mode.
Dedicated memory for Lottie was always allocated. In the software case, it would be a bitmap that is the size of the LottieAnimationView and in the hardware case, it was a dedicated hardware layer.
Benefits as a result of this change:
Reduced memory consumption. In the hardware case, no new memory is allocated. In the software case, Lottie will create a bitmap that is the intersection of your View/Composition bounds mapped with the drawing transformation which often yields a surface are that is smaller than the entire LottieAnimationView.
lottie-compose now supports setting a RenderMode.
Custom uses of LottieDrawable now support setting a RenderMode via setRenderMode.
Lottie can now render outside of its composition bounds. To allow this with views such as LottieAnimationView, set clipToCompositionBounds to false on LottieDrawable or LottieAnimationView and clipChildren to false on the parent view. For Compose, use the clipToCompositionBounds parameter.
Prior to 5.0, LottieAnimationView handled all animation controls when the view's visibility or attach state changed. This worked fine for consumers of LottieAnimationView. However, custom uses of LottieDrawable were prone to leaking infinite animators if they did not properly handle cancelling animations correctly. This opens up the possibility for unexpected behavior and increased battery drain. Lottie now behaves more like animated drawables in the platform and moves this logic into the Drawable via its setVisible API. This should lead to no explicit behavior changes if you are using LottieAnimationView. However, if you are using LottieDrawable directly and were explicitly pausing/cancelling animations on lifecycle changes, you may want to cross check your expected behavior with that of LottieDrawable after this update. This change also resolved a long standing bug when Lottie is used in RecyclerViews due to the complex way in which RecyclerView handles View lifecycles (#1495).
#1981
Add an API setClipToCompositionBounds on LottieAnimationView, LottieDrawable, and the LottieAnimation composable to prevent Lottie from clipping animations to the composition bounds.
Add an API to always render dynamically set bitmaps at the original animation bounds. Previously, dynamically set bitmaps would be rendered at their own size anchored to the top left
of the original bitmap. This meant that if you wanted to supply a lower resolution bitmap to save memory, it would render smaller. The default behavior remains the same but you can
enable setMaintainOriginalImageBounds to be able to supply lower resolution bitmaps (#1706).
Add support for LottieProperty.TEXT to use dynamic properties for text. This enables dynamic text support for lottie-compose (#1995).
Invalidate the software renering bitmap when invalidate is called (#2034)
5.0.2
Bugs Fixed
Prevent a crash when using software rendering before a composition has been set (#2025)
5.0.1
New Features
[Removed API] Removed the setScale(float) APIs from LottieAnimationView and LottieDrawable. The expected behavior was highly ambiguous when paired with other scale types and canvas transformations. For the vast majority of cases, ImageView.ScaleType should be sufficient. For remaining cases, you may apply transformations to Canvas and use LottieDrawable#draw directly.
Added support for the "Rounded Corners" effect on Shape and Rect layers (#1953)
Prior to 5.0, LottieAnimationView would always call setLayerType with either HARDWARE or SOFTWARE. In the hardware case, this would case Android to allocate a dedicated hardware buffer for the animation that had to be uploaded to the GPU separately. In the software case, LottieAnimationView would rely on View's internal drawing cache.
This has a few disadvantages:
The hardware/software distinction happened at the LottieAnimationView level. That means that consumers of LottieDrawable (such as lottie-compose) had no way to
choose a render mode.
Dedicated memory for Lottie was always allocated. In the software case, it would be a bitmap that is the size of the LottieAnimationView and in the hardware case, it was a dedicated hardware layer.
Benefits as a result of this change:
Reduced memory consumption. In the hardware case, no new memory is allocated. In the software case, Lottie will create a bitmap that is the intersection of your View/Composition bounds mapped with the drawing transformation which often yields a surface are that is smaller than the entire LottieAnimationView.
lottie-compose now supports setting a RenderMode.
Custom uses of LottieDrawable now support setting a RenderMode via setRenderMode.
Lottie can now render outside of its composition bounds. To allow this with views such as LottieAnimationView, set clipToCompositionBounds to false on LottieDrawable or LottieAnimationView and clipChildren to false on the parent view. For Compose, use the clipToCompositionBounds parameter.
Prior to 5.0, LottieAnimationView handled all animation controls when the view's visibility or attach state changed. This worked fine for consumers of LottieAnimationView. However, custom uses of LottieDrawable were prone to leaking infinite animators if they did not properly handle cancelling animations correctly. This opens up the possibility for unexpected behavior and increased battery drain. Lottie now behaves more like animated drawables in the platform and moves this logic into the Drawable via its setVisible API. This should lead to no explicit behavior changes if you are using LottieAnimationView. However, if you are using LottieDrawable directly and were explicitly pausing/cancelling animations on lifecycle changes, you may want to cross check your expected behavior with that of LottieDrawable after this update. This change also resolved a long standing bug when Lottie is used in RecyclerViews due to the complex way in which RecyclerView handles View lifecycles (#1495).
#1981
Add an API setClipToCompositionBounds on LottieAnimationView, LottieDrawable, and the LottieAnimation composable to prevent Lottie from clipping animations to the composition bounds.
Add an API to always render dynamically set bitmaps at the original animation bounds. Previously, dynamically set bitmaps would be rendered at their own size anchored to the top left
of the original bitmap. This meant that if you wanted to supply a lower resolution bitmap to save memory, it would render smaller. The default behavior remains the same but you can
enable setMaintainOriginalImageBounds to be able to supply lower resolution bitmaps (#1706).
Add support for LottieProperty.TEXT to use dynamic properties for text. This enables dynamic text support for lottie-compose (#1995).
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
dependabot[bot]
commented
2 years ago
Bumps lottie from 4.2.0 to 5.1.1.
Release notes
Sourced from lottie's releases.
... (truncated)
Changelog
Sourced from lottie's changelog.
... (truncated)
Commits
7dfb1f4v5.1.161e8844Clear onVisibleAction once the action is taken (#2066)f0ff8a3Improved docs for gradient parser (#2065)1ddca71Add support for gradient opacity stops (#2062)b2f2161Remove rounding from setMaxFrame (#2064)47745aaMake LottieDrawable.setSystemAnimationsAreEnabled public (#2063)d612830Fix a Xiaomi specific crash (#2061)0f0bc6fFixing memory leak of ShowcaseFragment (#2030)318b8eaFix LottieDrawable#start for non-View callbacks (#2056)bda22a1Fix references to Store in Code of Conduct (#2057)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)