macOS SDK crashes when moving between screens

[kkaefer]

When moving the macOS SDK window between screens (one with a Retina pixel ratio, and the other with a regular pixel ratio in my case), I'm getting a crash when trying to update the FrameHistory texture. It doesn't appear to be specific to that texture since it crashes at other locations as well if that upload is commented out. It seems like doing any sort of OpenGL API call triggers this crash.

Using apitrace, I found that just prior to the crash, CGLUpdateContext is called, and returns kCGLBadDrawable.

The crash does not appear when moving GLFW windows between screens, making me believe that there's something fishy in our use of NSOpenGLLayer or the macOS implementation in general.

/cc @1ec5 @incanus

[jfirebaugh]

Probably should consolidate with #5010 and #3451.

[incanus]

Out of curiosity, @kkaefer do you see this as merely an annoyance / nice to have or something we should prioritize more highly to be 100% correct? Like, it's not a very common user scenario, right?

[kkaefer]

It's not super common, but it is an unavoidable crash bug that might deter people from using it on an actual macOS app. That being said, it's also annoying when testing since I sometimes move windows between screens.

[1ec5]

It's pretty common to have screens with different pixel densities, particularly on a MacBook that may be hooked up to a non-Apple monitor or a projection screen.

The higher priority would be to not crash in this scenario. Ideally, the map would refresh with the correct pixel density – there's a notification for that – but auto-refreshing might buck developer expectations around the runtime styling API.

[1ec5]

As far as I know, GLFW uses NSOpenGLView but doesn't use NSOpenGLLayer directly as this SDK does.

[1ec5]

Per #7819 (comment), moving a map view between different screens doesn’t crash in a Release build, but it does stop rendering, which suggests that it would crash in a Debug build.

#1799 removed the ability for an mbgl::Map object to transition between different pixel densities. So a proper fix for this issue would entail either undoing #1799 or somehow creating a new mbgl::Map whenever the window moves between screens. Either approach sounds daunting.

[kkaefer]

I debugged this further with apitrace and found that when moving the window to a new screen, the underlying NSOpenGLLayer implementation actually destroys the OpenGL context and creates a new one. Of course, that means that all of the OpenGL handles we've stored in our internal state are now invalid, leading to the crash.