* [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
Simple tests that will render a raster and a vector map and
hopefully the valgrind bot will detect something wrong if any.
The other test will look for application lifetime leaks that cannot
be detected with valgrind. It can also detect GL leaks if they are
very expressive. A threshold is needed because of memory will grow
anyway due to fragmentation.
The StupFileSource of the memory test will do the rendering
completely offline with a vector tile that is densly populated
with features and a raster tile of the same region.
The styles are streets and satellite respectivelly.
add outlinepattern shader class to relevant files
add outlinepattern code to painter_fill.cpp
add outlinepattern code to fill_bucket
refactor painter_fill, fix tests
fix merge conflicts and setDepthSublayer
update render test to no antialiasing so travis will be happy
Now it works more like StubStyleObserver: you can assign std::functions to specific slots based on resource type.
Rewrite resource loading tests in that style, making them less like integration tests of Style and more like unit tests of Source, GlyphStore, and SpriteStore.
This reverts commit 6709bdcacd.
There was an issue with the script that removes '-lwebp' from WebP
linker flags, since we're statically linking. This is now fixed.
Updating glyphs is still unsupported, and there's no good use case for doing so. When we're using a stale glyph PBF, and the fresh answer contains changed to that glyph, we will continue to use the old glyph.
This is a naïve implementation that essentially merges updated data into existing data. It will *not* remove icons from the stale sprite if they aren't present in the fresh sprite (we aren't tracking the source of a sprite, and the user could have changed it as well). Similarly, it will not update icons that have changed in dimension. This is a rare edge case and probably not worth implementing.
We're now supporting using stale TileJSON and GeoJSON data. When we receive a new answer with an updated TileJSON file, we're replacing the Source's metadata with the new one and trigger updates to make sure we're loading the correct tiles. Similarly, GeoJSON data will be reparsed.
This adds support for using cached styles that are stale. They're treated like changing styles; when the refreshed style changed compared to the one we've already had, we're swapping out the entire style, which might cause a slight flicker.
I regenerated assets.zip so that all file paths have an `assets/` prefix, as the Android AssetFileSource implementation asserts, and removed `TEST_DATA` from the paths.
* Move asset:// URL handling to DefaultFileSource.
* AssetFileSource implements FileSource interface and follows familiar implementation patterns.
* Move default implementation to platform/default, zip implementation to platform/android.
* Don't bother with modified / expires / etag -- assets are not cached so it doesn't matter.
* Don't bother with interleaving individual IO calls on the implementation thread. That adds a lot of complexity for very little benefit.
