Custom Vector Source (n+1) #9983

asheemmamoowala · 2017-09-12T23:28:58Z

Follow up to #8473 rebased on master and updated for Async Render and other changes.

TODO:

asheemmamoowala · 2017-10-04T16:43:33Z

Using the Actor model to enable asynchronous communication to the RenderCustomVectorSource.

To request data

CustomTile is initialized with an actor reference to a CustomTileLoader
CustomTile invokes CustomTileLoader::fetchTile with an actor-ref to CustomTile::setTileData
fetchTile is forwarded to the user-provided function to CustomVectorSource

To set data

user-provided function calls CustomVectorSource::setTileData
CustomTileLoader::setTileData invokes CustomTile::setTileData

CustomTileLoader helps track the actor-refs to the tiles so that the platform bindings don't have to.

ivovandongen · 2017-10-05T11:55:32Z

@asheemmamoowala Looking good!

The only thing I'm wondering is wether we can skip going back over the main thread to set the tile data through CustomSource::setTileData. I understand hiding the management of the Actor references. However, the providing the actor reference to the tile directly and calling that from the tile fetching operation (b591ed6#diff-83e9a6627797d3a9645fe63cf48f4102R84) might be more efficient? The actor reference itself makes it safe to call from multiple threads, even if the underlying Tile is already gone.

That said, I'm not sure how much overhead orchestrating the tile data setters on the main thread has to begin with.

asheemmamoowala · 2017-10-05T15:16:13Z

@ivovandongen - I wondered about that as well . Given that each tile request results in its own operation in the platform binding - it would take away the need for managing all the tile actors in CustomTileLoader.
Will give it a try

asheemmamoowala · 2017-10-05T21:08:10Z

@ivovandongen - having worked on your suggestion, I remembered setting it up through CustomVectorSource::setTileData so that the tile can be updated at any time after it is created. This prevents the client from having to hang on to the ActorRef<> for each tile and removes the need to ask if a tile needs an update before each frame.

ivovandongen

Some small formatting issues

ivovandongen · 2017-10-17T23:02:03Z

src/mbgl/style/custom_tile_loader.cpp

