Map view is slow to respond to some gestures and fly animations

[boundsj]

The panning / flyto slowness we've been observing on master and agua seems to be because of some underlying performance problem related to an internal framework method (_updateConstraintsAsNecessaryAndApplyLayoutFromEngine) to update constraints. We were exposed to this in #9995 by setting _scaleBar.translatesAutoresizingMaskIntoConstraints = NO;.

However, this was not actually a problem before the last merge but something about the rendering interface updates done back in b6d56ad trigger this problem and are driven by repeated calls to -[MGLScaleBar setMetersPerPoint:] in -[MGLMapView cameraIsChanging].

We see this problem now after the merge since all of the commits to trigger it are in place (there is no problem with the merge itself). The constant updates to the scale bar's frame triggered by the renderer / camera / gesture updates are just too much.

cc @frederoni @1ec5 @fabian-guerra @ivovandongen @lilykaiser

[boundsj]

I see that Apple Maps actually shows the scale bar far less than we do (only when the user does a two finger zoom gesture). I've tested and copying that UX works around the issue described here since, if the scale bar is not visible, the setMetersPerPoint: message is never sent. I'll make a PR for that workaround.

[1ec5]

I see that Apple Maps actually shows the scale bar far less than we do (only when the user does a two finger zoom gesture).

That’s the case by default, but the scale bar is always visible when showsScale is true.

[frederoni]

Can we have another range index so we don't have to find the preferred row or limit the number of calls to setMetersPerPoint: by rounding?

[boundsj]

That’s the case by default, but the scale bar is always visible when showsScale is true.

Good point. Let's not implement that workaround I mentioned before then.

Can we have another range index so we don't have to find the preferred row or limit the number of calls to setMetersPerPoint: by rounding?

That may be a good / the best? idea. For now, I've proposed this workaround that fixes the UX issues (slow flyto and panning)

[boundsj]

I spent more time today digging into why the renderer changes triggered this issue. I think #10277 may be a better approach.