Map initialization with desired configuration is delayed

[bubenheimer]

Setting an initial camera position for the GoogleMap is commonly done by passing an appropriately initialized CameraPositionState parameter to the GoogleMap() Composable.

While reviewing the android-maps-compose code (4.3.0) I noticed that the GoogleMap camera is moved to its initial requested position (via CameraPositionState) only during the (sub-) composition apply phase. I believe this means that the entire initial sub-composition (short of applying) has to complete first. I think this could mean a significant delay in map position initialization, in particular if the sub-composition is fairly sizable.

Delaying map position initialization implies that loading tiles for the desired position is delayed. It would also mean additional visual artifacts, such as missing tiles and visually changing the map center from (0.0, 0.0) to the desired camera location.

From looking at the code I think it would be fairly easy and trouble-free to preempt the delay. The desired position is readily available before initializing the subcomposition and can be set right after awaitMap() has returned.

In terms of correctness, the parent composition would have completed at this point already, so the information from CameraPositionState can be considered valid/committed. I would expect that at this point the MapView would start being rendered, so the initial camera position should be set pronto.

Does this make sense? Looking for feedback.

android-maps-compose/maps-compose/src/main/java/com/google/maps/android/compose/GoogleMap.kt

Lines 158 to 168 in 4b7967d

	private suspend inline fun MapView.newComposition(
	parent: CompositionContext,
	noinline content: @Composable () -> Unit
	): Composition {
	val map = awaitMap()
	return Composition(
	MapApplier(map, this), parent
	).apply {
	setContent(content)
	}
	}

android-maps-compose/maps-compose/src/main/java/com/google/maps/android/compose/GoogleMap.kt

Lines 126 to 129 in 4b7967d

	LaunchedEffect(Unit) {
	disposingComposition {
	mapView.newComposition(parentComposition) {
	MapUpdater(

[bubenheimer]

The delay in setting initial CameraPosition was first introduced in 2237950. Up until then setting the camera was prompt.

I see now that this problem is not just about the camera. There is other critical map configuration from MapProperties that is similarly delayed and could cause temporary visual artifacts, slowness, etc.: contentPadding and various MapProperties such as mapType.

These additional concerns would likely require more substantial changes. Their introduction stems from the same commit.

[mishackee]

Is there some workaround/update for this please? It makes maps in lazy lists quite unappealing.

[bubenheimer]

@mishackee the concern I brought up in this issue is of a more theoretical and architectural nature, I have not quantified it.

Reusing GoogleMap() inside a lazy list is optimized in current android-maps-compose releases to leverage ReusableComposition. As long as your code does not preclude reusing the GoogleMap() things should not be overly slow.

[mishackee]

@bubenheimer Thanks for the prompt response. My bad, sorry, it seems to work in lazy lists once the map is initialized. However, adding it to the composition for the first time, the map is in some initial state and then jumps to my initial CameraPositionState. Is the delay configuration a possible cause of that? And if it is, is there a workaround for that now?

[bubenheimer]

@mishackee thank you for adding this valuable detail. It is the type of behavior I would expect to see with this issue. However, a jump like that could also be caused by initializing CameraPositionState in a suboptimal manner. I am not aware of other reports of jumpy initialization behavior at this time. Can you post excerpts of your code showing how you initialize CameraPositionState and how you pass it into the GoogleMap()? There may be something else delaying CameraPositionState initialization to a later composition.

As for a workaround, the problem should be more tolerable in R8/Proguard-optimized release builds, baseline profiles would likely help as well. See if this takes care of it.

[vijay-shingala]

@bubenheimer hey so I have been having this same issue where on initial load, the map flashes from latlong(0,0) to the request initial position. Wondering if there is a fix for this.

[RotBolt]

I'd like to take this issue.

Proposed scope:

• Apply the initial CameraPositionState.position to GoogleMapOptions before MapView creation.
• Preserve a camera explicitly configured through googleMapOptionsFactory.
• Keep subsequent camera updates on the existing CameraPositionState path.
• Add regression tests covering both default and explicitly configured initial cameras.

This follows the same initialization approach used for mapColorScheme in #976. Please confirm that the proposed precedence is correct before I start implementation.

[RotBolt]

I have raised the PR to fix this issue: #1027