* Add symbol dds attributes and adapt style code generation
* Update to mapbox-gl-js/master
* Refactor SymbolFeature as a subclass of GeometryTileFeature
Prepares for enabling DDS on symbol paint properties by allowing the
SymbolFeatures, which we keep around after constructing SymbolLayout,
to be used in evaluating data-driven paint properties later in the
layout process.
* Draft approach for splitting icon/text paint properties
The `Program` types are set up to bind GL attributes to each of the
data-driven paint properties specified in the `PaintProperties` type
provided. Since `SymbolPaintProperties` specifies both `Text*` and
`Icon*` properties, the symbolIcon, symbolIconSDF, and symbolGlyph
programs each attempt to bind roughly double the number of attributes
that they actually need.
This change addresses this by:
- Adding the more specific `IconPaintProperties` and `TextPaintProperties` types, which are subsets of the full `SymbolPaintProperties`.
- The symbol layer continues to use its `SymbolPaintProperties paint` member to track layer property state, but it provides helpers that construct objects of each the specific `{Icon,Text}PaintProperties::Evaluated` type, for use by the painter.
- The three symbol programs instantiate `Program<>` using the appropriate `{Icon,Text}PaintProperties` type.
* check in generated style code
* Populate paint buffers for symbol DDS properties
* Address first round of review comments
* Refactor VectorTile{Layer,Feature} to explicitly share data
* Update submodule
This leverages the work already happening in `mbgl::style::conversion` to convert style functions from style-spec definitions into `mbgl::style::{Camera,Source,Composite}Function`s. In particular, this allows the conversions system to handle the differing typing requirements based on whether the output type of the style function is interpolatable or non-interpolatable.
ported from -js: eb6c6596c6a7a61363d30356674e0002153b1d19
`altitude` was a terribly-named variable that was used to indirectly
control the fov. This should eliminate some confusion.
`altitude` was equivalent to `cameraToCenterDistance / height`
* [ios, macos] Replaced custom style layer API with MGLOpenGLStyleLayer
Replaced the custom style layer API on MGLMapView with an equally unsupported MGLOpenGLStyleLayer API that nonetheless is consistent with the broader runtime styling API and is compatible with macOS.
Fixed an unrecognized selector crash when wrapping a layer of unrecognized type coming from mbgl.
* [macos] Added lime green layer demo to macosapp
Reprised the demo removed from iosapp in #5091.
* [ios, macos] Rationalized MGLOpenGLStyleLayer API
MGLStyle now strongly references any MGLOpenGLStyleLayer object that’s added to it, in order to prevent pointers from going stale and make it easy for layer drawing code to get more information about the map view. Replaced the MGLOpenGLStyleLayer callback blocks with overridable instance methods. Added internal documentation for each method. Subclassed MGLOpenGLStyleLayer as LimeGreenStyleLayer inside macosapp.
Consolidated -addToMapView: into -addToMapView:belowLayer: to ensure that MGLRedundantLayerException gets raised even if the layer is being inserted rather than added to the bottom of the stack.
* [core] Clarified that rendering happens on the main thread
* [ios, macos] Fixed removing and re-adding MGLOpenGLStyleLayer
Don’t allow index-based layer removal to circumvent -removeFromMapView:, which MGLOpenGLStyleLayer relies on to synchronize the style’s array of MGLOpenGLStyleLayers. When obtaining an MGLOpenGLStyleLayer, get the instance already added to the style instead of creating a new one to wrap the underlying CustomLayer.
This converts the style property classes (CirclePaintProperties and so on) to the same tuple-based approach as gl::Attribute and gl::Uniform. The approach is outlined in https://github.com/mapbox/cpp/blob/master/C%2B%2B%20Structural%20Metaprogramming.md.
The main advantage of this approach is it allows writing algorithms that work on sets of style properties, without resorting to code generation or manually repetitive code. This lets us iterate on approaches to data-driven properties more easily.
Another advantage is that the cascading, unevaluated, and evaluated states of a set of properties exist as independent structures, instead of individual properties holding their own state. This is a more functional approach that makes data flow clearer and reduces state.
This paves the way for updates to filter and layout properties to trigger a source reload, without each SDK having to participate in the implementation.
* [core] geometry.hpp 0.8.0
* geojsonvt @ 6.0.0
* Update platform deps, build scripts
* Perf optimizations/cleanup
* Rebase in geometry@080
* D.R.Y. etc
* Ensure fill annotation geometries have closed rings.
* Optimizations
* Update to geojsonvt @ 6.1.0 for clean handoff between geojson parsing and geojsonvt
* Apply close multi/poly geoms for line annotations as well
* Layer source ID is immutable; must be provided to the constructor
* Layer source layer is mutable
* Layers with GeoJSON sources do not have a source layer
While here, make Layer::copy impl-private.