material-components / material-components/material-components-android
[MaterialContainerTransform] Poor visual performance on the first run
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 17.4k
- Forks
- 3.2k
- PR merge metrics
- No merged PRs in 30d
Description
**Description:**
Hello! **MaterialContainerTransform** sharedElementEnterTransition is great.
However, I'm experiencing strange visual smoothness issues on the first post-install **MaterialContainerTransform** animations run. These issues are successfully reproduced on both the official "Reply" app sample and on my project.
I'll try to provide all the requested details, that issue is super annoying.
My attempts to detect anomalies via profiler failed. I've found no difference in app workload between laggy and smooth runs.
The issue reproduces only on the first few post-install runs. Consequent cold runs, runs after reboot, and runs in the same process are smooth. Both R8-optimized release and non-optimized debug builds are experiencing the same issue.
**Source code:**
Official "Reply" app experiences the same issue too:
https://github.com/material-components/material-components-android-examples
My snippet:
```
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
exitTransition = MaterialElevationScale(false)
reenterTransition = MaterialElevationScale(true)
sharedElementEnterTransition = MaterialContainerTransform().also {
it.drawingViewId = R.id.mainFragmentContainer
it.duration = Constants.ENTER_TRANSITION_DURATION
it.startShapeAppearanceModel = ShapeAppearanceModel().withCornerSize(
resources
.getDimensionPixelOffset(R.dimen.default_card_corner_radius)
.toFloat()
)
it.endShapeAppearanceModel = ShapeAppearanceModel().withCornerSize(
resources
.getDimensionPixelOffset(R.dimen.default_card_corner_radius)
.toFloat()
)
it.startContainerColor = ContextCompat.getColor(requireContext(), R.color.surfaceColor)
it.endContainerColor = ContextCompat.getColor(requireContext(), R.color.backgroundColor)
}
sharedElementReturnTransition = MaterialContainerTransform().also {
it.drawingViewId = R.id.mainFragmentContainer
it.duration = Constants.EXIT_TRANSITION_DURATION
it.startShapeAppearanceModel = ShapeAppearanceModel().withCornerSize(
resources
.getDimensionPixelOffset(R.dimen.default_card_corner_radius)
.toFloat()
)
it.endShapeAppearanceModel = ShapeAppearanceModel().withCornerSize(
resources
.getDimensionPixelOffset(R.dimen.default_card_corner_radius)
.toFloat()
)
it.startContainerColor = ContextCompat.getColor(requireContext(), R.color.backgroundColor)
it.endContainerColor = ContextCompat.getColor(requireContext(), R.color.surfaceColor)
}
}
```
**Android API version:**
Android 11, API 30
**Material Library version:**
1.2.1, 1.3.0-beta01
**Device:**
Samsung Galaxy S20 Ultra
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the first few post-install runs in the official Reply app sample and with the provided MaterialContainerTransform sharedElementEnterTransition snippet on Android 11. Compare the laggy initial animations with later cold and same-process runs, then trace the MaterialContainerTransform transition path. Done means identifying and resolving the first-run visual smoothness regression with consistent smooth performance across those runs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile-dev, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100