Deprecate MarkerView

[tobrun]

This PR deprecates the usage of MarkerView and replaces those use-cases with using a SymbolLayer + SymbolGenerator. This allows to benefit from the options that symbolLayer exposes while using any Android SDK View as iconImage.

• First commit updates naming of an older example (no refs to sprite in public api of the android binding)
• Second commit show cases SymbolGenerator (see gif below)
• Third commit deprecates MarkerView API

cc @mapbox/android

[zugaldia]

Could we add a link to an example using the new proposed approach? Explaining the general approach is great but I think that some working code would make the transition easier.

[zugaldia]

Maybe CustomSymbolLayerActivity or SymbolGeneratorActivity if they're reference implementations for the new approach?

[zugaldia]

Maybe add a note saying "replaces MarkerView approach"?

[1ec5]

Can you speak to the performance of SymbolGenerator compared to MarkerViews with 100, 500, 1,000 markers on the map?

[tobrun]

MarkerViews are Android SDK views synchronized above our rendering surface (currently SurfaceView, optional to switch to TextureView for increased view synchronization performance). What happens for a MarkerView is that the user inflates a View and we will synchronize its position to a LatLng every time the map changes. This synchronization will result in measure and layout phases with every change.

With SymbolGenerator we measure the view once and create a bitmap of it, no performance hit while using the map. One difference though is that MarkerView are inflated on the fly but with SymbolGenerator you will be creating your views/bitmaps up front. I'm not really seeing this as an issue as this is the same ux as with SymbolLayer.

I will look into creating a more complete example to identify any possible issues with SymbolGenerator initialization when measuring a lot of views. Note that while using the map, the performance will boil down to performance of SymbolLayer which will always outscore MarkerView.

[tobrun]

I updated the example to create a View and SymbolLayer for each Feature in the GeoJSON (37 features):

I would say this example would show a lot of jiggling/degraded performance with MarkerViews.

[tobrun]

Did another test with this geojson. This resembles ports in the world and consists out of 1081 points.

You can see this is not acceptable in terms of performance (tested on low end device) though the same use-case implemented with textField shows similar issues:

[tobrun]

for reference here is a gif with 100 and 1000 markerviews:

Adding 1000 resutls in an ANR.

[1ec5]

Thanks for the analysis. So would this be a good characterization of the tradeoff?

MarkerViews:

• Support views that change dynamically with animation – doing that performantly would require Add and modify individual features in a GeoJSON source on the fly #6177
• More performant for markers that move frequently with animation (think cars moving around atop the map)

SymbolGenerator:

• Markers can appear beneath other style layers
• More performant for markers with static coordinates and static content (no jiggling and smaller memory footprint)
• Markers correctly scale (When map is tilted, Marker Views don’t scale by distance from camera #5169) and skew (Flat markers should have screen-centered vanishing point #5218) when the map is tilted

What about some of the other behaviors listed in #6181?

• Can a SymbolGenerator persist beyond the lifetime of a style (Optionally persist layers and sources across styles #6180)?
• If the developer wants to implement interactivity, can they use feature querying and rely on the feature IDs to correspond to view IDs (Feature querying should return existing annotations #6178 mbgl::style::GeoJSONSource should have GeoJSON getter #7376)?

[tobrun]

Capturing from internal conversations that we are planning to put the SymbolGenerator code inside a utils plugin instead of the SDK. I'm going to rework this PR to only deprecate MarkerView and point the deprecation notices to use SymbolLayer instead.

[tobrun]

with ed2ae27 the suggestion from #9782 (comment) has been applied.

cc @zugaldia

[zugaldia]

How about we instead include this approach as an activity in the TestApp while we work on making it available as a plugin?

[tobrun]

I added SymbolGeneratorActivity to the testapp, replaced all references to the gist with a permalink to an Activity in the testapp.

[zugaldia]

@tobrun 👍

[tobrun]

If you are on-board with this change, could you re-review?

[tobrun]

updated the example to use 1 layer for all different used symbols in
68f32bc