-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Significant performance drop in case of rich toolbar layout #23
Comments
I have found a way to speed up this layout more than 60%. Thanks to this doc. Passing progress as a lambda makes re-execute only layout and draw phases of Compose rather than trigger recomposition: toolbar = {
val progress = { collapsingToolbarScaffoldState.toolbarState.progress }
// ...
}, I think we should implement an example screen with demonstration of this concept. It will be useful for creating complex toolbars. But there are still two problems: one with Road() issueThe problem is that Clickable() strange behaviorIn the code above lets look at toolbar composable lambda where MyCollapsedAppBar(
modifier = Modifier.clickable(onClick = { }), // TODO: Affects performance
progress = progress,
)
@Composable
private fun MyCollapsedAppBar(
modifier: Modifier = Modifier,
onClick: () -> Unit,
@FloatRange(from = 0.0, to = 1.0) progress: Float,
) {
// ...
MyAppBar(
modifier = Modifier.clickable(onClick = onClick), // Now MyCollapsedAppBar won't recomposing
title = {
Log.d("redraw", "collapsed bar title redrawing")
Text(
modifier = Modifier.alpha(progress),
text = "Collapsed app bar",
color = MaterialTheme.colors.onPrimary
)
}
)
// ...
} For now I can't explain how it works. Maybe you can? It should be noted that this trick not work with I will try to play with collapsing toolbar modifiers but it will very helpful if you share your knowledge about this problems. |
Thank you @RareScrap , that would help the library to gain performance a lot! Maybe we can refer to the behavior of lambda version |
I have one thing to note here: since |
I'm happy to report that I have found a way to enormously improve the performance of I also want to implement an example activity with rich toolbar layout and create choosing page which allow to run different examples without manifest editing. What are you think? |
@RareScrap Thank you! I will review your PR this weekend. And it would be very nice to see the new example screen! If you are going to refactor examples please submit a separate PR 😀 |
Closing the issue with your contribution! Please create another issue if the performance issue seems to persist 😃 |
My toolbar contains pretty large numbers of elements so its performance is especially important for me. Here is my toolbar:
In action it looks like this:
On the GIF you can see performance drop when scroll occur. It's important to node that the GIF is not compressed.
Here is the code of my toolbar layout:
I added some logs to figure out what parts of UI affected by recomposition. It turned out that they all were affected after any change in the toolbar state. Even if I remove alpha modifier the recomposition process still affect all toolbar composables. I think this behaviour directly contradicts the basic principle of Compose - doing recomposition only if state of composable has changed
In my case there is no need to recompose toolbars (only they titles). So there must a way not to trigger recomposition of all tolbar content
I'm still in research of this problem. But it's important to discuss this problem.
The text was updated successfully, but these errors were encountered: