Closed 1ec5 closed 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_map
s to map
would restore the prior behavior.
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):
8985b1311b7d00cf761752bd9291566325ae207a introduced a regression that incorrectly closed each polyline:
0fba70d5a8465499b0dce900e5aa74f7189e4594 introduced another regression that reversed the z-order of the polylines:
As of 44406e91de97132e18494fb1d3353ce00726f192, the polyline-closing bug has been fixed, but the z-order bug remains:
In some cases, we’ve seen mixed behavior:
What should happen is that each added annotation is drawn above the annotation that was added before it.
/ref #5200 /cc @jfirebaugh