- we're now always loading and parsing styles in the map thread
- adds an atomic enum that stores the actual updates we need to perform
- adds a MapData object that mutexes access to variables used from both threads
On iOS, the main thread does framebuffer operations just before it requests a rerender of the view contents. This means that GL operations on the Map thread will interfere with that and cause a crash. While most GL operations happen throughout rendering (which is synchronized with the main thread), deletion of shared_ptrs release in turn their OpenGL objects. This may happen at any time and isn't synced with rendering.
This patch changes this so instead of deleting all objects immediately, we are collecting all abandoned IDs and delete them in bulk once the main thread has given us permission to use OpenGL calls (i.e. during render()).
When using Valgrind for debugging memory leaks and access violations, we
often see a lot of false positives, specially when dealing with OpenGL
that does it own buffer management. This file is an attempt to filter
these false positives.
Note that we are only filtering for the open source Radeon driver and
the list will probably grow to accommodate other setups.
To use the Valgrind with the suppression file for hunting memory leaks,
try something like:
valgrind --leak-check=full --track-origins=yes --suppressions=[path/to/valgrind.sup] ./mapbox-gl
This podspec was originally lifted from mapbox/mapbox-ios-sdk, which was structured and built quite differently. We could have the podspec build this repo as is, using scripts/package_ios.sh, but that would require developers to install the same version of Xcode as Travis is using (see #977). So this podspec instead pulls a prebuilt library. Much simpler.
Also package a LICENSE with the archive to satisfy a CocoaPods warning.
Fixes#829.
As a best practice for the beta and a workaround for #1014.
Also reversed the argument order of the existing init method. Reads better this way, but you’ll likely have to change your initialization to match the new signatures.
To make it easier to debug, add the Environment ID and the Thread name
to the log messages. For instance log messages from the TileParser will look like:
[WARNING] {0}{TileWorker_15/18653/9486}[ParseTile]: some relevant warning message
| | | |
| | | +-> Component
| | +--------------------> Thread name
| +----------------------------------> Environment ID
+------------------------------------------> Severity level
Log messages that are not inside an Environment::Scope will work
normally and will look like:
[WARNING] [JNI]: some relevant warning message
Fixes#882.
