macOS - annotations do not appear until the next time user adds one.

[julianrex]

Platform: macOS 10.13.3 (17D102) Mapbox SDK version: release-boba (https://github.com/mapbox/mapbox-gl-native/tree/0525fd1e4a207040b6268ee0b2a9634d8fa37753)

When dropping pins, occasionally they do not appear until the next time the user tries to add one.

This happens inconsistently, but I have most luck in triggering this by re-running the app until the tiles don't appear to be fully loaded/rendered correctly (this may be another/existing issue?). In the above, I've used satellite view, but I have had it occur with other styles.

Additionally, I've also seen the pin appear when the callout has fully appeared (not simultaneously with its appearance).

/cc @1ec5

[jfirebaugh]

Can you git bisect this to try to pinpoint the cause?

[julianrex]

Since the bug can be tricky to reproduce, and appears to have gone through a few variants, I don't completely trust the following:

The first set of changes that produce this

(which is slightly different from the image in the OP), occurred somewhere in https://github.com/mapbox/mapbox-gl-native/compare/dcd7da...ff58848. Some of the interim commits don't compile, so I couldn't narrow it down further.

Later, the annotations' appearance is improved in https://github.com/mapbox/mapbox-gl-native/commit/6782d7a (producing what I first reported).

I suspect the annotations are there and this is just an alpha/timing issue.

cc @ChrisLoer @ansis

[ChrisLoer]

Thanks for tracking that down @julianrex , I can reproduce with the macosapp. I'm still digging in, but it looks to me like the symbol is getting added without triggering a placement (that's why it appears when you add the next one or move the map -- almost any change will usually trigger placement).

[ChrisLoer]

Looks to me like this is caused by #7820, although it's a different manifestation. The problem is that we're asking the MGLMapView to request a new frame but for whatever reason it's not calling back into the rendering code. Here's a verbose log showing the pattern in one of the cases where the pin doesn't animate in:

...
setNeedsGLDisplay
Render
Rendering with stale placement
has transitions: 1
setNeedsGLDisplay
Render
Rendering with stale placement
has transitions: 1
setNeedsGLDisplay
<nothing more>

That final setNeedsGLDisplay should be followed by a render call (at which point we should run placement and start animating the pin in.

@1ec5 do you have any ideas about what we can do for this situation? I can only think of pretty hacky workarounds like "set a timer whenever you request a frame, and if the frame doesn't get drawn within X milliseconds, request it again".

[ChrisLoer]

Lucky for me I have one of the machines affected by #7820, otherwise I never would have been able to reproduce this...

[julianrex]

@ChrisLoer I just pushed an experimental branch

https://github.com/mapbox/mapbox-gl-native/tree/jrex-11275-render-display-link-test

that uses macOS's CVDisplayLink (somewhat like CADisplayLink on iOS) to manage the layer's setNeedsDisplay call - this seems to do the trick, though it was added quickly and as such is not fully tested. Certainly there's nothing there to manage frame rates.

[julianrex]

/cc @frederoni

[ChrisLoer]

@julianrex That sounds like it could be a promising approach! I don't know anything about the actual details of CVDisplayLink, though, so I can't give you much feedback on the actual code. I did try building the macosapp off of your branch, and I seemed to get pretty bad frame rates (single-digit FPS). Ideally a solution here will also address #7820 and allow us to get that deliciously smooth 60FPS rendering...

[julianrex]

Interesting - mine was silky smooth, so perhaps it is a machine issue.

[1ec5]

I initially explored using CVDisplayLink as part of #3135 but abandoned that approach because it very easily spun up the fans on my machine. It’s possible that the API or something about mbgl has changed since then to make this a feasible approach, however.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julianrex]

I need to revisit this issue to see if it's still occurring; there have been many changes in the interim.

[stale[bot]]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.