RMMark, RMPath "vibrate" while the RMMapView is being scrolled

[mouse4d]

while scrolling the map the RMMarker and RMPath overlay "vibrates", it's like the overlay tries to "catch up" with it's normal position when the map is scrolled. It's just a few pixels, but when zoomed it looks pretty bad. this happens most probably because the -draw() method is called only when the map is moved more than just a pixel.

[incanus]

For RMPath, see #73.

For RMMarker, I haven't seen this. Do you still see it when not using a path/shape with your markers, and if so, when using RMShape instead of RMPath?

[incanus]

I at least can see this now. Will try to address soon.

[incanus]

Assigned to Tender discussion #259.

[cga-F4]

Hi, I tried to see where this problem comes from.
With high zoom level, we see that the tile layer moves pixel by pixel while the RMMarker moves only 4 by 4 pixel.
I log some info in the function in RMMapView

• (void)observeValueForKeyPath:(NSString *)aKeyPath ofObject:(id)anObject change:(NSDictionary *)change context:(void *)context
  and we see that we are called each time the tile layer is moved, but the .contentOffset value from the change variable is the same and only changed 4 by 4 pixel. The _mapScroolView.contentOffset follows the same : it does not change pixel by pixel, but 4 by 4 pixel.
  Maybe this is because, with high level zoom, the contentSize and contentOffset are really big value (and there are float), and Apple scrollview does not support accurate move on big big contentOffset/contentSize.

I hope this can help you find a fix for this issue.

[davidovitch1]

same problem here, any news ?

[cga-F4]

Since last time, i tried using Alpstein Route Me, and we see the same problem with their example MarkerMurder. When you zoom to max, you see the marker vibrating (in this example, you can set the maxZoom to 22, and on maximum zoom, the markers vibrates much more).
I saw the layer with annotations is not in the RMMapScrollView *_mapScrollView. Would it be a bad idea or lots of work to have the RMMapOverlayView *_overlayView and the _tiledLayersSuperview in the same scrollView ?

[cga-F4]

I see the problem : when I am on level 19 zoom, and I look to Paris, France, my contentOffset has a value more than 60 000 000. When scrolling, we want to add 1, 2, 3 ... pixels to this value. But due to float precision, 60 000 000 + 1 returns 60 000 000 and 60 000 000 + 3 returns 60 000 004. We have a precision to 4 digit, so we see the annotions move only 4 pixels by 4 pixels. All because contentOffset is a float value (not double). [ By the way, I don't know how the _mapScrollView handles this by itself for the tileLayer which moves perfectly good, maybe the OS computation is in double but we can only access the contentOffset with float precision]
One solution would be to ensure that our contentOffset does not go further than the float precision limit.
From this post : http://stackoverflow.com/questions/1576126/iphone-and-floating-point-math, we can see that if we want a 1 pixel precision, we need to keep contentOffset under approximatively 8 000 000 (log2(8000000) = 22.93 < 23). This explains why we have the problem with big zoom level, and not average zoom level.

[incanus]

Interesting, @cga-F4. That's a great find & this makes sense. I will take a look.

[incanus]

@trasch, do you have any insight into this? I'm wondering if you ever tried the route of making the overlay layer size with the scroll view's content view, instead of making it a scroll layer with annotation corrections like it is now.

[trasch]

I did try it, but I really can't remember what the issue was. Maybe this is not an issue any more, since so many parts of route-me have changed in the meantime. It would certainly make lots of things easier if the overlay would have the size of the content view, maybe we could just try it.

Apart from that I honestly never thought that anyone would use route-me with zoom leves above 18... :)

[psavich]

Hello there. I'm experiencing the same problem on zoom levels 17 and above.

Here's a demo: https://dl.dropbox.com/u/586782/mapbox-marker-bug.mp4

The problem is definitely related to float precision of contentOffset – like cga-F4 I injected some logging into the value observer, and here's what I got (each line is a 1px movement):

2012-11-25 19:51:16.403 iGIS[98912:c07] ContentOffset: 162256000.000000 83907544.000000
2012-11-25 19:51:16.420 iGIS[98912:c07] ContentOffset: 162256000.000000 83907544.000000
2012-11-25 19:51:16.436 iGIS[98912:c07] ContentOffset: 162256000.000000 83907544.000000
2012-11-25 19:51:16.453 iGIS[98912:c07] ContentOffset: 162256016.000000 83907544.000000
2012-11-25 19:51:16.470 iGIS[98912:c07] ContentOffset: 162256016.000000 83907544.000000
2012-11-25 19:51:16.487 iGIS[98912:c07] ContentOffset: 162256016.000000 83907536.000000
2012-11-25 19:51:16.503 iGIS[98912:c07] ContentOffset: 162256016.000000 83907536.000000
2012-11-25 19:51:16.520 iGIS[98912:c07] ContentOffset: 162256016.000000 83907536.000000

As you can see, on 19 zoom we have a jump of 16px by x, and 8px by y. Each step of zooming out decreases the "jump distance" by factor of 2.

Unfortunately this issue is critical for our project, cause all RMPaths and RMMarkers vibrate really badly in some important use cases.

I see two solutions:

• unbind annotations from contentOffset and align their position to some more accurate properties.
• workaround by shifting the center of coordinates somewhere near ourselves, to decrease the value of contentOffset and make it more precise (this is possible in our situation because we work with a single city in our project)

What do you guys think about this stuff?

[zhm]

+1 to seeing this one fixed. Once this gets fixed I can complete the conversion of 2 apps to this SDK :) This one is just kind of critical because users have maps that are often high resolution satellite imagery.

[cga-F4]

Hi ! (and Happy New Year)
Is there some news for this issue ? This is critical for us too.

[incanus]

I will be investigating this soon and working with upstream on it. Have a couple ideas here.