platform views vs. core GL sprites for annotations & callouts

[incanus]

In chatting with @zugaldia about Android needs for what we call the "info window" there and "callouts" or "popups" on iOS, I wanted to clarify my thinking around #1125 (and some in #1784) and where we are or aren't blocked right now. I think there is some misunderstanding of next steps and potential features here.

Current state of things around annotations & popups:

• iOS: We use the iOS-side SMCalloutView to present callouts on tapped annotations (if so configured).
• Android: We have our own Android-side InfoWindow class internally for popups.
• We present singular popups for selection annotations.
• On map viewport change, we dismiss the popup so that we don't have to worry about syncing its position.
• All annotations are rendered GL-side as sprite images, scaling to 10,000 or more markers effortlessly.
• On both platforms, the user dot is platform-side as a native view whose position is synced after each frame draw (iOS and Android). We do this platform-side because each has its own very distinct platform feel and makes use of animations and other patterns specific to those platforms. Also, it's just one, single view to sync — the singular user dot.

A few things we could technically do now:

1. Allow for multiple popups on screen at once. We've shied away from this in past due to weird UI patterns and no precedent in other toolkits, but this is easily accomplished.
2. Sync the popups the same way we sync the user dot now so that they can pan and zoom with the map (though, like markers, they stay the same size — this is basically just position syncing).
3. Render native Android/iOS views for annotations and track them to the map in the same way.

What #1125 is talking about is the fact that the third point above is not performant for large quantities of markers (say, over a couple hundred). We've seen this firsthand already because this is how annotations were done in the raster toolkits. #1125 aims to explore the possibility of compositing the native views' contents as GL textures for the best of both worlds — native, platform-side view API and GL performance. This was explored on iOS and proven probably possible as of #1125 (comment).

However, finishing out #1125 (if it is indeed possible) is not necessarily a blocker to doing more with popups and maybe even annotations right now. We just need to set expectations properly about the numbers of views able to be reasonably added to the view hierarchy and synced every frame draw, 60 times per second. We also want to think about API complexity around possibly having two avenues for implementing annotations — and ideally shield the API consumer from any of those complexities.

Basically, think about what we need to accomplish now, possibly implement some of it, but don't paint ourselves into a corner if something like #1125 isn't feasible.

@mapbox/gl @twbell

[zugaldia]

Related: #3115

[1ec5]

One of the salient points of #1582 is that the SMCalloutView can be animated around the screen without much of a performance penalty, even without the view-based animations explored in that PR, now that we time our screen updates properly via #3005 and #3009.

[RomainQuidet]

We've got a story here at Mappy where we need to animate an annotation (Dropping, or jumping around on the map). Doing so in GL is quite difficult (I easily see how to do in iOS native). Am I wrong ?

[1ec5]

Now that #1125 is finally resolved, we’re taking a fresh look at this problem space. #4801 is a work-in-progress implementation of MapKit-style native annotation views on iOS. #3276 tracks something similar on Android.

We’re reconsidering native annotation views because there are many common use cases in which full integration with platform APIs is far more desirable than seamless performance of 10,000 annotations on screen simultaneously. Moreover, issues like #3185 have demonstrated that, while GL annotations excel at reusability, they aren’t designed to handle graphics-heavy use cases, particularly use cases in which every annotation may have a large, unique image.

This does roughly double the API surface area for annotations. I think the primary messaging around the two annotation APIs is that annotations come in two forms: views (UIViews) and icons (GL annotations). Views are heavier but richer, while icons are lighter, more performant. We also expect GL annotations, currently represented by MGLAnnotationImages, to eventually gravitate towards GeoJSON and GL style properties for parity with Mapbox GL JS. #837 is the first step. Once that happens, I don’t think there will be much of a mixed message, because the two APIs will be for fundamentally different things.

[1ec5]

We've got a story here at Mappy where we need to animate an annotation (Dropping, or jumping around on the map). Doing so in GL is quite difficult (I easily see how to do in iOS native). Am I wrong ?

@RomainQuidet, as of #3835, you can change the annotation’s coordinate iteratively (in a KVO-compliant manner) to approximate animation. It probably won’t be quite as smooth as view-based animation, however.

[jfirebaugh]

Closing; both #4801 and #3276 have been implemented.

[1ec5]

As for callout views, the next step on iOS is covered by #4392.