Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Obscure GLKView while app is in background #1254

Merged
merged 3 commits into from
Apr 15, 2015
Merged

Obscure GLKView while app is in background #1254

merged 3 commits into from
Apr 15, 2015

Conversation

1ec5
Copy link
Contributor

@1ec5 1ec5 commented Apr 10, 2015

Throw a static snapshot up for the app switcher. Hope you didn’t plan on seeing tiles load while the app is in the background.

Fixes #1050, #1186, #1203, #1243. Not sure about #1198.

/cc @incanus @kkaefer

Throw a static snapshot up for the app switcher. Hope you didn’t plan on moving markers around while the app is in the background.

Fixes #1050, #1186, #1203, #1243.
@1ec5 1ec5 added the iOS Mapbox Maps SDK for iOS label Apr 10, 2015
@1ec5 1ec5 added this to the iOS Beta 1 milestone Apr 10, 2015
@1ec5
Copy link
Contributor Author

1ec5 commented Apr 10, 2015

Another consequence of this change is that it’ll take longer for the tiles to reload when you switch back to the app. Previously you’d only see a brief flash as the tiles rerender, but now you can easily see the old tiles fade out and the new ones slowly reload.

@incanus
Copy link
Contributor

incanus commented Apr 11, 2015

Interesting, look forward to testing.

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 11, 2015

Hopefully the reloading effect mentioned above will be mitigated by #1255.

@kkaefer
Copy link
Member

kkaefer commented Apr 11, 2015

Why are we removing the GLKView when the app pauses? Does that mean the os won't send updates anymore? Does it do that by default?

I believe this error is caused by us explicitly triggering a view update, which is invalid when the app is in the background. So we should catch those explicit updates and only trigger them once the app comes back to the foreground. The call that triggers the explicit updates is View::invalidate.

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 11, 2015

Does that mean the os won't send updates anymore? Does it do that by default?

Yes. Here’s the stack trace when that happens:

#4  0x00000001001048f8 in mbgl::Map::triggerRender() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:320
#5  0x0000000100104764 in mbgl::Map::renderSync() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:302
#6  0x000000010035314c in -[MGLMapView glkView:drawInRect:] at /Users/mxn/hub/mapbox-gl-native-2/platform/ios/MGLMapView.mm:572
#7  0x00000001849f40f0 in -[GLKView _display:] ()
#8  0x0000000187d0ba34 in CA::Layer::display() ()
#9  0x0000000187ceca7c in CA::Layer::display_if_needed(CA::Transaction*) ()
#10 0x0000000187cec734 in CA::Layer::layout_and_display_if_needed(CA::Transaction*) ()
#11 0x0000000187cebebc in CA::Context::commit_transaction(CA::Transaction*) ()
#12 0x0000000187cebc3c in CA::Transaction::commit() ()
#13 0x0000000188619d18 in _UIWindowUpdateVisibleContextOrder ()
#14 0x0000000188619b60 in +[UIWindow _prepareWindowsPassingTestForAppResume:] ()
#15 0x00000001886453b8 in -[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:] ()
#16 0x0000000188644dfc in __88-[UIApplication _handleApplicationLifecycleEventWithScene:transitionContext:completion:]_block_invoke ()
#17 0x0000000188644d54 in -[UIApplication _handleApplicationLifecycleEventWithScene:transitionContext:completion:] ()
#18 0x0000000188637fe0 in -[UIApplication scene:didUpdateWithDiff:transitionContext:completion:] ()

I believe this error is caused by us explicitly triggering a view update, which is invalid when the app is in the background. … The call that triggers the explicit updates is View::invalidate.

View::invalidate() is never called from the time the map is stop()ed. (Map::stop() sets mode = Mode::None, which prevents Map::prepare() from calling invalidate().)

@incanus
Copy link
Contributor

incanus commented Apr 13, 2015

#4  0x00000001001048f8 in mbgl::Map::triggerRender() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:320
#5  0x0000000100104764 in mbgl::Map::renderSync() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:302
#6  0x000000010035314c in -[MGLMapView glkView:drawInRect:] at /Users/mxn/hub/mapbox-gl-native-2/platform/ios/MGLMapView.mm:572
#7  0x00000001849f40f0 in -[GLKView _display:] ()

If I'm following this correctly, why don't we just set a BOOL when the app is backgrounding (where this PR does view hierarchy manipulation) and if set, return early inside of -glkView:drawInRect: so that GL code is never called?

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 13, 2015

That’s apparently only one of the places where the OS can fiddle with the GLKView. Indeed, if you guard against being in the background in -glkView:drawInRect:, you just crash downstream in various places like:

Map (17)#0  0x0000000195927270 in __pthread_kill ()
#1  0x00000001959c5170 in pthread_kill ()
#2  0x000000019589eb18 in abort ()
#3  0x0000000195873a3c in __assert_rtn ()
#4  0x0000000100319690 in mbgl::Worker::send(std::__1::function<void ()>, std::__1::function<void ()>) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/util/worker.cpp:34
#5  0x0000000100140ed0 in mbgl::TileData::reparse(mbgl::Worker&, std::__1::function<void ()>) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/tile_data.cpp:62
#6  0x00000001001450b4 in mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0::operator()(mbgl::Response const&) const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/tile_data.cpp:46
#7  0x0000000100144c18 in decltype(std::__1::forward<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&>(fp)(std::__1::forward<mbgl::Response const&>(fp0))) std::__1::__invoke<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&, mbgl::Response const&>(mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&&&, mbgl::Response const&&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#8  0x0000000100144bf8 in std::__1::__function::__func<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0, std::__1::allocator<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0>, void (mbgl::Response const&)>::operator()(mbgl::Response const&) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1370
#9  0x0000000100202c5c in std::__1::function<void (mbgl::Response const&)>::operator()(mbgl::Response const&) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1756
#10 0x0000000100201dd8 in mbgl::Request::invoke() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:57
#11 0x0000000100201be4 in mbgl::Request::notifyCallback() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:38
#12 0x0000000100202b04 in mbgl::Request::Request(mbgl::Resource const&, uv_loop_s*, mbgl::Environment const&, std::__1::function<void (mbgl::Response const&)>)::$_0::operator()(uv_async_s*, int) const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:27
#13 0x0000000100202a9c in mbgl::Request::Request(mbgl::Resource const&, uv_loop_s*, mbgl::Environment const&, std::__1::function<void (mbgl::Response const&)>)::$_0::__invoke(uv_async_s*, int) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:27
#14 0x000000010038ddd0 in uv__async_event at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/async.c:80
#15 0x000000010038e1f4 in uv__async_io at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/async.c:156
#16 0x00000001003aa884 in uv__io_poll at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/kqueue.c:233
#17 0x000000010038e950 in uv_run at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/core.c:317
#18 0x00000001000f22f8 in mbgl::Map::run() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:278
#19 0x0000000100103030 in mbgl::Map::start(bool)::$_5::operator()() const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:177
#20 0x0000000100102e18 in decltype(std::__1::forward<mbgl::Map::start(bool)::$_5>(fp)(std::__1::forward<>(fp0))) std::__1::__invoke<mbgl::Map::start(bool)::$_5>(mbgl::Map::start(bool)::$_5&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#21 0x0000000100102e0c in void std::__1::__thread_execute<mbgl::Map::start(bool)::$_5>(std::__1::tuple<mbgl::Map::start(bool)::$_5>&, std::__1::__tuple_indices<>) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:332
#22 0x0000000100102dfc in void* std::__1::__thread_proxy<std::__1::tuple<mbgl::Map::start(bool)::$_5> >(void*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:342

and:

Map (17)#0  0x00000001949793f0 in __cxa_throw ()
#1  0x000000019494cc78 in std::__1::__throw_system_error(int, char const*) ()
#2  0x00000001002eab78 in std::__1::unique_lock<std::__1::mutex>::unique_lock(std::__1::mutex&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__mutex_base:108
#3  0x00000001002eab50 in std::__1::unique_lock<std::__1::mutex>::unique_lock(std::__1::mutex&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__mutex_base:108
#4  0x00000001002eab44 in mbgl::Channel<mbgl::Worker::Work>::send(mbgl::Worker::Work const&) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/util/channel.hpp:16
#5  0x00000001002e9748 in mbgl::Worker::send(std::__1::function<void ()>, std::__1::function<void ()>) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/util/worker.cpp:41
#6  0x0000000100110ed0 in mbgl::TileData::reparse(mbgl::Worker&, std::__1::function<void ()>) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/tile_data.cpp:62
#7  0x00000001001150b4 in mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0::operator()(mbgl::Response const&) const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/tile_data.cpp:46
#8  0x0000000100114c18 in decltype(std::__1::forward<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&>(fp)(std::__1::forward<mbgl::Response const&>(fp0))) std::__1::__invoke<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&, mbgl::Response const&>(mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0&&&, mbgl::Response const&&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#9  0x0000000100114bf8 in std::__1::__function::__func<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0, std::__1::allocator<mbgl::TileData::request(mbgl::Worker&, float, std::__1::function<void ()>)::$_0>, void (mbgl::Response const&)>::operator()(mbgl::Response const&) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1370
#10 0x00000001001d2c5c in std::__1::function<void (mbgl::Response const&)>::operator()(mbgl::Response const&) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1756
#11 0x00000001001d1dd8 in mbgl::Request::invoke() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:57
#12 0x00000001001d1be4 in mbgl::Request::notifyCallback() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:38
#13 0x00000001001d2b04 in mbgl::Request::Request(mbgl::Resource const&, uv_loop_s*, mbgl::Environment const&, std::__1::function<void (mbgl::Response const&)>)::$_0::operator()(uv_async_s*, int) const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:27
#14 0x00000001001d2a9c in mbgl::Request::Request(mbgl::Resource const&, uv_loop_s*, mbgl::Environment const&, std::__1::function<void (mbgl::Response const&)>)::$_0::__invoke(uv_async_s*, int) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/storage/request.cpp:27
#15 0x000000010035ddd0 in uv__async_event at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/async.c:80
#16 0x000000010035e1f4 in uv__async_io at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/async.c:156
#17 0x000000010037a884 in uv__io_poll at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/kqueue.c:233
#18 0x000000010035e950 in uv_run at /Users/kkaefer/Code/mason/libuv-0.10.28/mason_packages/.build/libuv-0.10.28/src/unix/core.c:317
#19 0x00000001000c22f8 in mbgl::Map::run() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:278
#20 0x00000001000d3030 in mbgl::Map::start(bool)::$_5::operator()() const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:177
#21 0x00000001000d2e18 in decltype(std::__1::forward<mbgl::Map::start(bool)::$_5>(fp)(std::__1::forward<>(fp0))) std::__1::__invoke<mbgl::Map::start(bool)::$_5>(mbgl::Map::start(bool)::$_5&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#22 0x00000001000d2e0c in void std::__1::__thread_execute<mbgl::Map::start(bool)::$_5>(std::__1::tuple<mbgl::Map::start(bool)::$_5>&, std::__1::__tuple_indices<>) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:332
#23 0x00000001000d2dfc in void* std::__1::__thread_proxy<std::__1::tuple<mbgl::Map::start(bool)::$_5> >(void*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:342

with this on the main thread:

#3  0x00000001000f03d4 in mbgl::Map::stop(std::__1::function<void ()>) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:209
#4  0x000000010034324c in -[MGLMapView appDidBackground:] at /Users/mxn/hub/mapbox-gl-native-2/platform/ios/MGLMapView.mm:593

Maybe they’re unrelated, but I’ve been much more successful getting these crashes without the proposed fix.

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 13, 2015

With some additional testing, I have been able to reproduce these crashes despite the proposed fix, so I think they’re probably unrelated, rather than being downstream bugs.

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 13, 2015

However, there is one crash that always reproduces without my fix and never with:

Map (38)#0  0x00000001949793f0 in __cxa_throw ()
#1  0x00000001001c9a24 in mbgl::gl::checkError(char const*, char const*, int) at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/platform/gl.cpp:96
#2  0x00000001001f1d04 in mbgl::Painter::setup()::$_4::operator()() const::_::~_() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/renderer/painter.cpp:79
#3  0x00000001001f1c88 in mbgl::Painter::setup()::$_4::operator()() const::_::~_() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/renderer/painter.cpp:79
#4  0x00000001001ec1c8 in mbgl::Painter::setup()::$_4::operator()() const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/renderer/painter.cpp:79
#5  0x00000001001ea398 in mbgl::Painter::setup() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/renderer/painter.cpp:79
#6  0x0000000100132880 in mbgl::Map::setup() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:391
#7  0x0000000100132410 in mbgl::Map::run() at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:272
#8  0x00000001001431b0 in mbgl::Map::start(bool)::$_5::operator()() const at /Users/mxn/hub/mapbox-gl-native-2/src/mbgl/map/map.cpp:177
#9  0x0000000100142f98 in decltype(std::__1::forward<mbgl::Map::start(bool)::$_5>(fp)(std::__1::forward<>(fp0))) std::__1::__invoke<mbgl::Map::start(bool)::$_5>(mbgl::Map::start(bool)::$_5&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#10 0x0000000100142f8c in void std::__1::__thread_execute<mbgl::Map::start(bool)::$_5>(std::__1::tuple<mbgl::Map::start(bool)::$_5>&, std::__1::__tuple_indices<>) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:332
#11 0x0000000100142f7c in void* std::__1::__thread_proxy<std::__1::tuple<mbgl::Map::start(bool)::$_5> >(void*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/thread:342

Triggered by glEnable(GL_BLEND). This console spew appears earlier, while the app is in the background, and I believe it holds the key to understanding why we can’t simply treat -glkView:drawRect: as a funnel that we can guard:

