DEPRECATED-mapbox-ios-sdk
DEPRECATED-mapbox-ios-sdk copied to clipboard
mapbox
RMMark, RMPath "vibrate" while the RMMapView is being scrolled
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.
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?
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.
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 ?
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.
Interesting, @cga-F4. That's a great find & this makes sense. I will take a look.
@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.
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... :)
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?
+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.
Hi ! (and Happy New Year) Is there some news for this issue ? This is critical for us too.
I will be investigating this soon and working with upstream on it. Have a couple ideas here.
This blog contains a proper solution to the problem: http://www.mlsite.net/blog/?p=1342 for more context, see https://github.com/Alpstein/route-me/issues/122#issuecomment-11965580
I'm not sure this does entirely solve the problem, though I have to investigate further. It says:
Note that the content view is set to the size of the entire rendered world; this does not cause out-of-memory problems because the content view does not render any content directly; only those subviews in its visible area are rendered.
Which leads me to believe that we will still have precision problems with higher zoom levels since the effective content view is still dealing in 1:1 pixel sizes with the current method.
No, the problem you are seeing, is that on high zoom level you need to scroll 10 pixels for a contentOffset change to be fired, because it is assumed you are viewing a zoomed in bitmap. By resetting the zoomlevel back to 1 you will get back the fine grained scroll events.
Could you keep this ticket updated with progress? I was planning on working on this myself, but it's better to not waste 2 people's time working on the same thing. Or if you want some help, I'm more then happy to chip in :)
Yes, I will. I am working on this combined with improved tile load performance in a hopefully-major (if successful) overhaul of this subsystem.
Based on my testing, this is a limitation in UIScrollView. I'm currently working on some testing that uses a large (> z17) content view, nothing to do with the KVO calls, and its own content view vibrates in this manner on high zoom.
I'm working on this issue in combination with performance work from discussions in https://github.com/Alpstein/route-me/issues/35 and will probably end up doing something related to not actually having the scroll view content view be 2^zoom * 256 pixels to a side, but rather "faking out" the system in order to keep the content view within reasonable sizes.
Yes, that is true, because again, it is assumed you are looking at a zoomed in bitmap, where it makes no sense to scroll less then 1 (hugely magnified) pixel. Now if you would have tested the kvo calls as well, you would have noticed the calls will only be triggered by scrolling for the magnified pixel (10 pixels instead of 1). Which still means that resetting the zoom level back to 1 after zooming has completed solved all problems. Also your problem IS the kvo calls because you are updating the position of the markers based on kvo events (thevmarkers are not even inside the scroll view). You can actually test this by zooming in heavily and scroll for less then 10 pixels and you will see no kvo events triggered untill you scroll enough pixels to cover an 'enlarged' pixel.
The markers are not inside the scroll view because they would be scaled while zooming. They are on an entirely different layer.
I am also resetting the zoom level back to 1 and also not drawing a bitmap, but rather using sublayers.
Awesome, then in any case I'm positive the problem will be fixed. Not sure if having layers will change anything since cglayers are rendered to the pixel buffer as a bitmap in the end, at which point you can still do transformations on them.
So most likely you will be zooming and panning in the scrollview with the allready rendered layers. But yeah cglayer rendering is really fast.
Good luck!
Will keep at it. Thanks for the back-and-forth; will keep progress updated here.
I'm not actively working on it right now, as I'm preparing the next release of the SDK. After that, I'm targeting this and tile performance together since both will be somewhat disruptive.
If you'd like to work on it in the meantime, that's good. I can share some of the ideas I had, but I don't have code as of yet.