Moved mbgl::util::default_styles to a more appropriate location, where iOS platform code can also find it. Moved -[MGLMapView bundledStyleURLs] (which is now deprecated) and the style switcher in iosapp to default_styles.
Added a collection of convenience methods for getting style URLs. It makes little sense to layer an enum atop this, as MapKit does, because MGLMapView styles aren’t limited to this set. A good analogy is UIColor. This also makes for a good entry point for future runtime styling APIs.
Introduced independent constants for each default style, because it’s more common to need access to a particular style than to iterate over them. This fact is apparent in the MGLStyle class, which now uses macros and assertions to ensure that it’s kept up-to-date with changes in default_styles.
/ref #1462
This fixes adding shape annotations after VectorTileData objects have
been created for annotations already, and will also be necessary for
the dynamic Style API.
To encapsulate the differences, this introduces an abstract
GeometryTileMonitor class, with concrete VectorTileMonitor and
AnnotationTileMonitor implementations, and makes pbf parsing for
VectorTile data happen lazily in getLayer, since we want that to
happen on the worker thread, rather than when VectorTile is created.
Fixes#2792
The location under your finger stays under your finger as you pan.
The location you double tap to zoom stays at the same point.
The location at the center of a pinch zoom stays at the center.
The location at the center of a rotation stays at the center.
We're now reparsing tiles when they expire. We're also swapping out buckets atomically to avoid flickering data; i.e. we're displaying the old data as long as we don't have a new parsed bucket for that layer yet. The parsed buckets now live in the *TileData objects rather than in the TileWorker; only partially parsed == pending buckets will remain in the TileWorker. Once they're parsed, they're moved to the *TileData object.
It's not implemented in GCC 4.9.2's stdlib (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57250). Instead, we're now always using a mutex to protect access; we previously created a mutex only on cancelation, but since we're always canceling now, it makes sense to allocate it right away.
When we get a request with an explicit expiration time, we're now starting a timer, and will trigger a refresh once the data expires. This gives requesters a chance to update their data.
We're now returning stale responses from cache. Those responses will have the `stale` flag set to true. Currently, all requesters in the core code discard stale responses, and cancel the request immediately after they got a non-stale response.
By not automatically destroying Request objects after the result has been delivered, we are making sure that we can potentially fire the callback multiple times without adverse effects. This means that you have to hold on to the result of fs->request(), can explicitly cancel it if you don't want to be notified of data changes anymore. Not doing so will monitor the request indefinitely and will prevent the app from exiting.
MapData was needed for two things: getting the default transition and
fade durations, and detecting still rendering vs. continuous.
The first is avoided by making transition durations optional, and
supplying the default fallback value at evaluation time. The second did
not fix the still rendering issue, and will be followed up with a
different approach in a later commit.
Adding new mbgl::GLContextMode enum to mbgl::Map ctor, which gets stored
in MapData. In shared GL context environments, we cannot assume that the
GL state that has been left since the last draw is the same, so we reset
the GL configurations to their default values.
Some property transitions were being set to their fallback values when
no classes are being used. This issue is particularly perceived when the
default transition duration is not zero (animated transitions).
Attempting to use a Mapbox-hosted incompatible raster map/style with GL
would throw a simple 404, without any indication of the real issue.
Fix#1724, ref #1841
