-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Remove black surface during map start up #12377
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really satisfied with current exposed naming of loadColor
, looking for alternatives
edit: went with foregroundLoadColor
instead.
e418a99
to
97fdde8
Compare
6eb9e10
to
c681f0c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Been trying out a couple of configurations (different map change events) to see if we can remove the black surface as seen on some lower end devices. Hooking into |
@LukasPaczos would you be able to re-review? I took a different approach in 3dc0365 |
|
||
@Override | ||
public void onMapChanged(int change) { | ||
if (change == MapView.DID_FINISH_RENDERING_FRAME) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is a typo here. As you mentioned, MapView#DID_FINISH_RENDERING_FRAME_FULLY_RENDERED
works as expected, but MapView#DID_FINISH_RENDERING_FRAME
doesn't resolve the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forgot to document my follow up findings:
I found that MapView#DID_FINISH_RENDERING_FRAME_FULLY_RENDERED
was taking a long time to show the map to the end user. Before core emits that event we receive multiple MapView#DID_FINISH_RENDERING_FRAME
with every render invocation we render a bit more content overtime. First time we render the black surface, second time we render the background (this is why there is a counter there). Feel free to play around this yourself but I feel this was providing a better UX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check out the following setup in the MapboxMap#onStart
that imitates bad connection:
void onStart() {
nativeMapView.update();
if (TextUtils.isEmpty(nativeMapView.getStyleUrl()) && TextUtils.isEmpty(nativeMapView.getStyleJson())) {
// if user hasn't loaded a Style yet
new Handler().postDelayed(() -> nativeMapView.setStyleUrl(Style.MAPBOX_STREETS), 2000L);
}
}
Waiting for MapView#DID_FINISH_RENDERING_FRAME_FULLY_RENDERED
here does the job well, but if you feel like it's too long, maybe you could wait for the style to load and then wait for those 2 frames to be partially rendered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for testing and catching that use-case! I implemented the latter suggestion and I feel it's working great for normal usage as for this specific case. LMK what you think.
f156605
to
3e48765
Compare
…ap to the end-user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Can you do the same thing when the map gets destroyed ? I don't see the black screen on start up anymore but do every time when switching to the next fragments in a view pager. |
Closes #10990, this PR exposes a color int configuration on MapboxMapOptions that is used as foreground color during map startup. Only when the style has loaded, we will show the render surface. This results in removing the black flash as shown in #10990.