Significant performance drop in case of rich toolbar layout

[onebone]

Significant performance drop in case of rich toolbar layout

[onebone]

@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 😀

[RareScrap]

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 Modifier.road() and other with Modifier.clickable()

Road() issue

The problem is that Modifier.road() triggers recomposition phase but in fact it affects only layout phase. For now I don't know how to fix this but I guess implementing LayoutModifier might be a started point.

Clickable() strange behavior

In the code above lets look at toolbar composable lambda where MyCollapseAppBar is placed:

MyCollapsedAppBar(
  modifier = Modifier.clickable(onClick = { }), // TODO: Affects performance
  progress = progress,
)

Clickable modifier will trigger recomposition al entire MyCollapsedAppBar each time collapsingToolbarScaffoldState.toolbarState is changed. But there is no any state reader in clickable. But the problem is gone if we move clickable inside MyCollapsedAppBar:

@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 Modifier.road().

I will try to play with collapsing toolbar modifiers but it will very helpful if you share your knowledge about this problems.

[onebone]

Thank you @RareScrap , that would help the library to gain performance a lot! Maybe we can refer to the behavior of lambda version Modifier.graphicsLayer to fix the road modifier issue. For clickable modifier, I will investigate what triggers recomposition.

[onebone]

I have one thing to note here: since Row, Column, Box are inline composable functions, they do not have their own recompose scope meaning that composable lambda passed to these functions will always recompose at the same time with their call sites.

[RareScrap]

I'm happy to report that I have found a way to enormously improve the performance of CollapsingToolbarScaffold (even with disabled AOT). The problem was that SubcomposeLayout executes recomposition phase immediately after the measuring phase which allows measurement results to be used as an argument during recomposition. The implementation of CollapsingToolbarScaffold is not depend on measurement results so using SubcomposeLayout is unnecessary and inefficient here. That's why we can achieve our goal just using Layout. Also modifiers won't trigger recomposition if Layout is used.

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?

[onebone]

Closing the issue with your contribution! Please create another issue if the performance issue seems to persist 😃