+        auto tuple = std::make_tuple(tileID.overscaledZ, tileID.wrap, callbackRef);
+        tileCallbackMap.insert({ tileID.canonical, std::vector<OverscaledIDFunctionTuple>(1, tuple) });
+    }
+    else {


ivovandongen · 2017-10-17T23:02:18Z

src/mbgl/style/custom_tile_loader.cpp

+        tileCallbackMap.insert({ tileID.canonical, std::vector<OverscaledIDFunctionTuple>(1, tuple) });
+    }
+    else {
+        for(auto iter = tileCallbacks->second.begin(); iter != tileCallbacks->second.end(); iter++) {


space after for

ivovandongen · 2017-10-17T23:02:27Z

src/mbgl/style/custom_tile_loader.cpp

+    }
+    else {
+        for(auto iter = tileCallbacks->second.begin(); iter != tileCallbacks->second.end(); iter++) {
+            if(std::get<0>(*iter) == tileID.overscaledZ && std::get<1>(*iter) == tileID.wrap ) {


space after if

ivovandongen · 2017-10-17T23:02:48Z

src/mbgl/style/custom_tile_loader.cpp

+}
+
+void CustomTileLoader::cancelTile(const OverscaledTileID& tileID) {
+    if(tileCallbackMap.find(tileID.canonical) != tileCallbackMap.end()) {


space after if

ivovandongen · 2017-10-17T23:03:00Z

src/mbgl/style/custom_tile_loader.cpp

+void CustomTileLoader::removeTile(const OverscaledTileID& tileID) {
+    auto tileCallbacks = tileCallbackMap.find(tileID.canonical);
+    if (tileCallbacks == tileCallbackMap.end()) return;
+    for(auto iter = tileCallbacks->second.begin(); iter != tileCallbacks->second.end(); iter++) {


space after for

ivovandongen · 2017-10-17T23:03:12Z

src/mbgl/style/custom_tile_loader.cpp

+    auto tileCallbacks = tileCallbackMap.find(tileID.canonical);
+    if (tileCallbacks == tileCallbackMap.end()) return;
+    for(auto iter = tileCallbacks->second.begin(); iter != tileCallbacks->second.end(); iter++) {
+        if(std::get<0>(*iter) == tileID.overscaledZ && std::get<1>(*iter) == tileID.wrap ) {


space after if

ivovandongen · 2017-10-17T23:03:26Z

src/mbgl/style/custom_tile_loader.cpp

+    auto iter = tileCallbackMap.find(tileID);
+    if (iter == tileCallbackMap.end()) return;
+    dataCache[tileID] = std::make_unique<mapbox::geojson::geojson>(std::move(data));
+    for(auto tuple : iter->second) {


space after for

ivovandongen · 2017-10-17T23:07:38Z

src/mbgl/tile/custom_tile.cpp

+        necessity = newNecessity;
+        if (necessity == Necessity::Required) {
+            loader.invoke(&style::CustomTileLoader::fetchTile, id, actor.self());
+        } else if(!isRenderable()) {


space after if

1ec5 · 2017-10-26T16:27:52Z

platform/darwin/src/MGLShapeSource.h

@@ -111,7 +45,7 @@ extern MGL_EXPORT const MGLShapeSourceOption MGLShapeSourceOptionSimplificationT
 ```
 */
 MGL_EXPORT
-@interface MGLShapeSource : MGLSource
+@interface MGLShapeSource : MGLAbstractShapeSource


This PR is scheduled to land in iOS SDK v4.0.0, which allows backwards-incompatible changes. That means we can revisit the taxonomy proposed in #6940 (comment). Specifically, we have the opportunity to choose a name for MGLAbstractShapeSource that doesn’t contain the word “abstract” and rename the MGLShapeSourceOptions to align with whatever class they’re used with. Any ideas?

How about a single MGLShapeSource with a data source that provides either tiled or non-tiled data. It would combine the existing MGLShapeSource and MGLProgrammaticShapeSource.
I don't have a good idea of what the peer Source class for a GeoJSON source would be in this scenario - maybe it makes room for an actual MGLGeoJSONSource, but I suspect that was removed earlier for some very valid argument.

I like this idea – would we combine GeoJSONSource and CustomSource into a single class to facilitate this simplification?

That may be a future state, where GeoJSONSource is rebuilt on top of CustomVectorSource, but its not in the current plan

I suppose that means MGLShapeSource would need to hold a variant<GeoJSONSource, CustomSource>? More reason to rename CustomSource to something more descriptive…

Landed on using CustomGeometrySource in core and android to match other uses of custom.

1ec5 · 2017-10-26T16:28:26Z

platform/macos/CHANGELOG.md

+* Deprecated `+[MGLStyle trafficDayStyleURL]` and `+[MGLStyle trafficNightStyleURL]` with no replacement method. To use the Traffic Day and Traffic Night styles going forward, we recommend that you use the underlying URL. ([#9918](https://github.com/mapbox/mapbox-gl-native/pull/9918))
+* Fixed an issue where stale (but still valid) map data could be ignored in offline mode. ([#10012](https://github.com/mapbox/mapbox-gl-native/pull/10012))
+
+## 0.5.0


This looks like a bad merge.

asheemmamoowala · 2017-11-02T00:25:17Z

Alll planned work for this PR is complete. Here's a recap of what's changed:

Core

CustomGeometrySource is a new source type that accepts callbacks for fetching and canceling tiles. Both callbacks will be called from worker threads, not the main thread; thus preventing the main thread bandwidth from hampering fetching of tiles. @ivovandongen, this addresses your earlier comment.

CustomGeometrySource::setTileData(CanonicalTileID, GeoJSON) with the clipped and zoom-appropriate geometry for that tile. This method can be called from the main thread or a worker thread.
CustomGeometrySource::invalidateTile(CanonicalTileID): invalidates a specific tile.
CustomGeometrySource::invalidateBounds(LatLngBounds): invalidates all tiles that occupy the given bounds at all zoom levels. tileCover turned out to be inappropriate to compute the list of tiles affected as it needed to run at every zoom level. Instead, the existing cached tiles are compared to the provided bounds for an intersection, containment, or overlap.
CustomTileLoader manages requests from tiles. It maintains a cache of tile data set via CustomGeometrySource::setTileData(..) so as to avoid repeated calls for the same tile for wrapped or over-zoomed tiles.

iOS, macOS

MGLComputedShapeSource, a wrapper for the core source type, accepts an MGLComputedShapeSourceDataSource, which is responsible for providing the tile data. The data source methods will be invoked on worker threads, not the main thread.

Android

CustomGeometrySource, a wrapper for core source type, accepts a GeometryTileProvider which is responsible for providing the tile data. The tile provider method(s) will be invoked on worker threads, not the main thread.

Node, Qt

N/A

Synchronization

CustomTileLoader runs on a shared thread pool, and all invocations to it are via actors. This includes API requests from CustomGeometrySource and data requests from CustomGeometryTile.
In the SDK bindings, fetchTile requests are queued and executed on worker threads using NSOperationQueue, and ThreadPoolExecutor in iOS/macOS and Android respectively.

Tail work

[android] Factor out CancellableThreadPool from CustomGeometrySource.
[android] Expose CanonicalTileID type and tile id based GeometryTileProvider and CustomGeometrySouce methods(GeometryTileProvider should allow tile-id based callback methods #10495)
[ios, macos] Rename MGLAbstractShapeSource and related types to take advantage of upcoming API-breaking release (Simplify and consolidate Shape sources #10410)

Future Work

[core] Reuse canonical tiles in TilePyramid instead of a separate cache in CustomTileLoader (Reuse CanonicalTile in TilePyramid #10258).
[core] Support data in tile coordinates in addition to geographic coordinates (CustomGeometrySource should support data in tile coordinates #10494).

/cc @jfirebaugh @tobrun @ivovandongen @kkaefer @1ec5

1ec5 · 2017-11-03T02:02:01Z

MGLComputedShapeSource, a wrapper for the core source type, accepts an MGLComputedShapeSourceDataSource, which is responsible for providing the tile data. The data source methods will be invoked on worker threads, not the main thread.

As in #6940 (comment) and #7485 (comment), I continue to fear that calling the callback on a background queue will be a trap for Objective-C and Swift developers, who are accustomed to doing anything UI-related on the main queue. A developer’s first instinct will be to make their view controller class the data source and have the MGLComputedShapeSourceDataSource method implements refer to instance variables, which will lead to concurrency trouble.

That said, I understand the performance considerations that led to this approach. Hopefully the presence of NSOperationQueue will point more savvy developers toward correctly isolating the data source method implementations into a separate class, but the asynchronicity does significantly diminish this feature’s attractiveness as part of the solution for #6181.

JesseCrocker · 2017-11-03T19:55:43Z

I agree that calling the callback on a background queue could be confusing to some developers, though i think this will end up being a feature that beginning developers probably wont find themselves needing, and the main thread checker in xcode9 makes the kinds of errors that it could lead to far more obvious. I think if this is changed to calling the callback on the main thread then the callback needs to be passed a callback, not return data, otherwise this feature would be not usable for many uses, including anything that has to fetch data from the network.

asheemmamoowala · 2017-11-03T20:58:19Z

A callback on the main thread would be less confusing and result in fewer synchronization errors. But we would lose the advantage of canceling stale tile requests provided by NSOperationQueue. Cancelling requests is necessary for providing smooth interactions (pan/zoom), and animations. Objective-C does not provide any primitives for canceling a callback invocation that has already been invoked.
Using an abstract class that requires inheritance could help communicate the intent of tile data requests being asynchronous tasks:

MGLShapeSourceTileProvider : {
- (NSArray<MGLShape <MGLFeature> *>*)featuresInTileAtX:(NSUInteger)x y:(NSUInteger)y zoomLevel:(NSUInteger)zoomLevel;
}

ivovandongen

@asheemmamoowala I focussed mostly on the Android bindings this time around. Few nit picky things aside, my main concern is the ownership/life-cylces of the core CustomGeometrySource, c++ peer and Java peer.

Right now, the c++ peer owns both the core source and maintains a global ref to the java peer, where I think the core class should own the c++ peer. This way, when the core source is destroyed, the c++ peer can be destroyed, releasing the java object. Right now, it seems that the peer classes are never cleaned up.

ivovandongen · 2017-11-07T12:44:25Z

...SDKTestApp/src/main/java/com/mapbox/mapboxsdk/testapp/activity/style/GridSourceActivity.java

+
+import static com.mapbox.mapboxsdk.style.layers.PropertyFactory.lineColor;
+
+public class GridSourceActivity extends AppCompatActivity implements OnMapReadyCallback {


A little hint of JavaDoc would be nice here

ivovandongen · 2017-11-07T12:44:50Z

...SDKTestApp/src/main/java/com/mapbox/mapboxsdk/testapp/activity/style/GridSourceActivity.java

+  @Override
+  public void onMapReady(@NonNull final MapboxMap map) {
+    mapboxMap = map;
+    new Handler(getMainLooper()).post(new Runnable() {


Why is this posted to the main looper? Shouldn't be necessary.

ivovandongen · 2017-11-07T12:47:55Z

src/mbgl/style/custom_tile_loader.cpp

-        std::lock_guard<std::mutex> lock(dataCacheMutex);
-        dataCache.erase(tileID);
-    }
+    dataCache.erase(tileID);
 }

 void CustomTileLoader::invalidateRegion(const LatLngBounds& bounds, Range<uint8_t> ) {
    for(auto idtuple= tileCallbackMap.begin(); idtuple != tileCallbackMap.end(); idtuple++) {


space after for

ivovandongen · 2017-11-07T12:49:18Z

...orm/android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/geometry/LatLngBounds.java

+  /**
+   * Constructs a LatLngBounds from a Tile identifier.
+   */
+  public static LatLngBounds from(int z, int x, int y) {


Also document the parameters for public methods please.

ivovandongen · 2017-11-07T12:49:54Z

...apboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/style/sources/CustomGeometrySource.java

+   *
+   * @param id the source id
+   */
+  public CustomGeometrySource(String id, GeometryTileProvider provider_) {


Missing GeometryTileProvider JavaDoc

ivovandongen · 2017-11-07T12:56:14Z

...apboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/style/sources/GeometryTileProvider.java

+import com.mapbox.mapboxsdk.geometry.LatLngBounds;
+import com.mapbox.services.commons.geojson.FeatureCollection;
+
+public interface GeometryTileProvider {


Please document public interfaces

ivovandongen · 2017-11-07T13:13:10Z

...apboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/style/sources/CustomGeometrySource.java

+   * @param id the source id
+   */
+  public CustomGeometrySource(String id, GeometryTileProvider provider_) {
+    executor = new ThreadPoolExecutor(2, 2, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(80));


Missing generic classification on ArrayBlockingQueue: <Runnable>

Should we ensure proper shutdown of the executor when the source is removed btw? At the moment, the core source might be removed while there are still tasks in the queue, these keep executing until finalisation of the Java object.

ivovandongen · 2017-11-07T13:35:50Z

platform/android/src/style/sources/custom_geometry_source.cpp

@@ -0,0 +1,122 @@
+#include "custom_geometry_source.hpp"


The indentation of this file is kinda off.

ivovandongen · 2017-11-07T13:39:25Z

platform/android/src/style/sources/custom_geometry_source.cpp

+                                               options,
+                                               std::bind(&CustomGeometrySource::fetchTile, this, std::placeholders::_1),
+                                               std::bind(&CustomGeometrySource::cancelTile, this, std::placeholders::_1))) ),
+      javaPeer(_obj.NewGlobalRef(env))  {


I don't think this is going to work properly as the Java/c++ peers will never be cleaned up.

As far as I can tell, the java object is created, which creates the c++ peer. The c++ peer holds a global reference to the java peer, ensuring it is not GC'd. Now, the only way to clean up both would be to destroy the c++ peer, which would release the global reference on the Java peer, making it eligible for GC. This in turn would however try to call the destructor of the c++ peer as that is how it has been registered through jni::RegisterNativePeer below.

For this to work, the life-cycle of the the c++ peer should be coupled to the core CustomGeometrySource. When it is destroyed, the c++ peer should be destroyed, releasing the global reference, making the java peer eligible for GC.

ivovandongen · 2017-11-07T13:45:03Z

platform/android/src/style/sources/custom_vector_source.hpp

@@ -0,0 +1,46 @@
+#pragma once


This is a left-over after refactoring right?

Yeah - this is definitely a mistake.

mkrussel77 · 2017-11-07T21:03:51Z

...apboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/style/sources/CustomGeometrySource.java

+   */
+  public CustomGeometrySource(String id, GeometryTileProvider provider_) {
+    executor = new ThreadPoolExecutor(2, 2, 60, TimeUnit.SECONDS, new ArrayBlockingQueue(80));
+    cancelledTileRequests = new HashMap<>();


Is using a HashMap safe here. Seems like it is getting modified by multiple threads, unless there is always only one WorkerThread. setTileData is not marked as a WorkerThread.

Since the class is holding an AtomicBoolean it looks like it is intended to be used by multiple threads.

Thanks for catching this @mkrussel77. HashMap will not work here and will need to use a thread-safe option like ConcurrentHashMap

…trySource

…ce in the C++ peer.

celoftis · 2017-11-29T21:26:13Z

I'm researching mapping APIs for offline maptile capability. This feature would be great to have.

j1m1y · 2018-02-01T07:58:09Z

this sdk version can load .mbtiles from local storage/sdcard ?

1ec5 · 2018-02-03T06:56:33Z

This PR alone doesn’t implement MBTiles support. Built-in MBTiles support is being tracked in #6862.

asheemmamoowala added the ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold label Sep 12, 2017

asheemmamoowala mentioned this pull request Sep 13, 2017

Add single-tile index: GeoJSONVTTile mapbox/geojson-vt-cpp#65

Merged

asheemmamoowala force-pushed the ahm-custom-vector-source branch from 1f4f494 to 3245ab3 Compare September 13, 2017 00:23

kkaefer added the Core The cross-platform C++ core, aka mbgl label Sep 13, 2017

asheemmamoowala force-pushed the ahm-custom-vector-source branch 3 times, most recently from 2415987 to 56150de Compare October 3, 2017 00:43

asheemmamoowala force-pushed the ahm-custom-vector-source branch 2 times, most recently from b414351 to fa81ebc Compare October 11, 2017 23:51

asheemmamoowala added the ✓ ready for review label Oct 12, 2017

ivovandongen suggested changes Oct 17, 2017

View reviewed changes

asheemmamoowala removed the ⚠️ DO NOT MERGE Work in progress, proof of concept, or on hold label Oct 18, 2017

jfirebaugh mentioned this pull request Oct 24, 2017

Custom vector source #8473

Closed

9 tasks

1ec5 reviewed Oct 26, 2017

View reviewed changes

1ec5 suggested changes Oct 26, 2017

View reviewed changes

asheemmamoowala force-pushed the ahm-custom-vector-source branch 4 times, most recently from a626b32 to 3ea2155 Compare November 1, 2017 23:40

asheemmamoowala force-pushed the ahm-custom-vector-source branch from 3ea2155 to 8c58a98 Compare November 2, 2017 21:10

ivovandongen suggested changes Nov 7, 2017

View reviewed changes

mkrussel77 reviewed Nov 7, 2017

View reviewed changes

asheemmamoowala force-pushed the ahm-custom-vector-source branch from 9227548 to 557f232 Compare November 11, 2017 01:58

asheemmamoowala mentioned this pull request Nov 14, 2017

[core, ios, macos, android] Support non-copyable types with unique_any #10459

Merged

asheemmamoowala force-pushed the ahm-custom-vector-source branch 2 times, most recently from 6ec1ec3 to 7d28ab7 Compare November 20, 2017 23:16

ivovandongen approved these changes Nov 21, 2017

View reviewed changes

asheemmamoowala force-pushed the ahm-custom-vector-source branch from 2f48e85 to 5d7fe7f Compare November 22, 2017 18:20

Asheem Mamoowala and others added 10 commits November 22, 2017 11:45

[core] Custom Geometry Sources

6995b39

[darwin] Abstract ShapeSource interface

d608334

[ios, macos] Implement MGLComputedShapeSource binding for CustomGeome…

a4b7195

…trySource

[ios,macos] Add MGLComputedShapeSource example to demo apps

851ff9e

[android] Bindings for Custom Geometry Sources

42f61c0

[android] Add Grid source sample for Custom Geometry Source

a541bf8

[core] Use Actors for CustomTileLoader invocation from bindings.

08f6e4d

[core, ios, macos] Implement unique_any and remove linb::any

39bc720

[android] Reuse Java Source objects by holding on to a strong referen…

1737bfc

…ce in the C++ peer.

[android] Use inherited javaPeer in CustomGeometrySource C++ peer

1fb74c2

asheemmamoowala force-pushed the ahm-custom-vector-source branch from 5d7fe7f to 1fb74c2 Compare November 22, 2017 19:48

asheemmamoowala merged commit e2702c7 into master Nov 22, 2017

asheemmamoowala deleted the ahm-custom-vector-source branch November 22, 2017 22:00

akitchen mentioned this pull request Nov 27, 2017

Static analysis warnings in MGLComputedShapeSource.mm #10571

Closed

asheemmamoowala mentioned this pull request Dec 6, 2017

Adding a new MGLSource subclass that implements datasource pattern for fetching tiles on iOS #6861

Closed

1ec5 mentioned this pull request Jan 10, 2018

MBTiles mapbox/mapbox-plugins-ios#19

Open

This was referenced Jan 25, 2018

Add CustomGeometrySource example mapbox/mapbox-android-demo#610

Open

Release Android v6.0.0-beta.1 #11060

Closed

1ec5 mentioned this pull request Feb 28, 2018

Exposing MGLGeometry_Private.h C++ globals #9819

Closed

asheemmamoowala removed the ✓ ready for review label Mar 29, 2018

asheemmamoowala mentioned this pull request Aug 28, 2019

[ios] Crashes caused by dangling rawSource pointer after new style is parsed. #15333

Closed


		import static com.mapbox.mapboxsdk.style.layers.PropertyFactory.lineColor;

		public class GridSourceActivity extends AppCompatActivity implements OnMapReadyCallback {

Custom Vector Source (n+1) #9983

Custom Vector Source (n+1) #9983

Conversation

asheemmamoowala commented Sep 12, 2017 • edited Loading

asheemmamoowala commented Oct 4, 2017

ivovandongen commented Oct 5, 2017

asheemmamoowala commented Oct 5, 2017

asheemmamoowala commented Oct 5, 2017

ivovandongen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

asheemmamoowala commented Nov 2, 2017 • edited Loading

Core

iOS, macOS

Android

Node, Qt

Synchronization

Tail work

Future Work

1ec5 commented Nov 3, 2017

JesseCrocker commented Nov 3, 2017

asheemmamoowala commented Nov 3, 2017 • edited Loading

ivovandongen left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

celoftis commented Nov 29, 2017 • edited Loading

j1m1y commented Feb 1, 2018

1ec5 commented Feb 3, 2018

asheemmamoowala commented Sep 12, 2017 •

edited

Loading

asheemmamoowala commented Nov 2, 2017 •

edited

Loading

asheemmamoowala commented Nov 3, 2017 •

edited

Loading

ivovandongen left a comment •

edited

Loading

celoftis commented Nov 29, 2017 •

edited

Loading