-
Notifications
You must be signed in to change notification settings - Fork 128
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
Unnecessary map initialization performance penalty caused by delaying composing GoogleMap() subcomposition until after GoogleMap object is available #501
Comments
Just as an aside thought, not directly linked to this issue: the initial composition phase of the |
Another element to consider here: MapsInitializer may need to be a part of an app's map initialization pipeline: the |
…ally … (#478) * fix: Use recomposed map listener callbacks rather than only the initially composed version Fixes #466 * Minor formatting fix * Label leaf composable as @GoogleMapComposable for proper compile-time diagnostics * Clarify documentation * Address spurious subcomposition recompositions by delaying state updates to after parent composition, not during parent composition * Delay GoogleMap object access until composition apply phase (see #501) * Revert "Address spurious subcomposition recompositions by delaying state updates to after parent composition, not during parent composition" This reverts commit dff2b0a.
@wangela Just FYI: the 4.3.3 release says that it fixes this issue, but that is not the case. I think this mixup happened because I mentioned this issue in one of the commits for 4.3.3 ("see #501", I was not aware that this has "fixes" semantics, maybe some problem with release automation, or maybe I shouldn't do this in commit messages?). |
@bubenheimer Where are you seeing that the release says it fixes this issue 501? I only see it mentioning that it fixes issue 466 which was tagged intentionally on your PR number 478. |
Strange, may be human error. I've deleted that mention from the release notes. |
I've added two related issues on the Google issue tracker: https://issuetracker.google.com/issues/340494390 |
android-maps-compose 4.3.0
From code inspection I've noticed that there is an undue performance penalty caused by delaying the
GoogleMap()
subcomposition until after theGoogleMap
object has been made available via suspendingMapView.awaitMap()
.While the
GoogleMap
object is required during the "apply changes" phase of the subcomposition, it should not be required to perform the initial composition of the subcomposition, prior to "apply changes".Initial composition phase of subcomposition and
MapView.awaitMap()
should and can be performed in parallel.The text was updated successfully, but these errors were encountered: