| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
file requests.
Fixes issue #12655: don't let offline downloads starve interactive tile downloads.
|
|
|
|
| |
When creating a offline region, we've previously only requested the sprite image for the specified resolution. This lead to offline packs not being usable on devices that have a different pixel ratio. We're now requesting both 1x and 2x sprites. Some devices use even higher or fractional pixel ratios. However, we only ever use 1x and 2x sprite images in our requests.
|
|
|
|
| |
We optimize our updateRenderable algorithm by breaking ascent when we've already checked a certain tile. So far, we've compared the UnwrappedTileIDs, but they don't include the overscale component. When ascending through overscaled tile IDs, we've stopped the ascent too early, when we should've kept the search going.
|
| |
|
| |
|
| |
|
|
|
|
| |
expressions in `*-pattern` properties
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Fixes issue #12472.
This commit doesn't address the underlying issues that come from symbolAnnotationTree using a slightly lower precision coordinate system than the annotations themselves.
Instead, it just puts a small padding around each tile when it queries for tile data, so that symbols right at the tile boundary will be included in both tiles.
The rendering/querying code will take care of only displaying one instance.
The padding is in global coordinates, so at higher zoom the padding will be larger in tile units -- this is consistent with precision loss also being greater at higher zoom.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 990b3b11b9427ffd86f693d3f4c3dd351891e5d0.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This patch also bumps geojson-vt-cpp version to 6.6.0,
which enables the `lineMetrics` option.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the compilation errors on QNX 7:
1) QNX 7 compiler (i.e qcc based GCC 5.4.0 with libc++ from LLVM) has a
limited c++11 feature support and causing the compilation
errors with the inheriting constructors. This fixes the issues by
providing the required constructors explicitly.
2) Resolves an ambiguous overload error with optional<T>
|
|
|
|
| |
A mismatch can occur when a layer changes from one type to another.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
all point arrays as rings. Simplify the logic to only compare against
the next pt in the bound.
|
| |
|
| |
|
|
|
|
| |
Fixes issue #12104.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
|
|
|
|
| |
Cross platform parsing and evaluation code.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Legacy filters aren't part of the style specification, but you can generate them by parsing a legacy filter in a stylesheet, and obtaining the parsed Filter and serializing it.
|
| |
|
|
|
|
|
|
|
| |
* Eliminate unnecessary temporary in VTableStack::move, which also fixes calling the destructor on the incorrect instance
* Make move consistent: it destructs the src, not the dest, which is always empty
* delete doesn't need a null guard
* Conversions to void* don't need a cast
|
|
|
| |
Polymorphic types shouldn't be caught by value, as the warning message says. Catch them by constant reference instead.
|
|
|
|
|
|
|
|
| |
Before this change, we've tried to open the database in read/write, but not create mode. In situations where the database didn't exist yet, this logged an error to the console, and we proceeded to opening it again in read/write/create mode, which actually created the file. The reason we did this is so that we could detect really old caching databases from January 2016 in case a developer upgraded from an older SDK (iOS v3.1 and earlier, Android v3.2 and earlier) that didn't have https://github.com/mapbox/mapbox-gl-native/pull/3715 yet.
However, these error messages, while innocent, look scary in the console and some users suspect that it's a bug. This change opens the file directly in read/write/create mode, omitting the first failed attempt. To handle old cache databases, we're now deleting the `http_cache` table, which was the only table in those old databases, and create the new schema, rather than deleting the entire file and recreating the Database object. In most scenarios, this will lead to one fewer opening attempt, while the database migration will continue to work for the few users who upgrade all the way from a January 2016 SDK.
Additionally, this fixes a mismatch between the Qt and non-Qt implementation: Qt doesn't support opening a file in read/write mode without the create flag. This means that we've seen a different control flow on Qt compared to the non-Qt implementation when opening a database.
|