This change forces glyphs whose natural orientation in vertical writing
mode is 'sideways' to be rendered in upright orientation (only for non complex
text layouts). This is different compared to W3C / browser behavior that is by
default, renders glyphs in their respective natural orientation.
In the future, there might need to add a new layout property that would control
glyph orientation separately (e.g., text-glyph-orientation: natural | upright).
When using flyTo for easeTo:
Limit zoom out to min(startZoom, targetZoom).
Reduce cinematic zoom in animation at the end of transition,
Linear zoom interpolation.
The patch also sets linear interpolation for flyTo edgeInsets animation, as it looks more appropriate to follow the approach taken for pitch and bearing.
Fixes: #15144
Follow the approach from mapbox-gl-js for enabling opaque pass for background layer (same as for fill layer).
Fix combinations/heatmap-translucent--background-opaque render test.
ProjectedCollisionBox encapsulates geometry of the projected
collision box, it is using union and thus provides memory save
- 12 bytes per collision box instance.
Before this change, the `RenderTileSetSource` implementation
ignored update calls for the sources whose description was not yet
loaded and it lead to missing of relayout requests.
Patch partly fixes#15163 in a way that it doesn't allow loading tens of thousands of tiles and attempt to show area above horizon:
Limit pitch based on edge insets. It is not too bad - current limit of 60 degrees stays active until center of perspective is moved towards the bottom, to 84% of screen height. The plan is to split removal of 60 degrees limit to follow up patch.
Fix max Z calculation in getProjMatrix. TransformState::getProjMatrix calculation of farZ was complex with possibility to lead to negative z values. Replacing it with simpler, precise calculation:
furthestDistance = cameraToCenterDistance / (1 - tanFovAboveCenter * std::tan(getPitch()));
TransformState::getProjMatrix calculation of farZ was an aproximation. Replacing it with simpler, but precise calculation.
Related to: #15163
Before this change, `RenderOrchestrator::filteredLayersForSource` shrank inside
`createRenderTree()`, which potentially might have affected rendering performance.
This PR filters out invisible layers before quering features
(rather than after, like it happened before).
With this change `API_queryRenderedFeaturesAll` performance test
passes almost two times faster.
Once the algorithm finds the center of the line, if placement is
not possible, do not place the anchor.
Previous code was trying to continue place the label beyond the center
of the segment.
Fixes#15139.
Change in 3ffc14a325
was a typo while addresssing review nit: while it didn't affect render tests it doesn't work properly in all cases.
Fixes: #14844, #14779, #15039
Viewport center offset usage was wrongly submitted in #14664. It was part of alternative approach that used enlarged viewport. Existing and added tests were not sufficient to spot the regression, since the collision check padding is usually larger than the center offset x and y. Annotation picking has tolerance of only 10 pixels but no annotation integration test was using content insets.
Usage of offset is not needed because `posMatrix` in e.g. `CollisionIndex::projectPoint(const mat4& posMatrix, const Point<float>& point)` already incorporates center offset (projection matrix) and the code in current master was just offsetting all by the value.
Modified [ios] MGLAnnotationViewIntegrationTests.testSelectingAnnotationWithCenterOffset to use different insets. It verifies the fix.
Fixes [iOS] Annotations are not selectable (added via iosapp menu) #15106:
In case of #15106, view's original content insets is {top:88, bottom:34}, causing that center offset is {x:0, y:27} and selection with tolerance of 10 wouldn't select annotation.
After tapping the view, so that the header gets removed, view's content insets get changed to {top:44, bottom:34}, center offset is {x:0, y:5} and annotation selection would work, as described in #15106.
Fixes: #15106
Before this change render passes were assigned for the
whole layer at properties evaluation stage.
This caused problems, as layer render data are bound
to the tile and these data might differ from tile to
tile, depending on which tile has been updated by the
tile worker and which has not been yet updated.
This change takes into consideration the actual render
passes required for each tile and combines them for
the layer render passes. Naturally, this change also
introduces render pass check for each render layer in
`RenderLayer::render()` implementations.
The changes introduced in #9199 changed the minimum required pixel distance between start and end points to >= 1px in order to interpolate, which in scenarios of big zoom changes and low pixel density can result in animation to the previous position and then a jump to the target.
This fixes following issues:
* Fix some false passing combinations/fill-extrusion-translucent--XXXX tests
* Fix and enable other, failing but ignored, combinations/fill-extrusion-translucent--XXXX tests
* Fix rendering of layers that are on top of fill-extrusion layers
state.getProjMatrix(nearClippedProjMatrix, 100) caused that tests with size 64x64 were not
rendering fill extrusions: far plane calculated as 96.9 and near plane set to 100 was the cause.
near plane is changed from hardcoded 100 to depend on state.getCameraToCenterDistance() - producing
similar value but one that follows max zoom.
This caused that e.g. combinations/fill-extrusion-translucent--fill-opaque was falsely passing as
only fill-opaque layer got rendered.
combinations/fill-extrusion-translucent--XXXX tests expose regression https://github.com/mapbox/mapbox-gl-native/issues/14844#issuecomment-503600034 in #14844, #14779.
Fix (opaquePassCutoff, is3D) is ported from https://github.com/mapbox/mapbox-gl-js/pull/7821Fixes: #14844, #14779, #15039
