Combination of padding and pitch lead to unexpected results

[rinigus]

Platform: Linux, Qt 5.14
Mapbox SDK version: git master; d4af66e

Summary

When adding non-zero padding to the camera, there is interaction between zoom and pitch settings that is not expected (shown below). With zero pitch, zoom stays the same regardless of of the padding, as expected.

As it is shown below, effective pitch becomes larger than 60 degrees making the application slow and unresponsive.

This issue was not present in QMapboxGL incorporated into Qt as a location module.

In this application (Pure Maps), padding is used to push the center of the map towards button when the user is navigating. While just exploring, padding is set to small leading to the map center being in the center as well.

Steps to trigger behavior

1. Set pitch to 60 degrees, select location, zoom (16 for example)
2. Use smaller window, like 600 x 600 pixels
3. Compare results without padding (padding 0) and padding with the center towards the bottom of the screen. In my case, padding was 450 from top, 29 from bottom, 30 from left and right.

Expected behavior

Despite padding, scale and pitch would be the same as in the map without padding.

Actual behavior

Results are dramatically different and it is not clear how to compensate for it.

Map without padding, zoom 16, pitch 60 degrees:

Map with larger padding, zoom 16, pitch 60 degrees:

Map with larger padding, zoom and pitch found to match map without padding:

To match the map without padding, I changed zoom and pitch in the map with padding. Result was zoom ~16.6 and pitch ~52 degrees

[astojilj]

I'll need to split this:

1. asymmetric viewport

Hope this would clarify the asymmetric viewport design: #15163 (comment)

In short:
Despite padding, scale and pitch would be the same as in the map without padding. is correct: padding moves expected scale and pitch out of the screen center. That is why in screen center we expect to get different content.

One could get to the previous behavior by offsetting viewport center and not using padding #15163 (comment).

2. performance

As it is shown below, effective pitch becomes larger than 60 degrees making the application slow and unresponsive.

Related to performance, we have LOD integrated #16335 but it is not yet taken into use for this case, apparently. Let's track the status at #15163.

[rinigus]

Thank you very much for explanation of the design, that helped. However, what's not clear why the pitch is changing when I specify padding. I am quite convinced that there is a difference in ~10 degrees in my case. Or did I miss something in your explanation?

[astojilj]

It is in collapsed section of this comment #15163 (comment).

Expanding it here:

I have cut center + upper part of no-inset screen (1 on the picture), moved it down where it should be rendered as expected by content inset, and combined it with upper part(2) of inset screenshot. They fit perfectly (3rd image from left, if zooming you'll be able to see icons at 30% hight of the top, part of cut (1)).

Screenshot with large top Inset now doesn't look good and has severe performance issue because upper part is too busy: tiles at the top are showing way too much details compared to central or bottom area. As work on mapbox/mapbox-gl-js#8975 progresses, let me provide more details/screenshots, with the same center (52.510361, 13.389938) to back up this claim.

[rinigus]

When repeating your exercise, I took new screenshots with and without padding. Placed a center on a shown object (tree indicating park) and pasted left top quarter of the map taken without any padding on image with padding.

As you can see, results are different. While on the bottom, pasted section matches (so zoom is the same), following the streets on the vertical border you could quickly see the discrepancy. Strangely, though, I would read that the pitch is lower here in the pasted area (in the map without padding).

Or do we have some kind of curvature effects towards the top of the map?