Center location maker in bottom half of screen in routing mode

[ecgreb]

1. First the map position is set based on the device current location.
2. Second screen width and height for the device are queried using the WindowManager.
3. Once the map is centered on the current location then new LngLat coordinates are calculated for the adjusted position using MapController.coordinatesAtScreenPosition(screenWidth/2, screenHeight/4).
4. Finally, the map position is set again using the new adjusted coordinates.

While successfully centering the route location marker in the bottom half of the screen this solution has the side effect of causing the map to flicker due to setting the map position twice in rapid succession.

@blair1618 @tallytalwar @karimnaaji is there a way to delay rendering until the final coordinates are calculated? Or is there a better approach we can use to implement this feature?

Closes #105

[matteblair]

Nice, the approach you've found is pretty clean. Getting it to reliably update in one frame might be the trickier bit.

Unless a stylesheet requires some kind of animation, tangram-es will render on-demand, meaning that when a parameter or datum is changed that will impact the image on screen, a render is requested. I say "requested" because the actual rendering happens on a dedicated thread, separate from application logic.

What's likely happening in this case is:

• the first position setter kicks off the rendering thread to start a new frame
• the subsequent setters request re-rendering while the rendering thread is busy drawing the scene using the first position
• when the rendering thread finishes drawing, it fulfills the requested re-render and draws the scene again using the second position

The outcome is that you will see the map drawn at the first position for one frame or so and then immediately snap to the second position. Two solutions come to mind:

1. Calculate the final LngLat using the view parameters and set the map position once. This adds some complexity to the code, depends on knowing the camera type in the stylesheet, and may not fully solve the problem anyway since setters besides position would also request re-rendering.
2. Expose a pause setter for tangram-es. This would add a new public function to manually stop and start the normal re-rendering behavior; in code like this where re-rendering is problematic, you could prevent over-zealous updates by pausing and then un-pausing the renderer.

Option 2 seems pretty reasonable to me right now, I'm open to ideas from others too.

[ecgreb]

Can we add a method to the MapContoller to get the hypothetical map bounds without actually rendering the result?

For example:

public List<LngLat> MapController.getBoundsForPosition(LngLat mapPosition)

The return value would be a list with 4 elements representing the LngLat coordinates for the four corners of the screen if the map were to be rendered at the given position. Based on these values we should be able to calculate the adjusted position.

[matteblair]

I believe we can add this "position forecasting" to tangram. Additionally, to be sure that we're not triggering spurious renders, we can add a combined setter for all of the view parameters.

I'll let you know when we've got something in tangram that you can use.

[matteblair]

With a small addition to tangram-es, I've implemented this view adjustment without stuttering over here: https://github.com/mapzen/eraser-map/tree/matt/105-route-position-offset

The new MapController.queueEvent(Runnable r) can be used in any cases like this where you need to make multiple changes to the view in sequence - they'll be executed on the render thread without interruption.

[tallytalwar]

👍 Nicely done @blair1618.