2015-04-13 15:13:22.912 Mapbox GL[3863:513910] [DEBUG] {0}{Map}[General]: painter setup: 11ms
2015-04-13 15:13:49.609 Mapbox GL[3863:513779] Failed to bind EAGLDrawable: <CAEAGLLayer: 0x17002f820> to GL_RENDERBUFFER 1
2015-04-13 15:13:49.609 Mapbox GL[3863:513779] Failed to make complete framebuffer object 8cd6

@incanus
Copy link
Contributor

incanus commented Apr 13, 2015

The call to bind EAGLDrawable — is that our own call to bindDrawable or is it from somewhere else?

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 13, 2015

The console spew – and likely the call to bind EAGLDrawable – is coming from here:

#0  0x00000001830d75d0 in NSLog ()
#1  0x000000018333f7cc in -[GLKView _createFramebuffer] ()
#2  0x000000018333fd8c in -[GLKView _setFramebuffer:] ()
#3  0x000000018333ffe0 in -[GLKView _display:] ()
#4  0x0000000186657a34 in CA::Layer::display() ()
#5  0x0000000186638a7c in CA::Layer::display_if_needed(CA::Transaction*) ()
#6  0x0000000186638734 in CA::Layer::layout_and_display_if_needed(CA::Transaction*) ()
#7  0x0000000186637ebc in CA::Context::commit_transaction(CA::Transaction*) ()
#8  0x0000000186637c3c in CA::Transaction::commit() ()
#9  0x0000000186d817c8 in PrepareAppAndDoSpringboardSnapshottingWithBlock ()
#10 0x0000000186d811b4 in -[UIApplication _saveSnapshotWithName:] ()
#11 0x0000000186f884e4 in -[UIApplication _handleApplicationDectivationWithScene:shouldForceExit:transitionContext:completion:] ()
#12 0x0000000186f90dcc in __88-[UIApplication _handleApplicationLifecycleEventWithScene:transitionContext:completion:]_block_invoke ()
#13 0x0000000186f90d54 in -[UIApplication _handleApplicationLifecycleEventWithScene:transitionContext:completion:] ()
#14 0x0000000186f83fe0 in -[UIApplication scene:didUpdateWithDiff:transitionContext:completion:] ()
#15 0x000000018aac13c8 in __31-[FBSSerialQueue performAsync:]_block_invoke_2 ()

This kind of crash can only occur when the GLKView is part of the view hierarchy. With this PR, -[UIApplication _saveSnapshotWithName:] would instead cause an ordinary UIImageView to draw itself.

@incanus
Copy link
Contributor

incanus commented Apr 13, 2015

#10 0x0000000186d811b4 in -[UIApplication _saveSnapshotWithName:] ()

Ahhh, this is the OS taking its snapshot of the view, which requests a render, upon going into the background for its own multitasking switcher. I wasn't getting that before. I think this answers our question of who is operating outside the gated API for requesting view updates.

More: http://stackoverflow.com/a/18961652

@incanus
Copy link
Contributor

incanus commented Apr 13, 2015

At this point, I don't think there is an approved way to not have the OS take snapshots of our GLKView other than removing — or maybe obscuring it. @1ec5 what if we pop the UIImageView on top while setting opaque = YES or otherwise letting the system know that the GLKView will never be seen? Perhaps safer than actually manipulating the view hierarchy, since we could just hide or show the covering image view?

@1ec5
Copy link
Contributor Author

1ec5 commented Apr 14, 2015

I'll look into it, but even setting the GLKView's hidden = YES doesn't have an effect.

Generate the snapshot using `-[UIView snapshotViewAfterScreenUpdates:]` and place it _over_ the `GLKView`. UIKit appears to be able to detect that the `GLKView` is completely obscured and avoids `-_display`ing it.
@1ec5
Copy link
Contributor Author

1ec5 commented Apr 15, 2015

The key was to have the snapshot view obscure the GLKView, as @incanus suggested. Previously, I had only tried hiding the GLKView but not obscuring it. This appears to be a common enough scenario that there’s -[UIView snapshotViewAfterScreenUpdates:].

Just in case the host app mucks around with `MGLView`’s internal view hierarchy.
1ec5 added a commit that referenced this pull request Apr 15, 2015
Detach GLKView while app is in background
@1ec5 1ec5 merged commit ed74c6e into master Apr 15, 2015
@1ec5 1ec5 changed the title Detach GLKView while app is in background Obscure GLKView while app is in background Apr 15, 2015
@1ec5
Copy link
Contributor Author

1ec5 commented Apr 15, 2015

Meant to retitle this PR first. Just to clarify, the GLKView doesn’t get detached anymore; we just obscure it and keep from redrawing it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
iOS Mapbox Maps SDK for iOS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Crash locking while map is panning — renderSync()
3 participants