The following produces a reference cycle:
var map = new mbgl.Map({
request: function () { ... }
});
map has a reference to the request function, which has a reference to
its closure, which has a reference to map.
Storing a the map options in an internal field, rather than a Persistent,
allows V8 to collect the reference cycle when none of its members have
other references.
A hack atop the hack added in #2632. Pre-declare `styleURL__` with an attribute that prevents it from appearing in code completion suggestions, while leaving it available to Interface Builder, which is unable to parse attributes.
As of #2746, we no longer bundle any styles with the SDK, so the asset: URL scheme is unused. Instead, point asset: to the application root for developer convenience and consistency with the Android and default asset roots. Also fixed an issue that prevented relative URLs from being treated as asset: URLs.
Fixes#1208, fixes#3050.
The previous fix resulted in annotations sometimes never being added.
This would happen if, during the execution of MapContext::update where
Update::Annotations was set, the style itself was loaded but some of
its subresources (sprite or sources) were not.
#3082 is a follow up issue to make MapContext::update less error-prone.
ConstrainMode gives flexibility to our engine to choose between
constraining both vertically and horizontally, or just vertically
(default behavior).
Constrain in both axis means we can no longer pan the map beyond the map
boundaries. This fixes an issue where e.g. annotations disappear upon
crossing the map boundaries.
LatLngBounds southwest and northeast coordinate points were inverted, so
they could be extended via LatLngBounds::extend(). However, this looks
confusing and error-prone.
A static LatLngBounds::getExtendable() is added to address cases when we
want to extend LatLngBounds.
In MapContext thread, TransformState gets updated from main thread to
MapContext and Painter can safely reference MapContext's TransformState
instead of copying it upon each Painter::render call.
The doubly nested lambda that's responsible for executing the callback
needs to check the cancellation flag on *both* threads. See comment for
details.
Only the WorkTask mutex needs to be recusive because
the WorkQueue will run a WorkTask that will pop
itself from the WorkQueue causing it to get cancelled.
