improve synced view tracking

[incanus]

General ticket for improvement of "sticking" native, Cocoa-side views to the panning, zooming GL render view.

This relates to the user dot now, later to callouts and annotation views. Let's keep a ticket around until we are 100% satisfied with the behavior here, but we can move it along milestones as we make staged improvements.

[incanus]

I'm feeling pretty good about the current state of tracking, especially after the above commit which avoids invalid CLLocationCoordinate2D-based updates during TransformState "will change" events (and just catches the "did change").

The one issue I'm seeing which I'd like to clean up is the dot disappearing during e.g. a double-tap animated zoom. It doesn't show up again until the next CLLocationManager update. It gets hidden because the CGPoint received out of -[MGLMapView convertCoordinate:toPointToView:] is well out of range of given screen bounds. I think this is just some sort of math error in TransformState during animations.

[incanus]

Another lead that confirms the above: pan the map until the dot is >150px off screen, then hit the user locate button. The map pans back into view (meaning the map centering to the valid user location is of course working) but the dot doesn't show up until the next CL update post-animation. During the animation it's still residing at the offscreen value, so it's hidden.

[incanus]

Tracking is pretty good right now. Only outstanding issue I'd like to hit for the beta is the dot disappearing briefly during animated zooms (but coming back at least, now). I'm nearing some completion on this but don't want to hold up a build tonight so I'll work on that a bit over the weekend.

Going to squash & merge a few commits now with improvements thus far.

[incanus]

First batch of improvements in #1151.

[incanus]

Main blocker here now captured in the more general #1160 bug with projection conversion.

[kkaefer]

FWIW, I think we should get rid of overlaying iOS views onto the Map and instead render everything ourselves. Apple recommends against doing this as well: https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html#//apple_ref/doc/uid/TP40008793-CH105-SW8

For the absolute best performance, your app should rely solely on OpenGL ES to render your content.

[incanus]

Right, but I direct your attention back to https://github.com/incanus/AniAnnoDemo and what needs to happen to make this work :-) The thing I'm most uncertain about is syncing frames of animation from native views into GL. Maybe it's not as terrible as I'm imagining though.

[mb12]

@incanus Perhaps, we should try posting the synchronization problem to Apple developer forums and/or use the 3 incidents that Apple includes in developer support. Apple is already doing this for Mapkit. Its a problem that they have already solved. It would make writing all kind of Map overlays super easy.

https://developer.apple.com/devforums/

[incanus]

http://stackoverflow.com/a/17096916/977220

In fact, you can't synchronize them using current APIs. MobileMaps.app and Apple Map Kit use private property on CAEAGLLayer asynchronous to workaround this issue.

I'm intending to dig deep when the time comes for this, but right now the user dot is syncing well and we just need the bug fix in #1160 for a workable version right now.

From the POV of annotations, after shapes, this will be my next priority.

[incanus]

On this front, I've been thinking about looking into routes for capture a view's layer's presentationLayer at a given point in time and rasterizing it to a GL render layer. That is, all tracked views atop the GL view will actually get rasterized into a single "layer" in the GL. I have no idea how feasible this is, but is the sort of approach I've been mulling over researching.

[incanus]

We are ok here for b2 and b3 and beyond will feature much more robust point annotations.

[friedbunny]

Per WWDC and chat and Stack Overflow:

In iOS 9 CAEAGLLayer has presentsWithTransaction property that synchronizes the two.

[ljbade]

Making note of #2384 as it looks like iOS 9 has some fixes that can be used.

[incanus]

We started looking at that in #1125 (comment) @ljbade. No help currently.

[1ec5]

#3683 finally synchronizes the user dot with the map. Keeping this issue open until we’re able to leave callouts open while the viewport moves.

[1ec5]

#3683 has landed and will be in v3.2.0. Closing in favor of #3154.