summaryrefslogtreecommitdiff
path: root/src/mbgl/style/layout_property.hpp
Commit message (Collapse)AuthorAgeFilesLines
* [core] cascade ⇢ transition / cascading ⇢ transitionableJohn Firebaugh2017-05-151-2/+2
|
* [core] Unify {Paint,Layout,Light}PropertiesJohn Firebaugh2017-05-151-91/+4
|
* [core] Move render-related sources out of style directory/namespaceJohn Firebaugh2017-05-031-3/+4
| | | | | | | | | | | | | | | | Moves the following to the renderer directory and out of the style namespace: * CascadeParameters * PropertyEvaluationParameters * UpdateParameters * PropertyEvaluator * DataDrivenPropertyEvaluator * CrossFadedPropertyEvaluator * PaintPropertyBinder * PaintProperyStatistics * PossiblyEvaluatedPropertyValue * TransitioningLight * EvaluatedLight
* [core] Add DDS support for text-rotateJohn Firebaugh2017-03-311-3/+3
|
* [core] Introduce a fully-evaluated tuple type for layout propertiesJohn Firebaugh2017-03-311-12/+54
|
* [core] default value support in categorical function conversionIvo van Dongen2017-02-021-0/+11
|
* [core] Add support for data-driven stylingJohn Firebaugh2017-02-021-1/+12
|
* [core] Convert style properties to a tuple-based approachJohn Firebaugh2016-11-171-26/+38
| | | | | | | | 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.
* [core, node] Implement bindings for addLayerJohn Firebaugh2016-06-241-7/+0
|
* [core] Rationalize naming for style-related codeJohn Firebaugh2016-06-021-1/+3
|
* [core] Introduce PropertyValue<T>John Firebaugh2016-06-021-8/+22
| | | | PropertyValue<T> represents the three possible types of style property value: undefined, constant, or function.
* [core] Runtime style layer APIJohn Firebaugh2016-06-021-2/+0
|
* [core] use #pragma once instead of ifdef include guardsKonstantin Käfer2016-05-251-4/+1
|
* [core] Simplify property parsingJohn Firebaugh2016-04-261-1/+1
| | | | This is a followup to #4811. Now that use of Function is consistent, we can have a single separate parseProperty template function that delegates to a parseConstant template function.
* [core] Extract Function::evaluation to a separate class (#4811)John Firebaugh2016-04-251-1/+3
| | | This allows the Function<Faded<T>> partial specialization to be eliminated, giving all property functions a consistent storage type.
* [core] Use experimental optional instead of mapbox::util::optionalJohn Firebaugh2016-01-191-1/+1
|
* [core] change RapidJSON usage to use CrtAllocator and bump GeoJSON VTKonstantin Käfer2015-12-141-5/+3
|
* [core] Make Paint/LayoutProperties constructor explicitJohn Firebaugh2015-12-071-1/+2
|
* [core] add std::move to constructorsKonstantin Käfer2015-12-031-1/+2
|
* [core] add namespace comment to closing braceKonstantin Käfer2015-12-031-1/+1
|
* [core] Eliminate use of ClassProperties for paintJohn Firebaugh2015-11-101-1/+1
|
* [core] Eliminate use of ClassProperties for layoutJohn Firebaugh2015-11-101-0/+38