Open bubenheimer opened 8 months ago
I think this issue is caused by rememberUpdatedState()
updating states during composition, not during the apply phase. That's fine for state usage in a normal long-running lambda, but in our case there is a subcomposition in the long-running lambda and this peculiar rememberUpdatedState()
behavior causes snapshot state to get out of whack.
I have a fix for this which I will turn into a PR once my other PRs are merged, to avoid mega merge conflicts.
I've created an issue on the Google issue tracker: https://issuetracker.google.com/issues/322121228
Would be really great if one of the maintainers here could tap internal channels to get it prioritized.
I don't like my "fix", because it significantly delays recomposition of the subcomposition, to the next composition cycle.
android-maps-compose 4.3.0
The GoogleMap() implementation's subcomposition performs excess recompositions. Specifically, starting with the third composition, the subcomposition always performs an additional composition, i.e. it recomposes twice for every change.
I have a separate project replicating the GoogleMap() subcomposition structure to narrow down the issue: https://github.com/bubenheimer/dualsubcomposition
In this minimal project only the top-level subcomposition shows extra recompositions. In the GoogleMap() case, Composable functions beneath the top-level subcomposition also have extra recompositions, depending on what changes are being recomposed.
This is independent of Compose version used, I went all the way back to 1.0.5 for Compose runtime & compiler to see if there was a regression. Current versions are 1.5.6 (compiler), 1.5.4 (runtime). Kotlin version does not matter, either.
I was unable to find an issue reported on this. It would likely be helpful to request external help from Android Compose team.
Code is essentially this:
Output:
The problems starts once the value reaches 2, third composition.
(Example updated to make the intention clear)