-
Notifications
You must be signed in to change notification settings - Fork 1.3k
add FileSource activation/deactivation to MapSnapshotter #10556
Conversation
@@ -135,6 +134,11 @@ public void activate() { | |||
} | |||
|
|||
public void deactivate() { | |||
if (activeCounter == 0) { |
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.
It seems that we should deal with these multiple deactivations at the source (MapSnapshotter). Otherwise, if activate
/ deactivate
is not called in pairs, we have no solid state tracking for the activation state and it could be deactivated before all dependents are actually ready for deactivation.
18873c9
to
f4c4b1d
Compare
@ivovandongen you are correct, was able to find a couple of use-cases were the initial approach would go horribly wrong. Been revisiting activation/deactivation though not very happy with the required changes. The underlying issue is that MapSnapshotter is reusable + it doesn't have a lifecycle (if this was the case we could just hook into the C++ destructor and we would be done). To handle all use-cases "gracefully" with our current exposed API, I moved ref counting code to the C++ side and added ref counting itself to mapsnapshotter (to handle reuse/multiple requests). The edge case I have been focusing on is loading multiple maps with the MapSnapshotter and killing the activity before MapSnapshotter is done:
Do you see a better solution for this issue (with taking semver in account)? |
|
||
if (activationCounter > 0) { |
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 we simplify this to a boolean in the MapSnapshotter? Don't think we need an actual counter in this case right?
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.
This is needed because the MapSnapshotter can be reused for generating mulitple maps. When start is called we increase by one, when we receive a callback we decrease by one here. If the end developer calls into cancel (eg. as part of destroying the activity) we are resetting the counter. A boolean doesn't give us an indication if we have ongoing requests, eg. generating multiple maps in one activity would stop working after generating one bitmap.
platform/android/src/file_source.cpp
Outdated
@@ -63,11 +63,18 @@ void FileSource::setResourceTransform(jni::JNIEnv& env, jni::Object<FileSource:: | |||
} | |||
|
|||
void FileSource::resume(jni::JNIEnv&) { | |||
fileSource->resume(); | |||
counter++; | |||
if (counter==1 && wasPaused) { |
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.
Do we need to check both counter
and wasPaused
? The latter seems redundant.
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.
Also, spaces (==
)
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.
it seems that it's only valid to call resume if the filesource was paused first (else the assertion will fail in core). I reworked the code to use remove wasPaused and wrapped the counter in an optional instead.
platform/android/src/file_source.hpp
Outdated
@@ -54,6 +54,8 @@ class FileSource { | |||
static void registerNative(jni::JNIEnv&); | |||
|
|||
private: | |||
int counter = 0; |
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.
Use a more descriptive name, like activationCounter
you used elsewhere?
@@ -79,16 +83,24 @@ void MapSnapshotter::start(JNIEnv&) { | |||
static auto onSnapshotReady = javaClass.GetMethod<void (jni::Object<MapSnapshot>)>(*_env, "onSnapshotReady"); | |||
javaPeer->Call(*_env, onSnapshotReady, mapSnapshot); | |||
} | |||
activationCounter--; | |||
if(activationCounter==0){ |
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.
Spaces
platform/android/src/file_source.cpp
Outdated
} | ||
|
||
void FileSource::pause(jni::JNIEnv&) { | ||
fileSource->pause(); | ||
counter--; | ||
if (counter==0) { |
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.
spaces
6607bec
to
66e6d4a
Compare
@ivovandongen you were right on the Snapshotter, the counter has been replaced with a bool. |
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.
Looks good 👍
Could you remove the unrelated formatting changes from the PR?
… handle multiple deactivate scenario in FileSource
66e6d4a
to
00795d7
Compare
The unrelated formatting changes have been fixed in 00795d7. Going to merge once CI approves. |
… handle multiple deactivate scenario in FileSource (#10556)
… handle multiple deactivate scenario in FileSource (#10556)
* mapbox_release5.2.1: (29 commits) [android] - update changelog for 5.2.1 release [ios, macos] Rename the iOS and macOS SDKs (mapbox#10610) [core, ios, qt, android] Close race condition in RunLoop (issue mapbox#9620) Because a message we queue from the foreground may cause the background to complete, exit, and tear down the AsyncTask, we have to block queue processing until we've finished our call to AsyncTask::send(). Broadening the scope of a mutex is scary, but I audited the code of our four implementations of AsyncTask and I don't see any way this could cause a deadlock. [android] - add FileSource activation/deactivation to MapSnapshotter, handle multiple deactivate scenario in FileSource (mapbox#10556) [android] - handle destroying activity programmatically as part of theme switching (mapbox#10589) [android] - use concurrent lists for camera change listeners (mapbox#10542) [android] - harden MarkerView integration by checking for null bitmap (mapbox#10532) [android] - activate filesource to list offline regions (mapbox#10531) [android] Enable map rendering when app is paused [ios, macos] Snapshot classes added to jazzy [android] remove unnecessary jar generation from gradle-publish.gradle (mapbox#10625) [ios, macos] Refactor snapshot attribution. [macos] Fixed logo view distortion on macOS High Sierra [ios, macos] Update changelogs. [ios, macos] Fix an issue that triggers didSelectAnnotations for MGLAnnotationImage based annotations. [ios] Fix minimumZoomLevel is not getting set. [android] - attribtuion anchor point calculation fix for short text with full logo on a MapSnapshot (mapbox#10558) [android] use location engine abstraction instead of location source (lost) in MyLocationView#init (mapbox#10579) [build] Added CircleCI macos-release-node{4,6} jobs [android] Set a larger limit for the HTTP dispatcher (mapbox#10567) ... # Conflicts: # platform/android/CHANGELOG.md # platform/android/MapboxGLAndroidSDK/gradle-publish.gradle # platform/android/MapboxGLAndroidSDK/gradle.properties
This PR fixes the bug of the MapSnapshot occasionally not showing up.