Map view should use pixel density of current screen

[friedbunny]

Platform: macOS 10.12.3 Beta (16D17a)
Mapbox SDK version: macOS 0.3.0
Hardware: MacBook Pro (Retina, 13-inch, Early 2015), Intel Iris Graphics 6100 1536 MB

When running macapp on a non-retina screen, the map graphics are aliased and chunky. This is on 10.12.3 beta — when I update to today’s official release version I will retest.

/cc @1ec5 @kkaefer

[1ec5]

I wonder if this is happening because +[NSScreen mainScreen] is returning a screen other than the one this window is on. At the time you opened this window, did your MacBook Pro’s built-in Retina screen have keyboard focus?

[friedbunny]

At the time you opened this window, did your MacBook Pro’s built-in Retina screen have keyboard focus?

Yes, it turns out I was doing that — opened macapp from finder on the retina screen, but the app opened on the second, non-retina display. Focusing the non-retina screen and opening macapp on that screen works as expected (it’s anti-aliased).

[1ec5]

Incidentally, are you able to reproduce #6654?

[friedbunny]

Incidentally, are you able to reproduce #6654?

Moving to a screen with a different pixel density doesn’t crash (on a release build), but the GL view does stop working and goes gray/whatever-the-style’s-background-color-is. MGLMapView UI elements remain visible and map interactions appear to still work, but nothing is drawn.

[friedbunny]

It looks like #3451 covered both the original aliasing issue and the disappearing GL view. That was closed in favor of #6654.

[1ec5]

The root cause is that we create mbgl::Map with the backing scale factor of the main screen (the screen that has keyboard focus) at the time of the view’s creation. But if you open the window on one screen by clicking on some icon on another screen, the main screen and the window’s screen are distinct and may have different scale factors.

We’re in a catch-22. Ideally we’d use a solution similar to #7846 when creating mbgl::Map. Unfortunately, we create mbgl::Map in -commonInit, before the view is added to a window, yet #1799 removed the ability for mbgl::Map to transition to a different pixel density once the view is added to a window. We’d need to move the map’s creation and anything that depends on mbgl::Map’s presence from -commonInit to -viewDidMoveToWindow. But it’s most common to call -setStyleURL: between initializing the map view and adding it to a subview, which would trigger a crash. Therefore, the only solution would be to undo #1799, and I don’t know if that would be feasible under the current architecture.

[1ec5]

As of #12933, mbgl requests both 1× and 2× resources unconditionally, though the decision of which to display is still made at initialization and can’t be changed dynamically.

[kkaefer]

@1ec5 no, that's quite what #12933 does. We only request both when creating an offline pack, not in regular operation.

[1ec5]

Per #13701, it’s also possible for the iOS map SDK to run in a mixed pixel density environment, specifically when connected to an external display via either AirPlay or CarPlay.

[stale]

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