Repository navigation
improve synced view tracking #1125
Description
Activity
- added a commit that references this issue
on Mar 27, 2015 I'm feeling pretty good about the current state of tracking, especially after the above commit which avoids invalid
CLLocationCoordinate2D-based updates duringTransformState"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
CLLocationManagerupdate. It gets hidden because theCGPointreceived out of-[MGLMapView convertCoordinate:toPointToView:]is well out of range of given screen bounds. I think this is just some sort of math error inTransformStateduring animations.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.
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.
- added a commit that references this issue
on Mar 28, 2015 - added a commit that references this issue
on Mar 28, 2015 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.
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.
@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.
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
CAEAGLLayerasynchronousto 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.
On this front, I've been thinking about looking into routes for capture a view's layer's
presentationLayerat 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.50 remaining items
- added a commit that references this issue
on Jul 8, 2015 We started looking at that in #1125 (comment) @ljbade. No help currently.
- added a commit that references this issue
on Jan 25, 2016
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.