mapbox / mapbox-gl-native

Interactive, thoroughly customizable maps in native Android, iOS, macOS, Node.js, and Qt applications, powered by vector tiles and OpenGL
https://mapbox.com/mobile
Other
4.37k stars 1.33k forks source link

Shape annotation z-order is reversed #5691

Closed 1ec5 closed 8 years ago

1ec5 commented 8 years ago

We have a proof-of-concept application that draws an arrow on a route line at the location of each maneuver. Because the arrow’s stem must follow the path of the route even as it twists and winds, the arrow is implemented as a couple of polylines instead of a point annotation or annotation view. Because a polyline can only be stroked, not outlined, we’ve implemented the arrow as two similar pairs of polylines, a thinner, white pair of polylines atop a thicker, blue pair.

Here’s a patch to iosapp and macosapp that draws the arrow the way this proof-of-concept application does. This is what it’s supposed to look like, seen here in aa1a54c577a95082824f2a5a6bdf4948506fcaa9 (ignore the fact that it’s backwards):

aa1a54c

8985b1311b7d00cf761752bd9291566325ae207a introduced a regression that incorrectly closed each polyline:

cfd6757

0fba70d5a8465499b0dce900e5aa74f7189e4594 introduced another regression that reversed the z-order of the polylines:

0fba70d

As of 44406e91de97132e18494fb1d3353ce00726f192, the polyline-closing bug has been fixed, but the z-order bug remains:

master

In some cases, we’ve seen mixed behavior:

screen shot 2016-07-11 at 6 59 18 pm

What should happen is that each added annotation is drawn above the annotation that was added before it.

/ref #5200 /cc @jfirebaugh

jfirebaugh commented 8 years ago

I think prior z-ordering behavior of shape annotations was mostly accidental rather than an intentional API contract, but I can see how it's desirable. I bet reverting these unordered_maps to map would restore the prior behavior.