MBXMapKit Example App high CPU usage about mbxmapkit HOT 7 CLOSED

check out #153. The fix there helped my high CPU as well as a random crash ...

from mbxmapkit.

Now that I see this issue and #153 discussed together, I am betting they are one in the same. Instead of the fix proposed above, which could potentially lead to missing tiles from an online map -- since the setNeedsDisplayInMapRect call would have the (presumably) desirable effect of re-queuing an online tile for download if the data was bad -- I'd suggest leaving the setNeedsDisplayInMapRect call in the original location, but use an if to skip it if loadTileAtPath returns an error associated with missing offline tiles:

if ([error code] != MBXMapKitErrorCodeOfflineMapHasNoDataForURL) [weakSelf setNeedsDisplayInMapRect:mapRect zoomScale:zoomScale];

So setNeedsDisplayInMapRect will be called in all cases except the case of a missing offline tile.

That appears to block repeated calls to load an offline tile that does not exist, and avoids high CPU usage and crashes were were discussing on #153 . It also eliminates the need for that blank tile hack in #153 , so it allows over/under zooming of tiles at other zoom levels. Essentially, if there is no available offline tile for a mapRect, any previous rendering is left in place and we do not attempt to load the tile any further.

from mbxmapkit.

@s219 I'll have some time to test your comment out in the next few days - sounds like the best way to proceed !

from mbxmapkit.

Well, I saw a crash today with online maps, which originated from the setNeedsDisplayInMapRect call and veered off into the #153 crash. Need to study the code again -- may want to revisit and think about scenarios when that call needs to be skipped for online maps -- might be other error conditions, or cases where tileData is bad. @ndm-io may have had a safe approach up top of the thread.

from mbxmapkit.

I did some stress testing with online maps, and was able to create an endless looping condition similar to what we saw in #153 for offline maps when using my fix suggested up above. It took some doing and may not be a common scenario, but I showed it could happen. Based on that, I think @ndm-io has the best solution (whether offline or online), by calling setNeedsDisplayInMapRect inside the if(tileData) check. May even be that we should move that call inside the if(imageRef) check too.

I imagine the MapBox guys are busy with WWDC this week, but would be good to get some feedback here. It's possible that the location of the setNeedsDisplayInMapRect call in 0.7 is in fact a bug, and it should be up inside the tileData check as @ndm-io suggested. Of if it was meant to be where it is, I think we really need some sort of limit so that the whole setNeedsDisplayInMapRect --> canDrawMapRect cycle doesn't go into an endless loop in certain scenarios.

from mbxmapkit.

See #167 for a revised canDrawMapRect that avoids this crash and fixes another major bug when using 512px tiles.

from mbxmapkit.

@ndm-io Thanks a lot...Solved my crash issue by moving the call to within the if block..

from mbxmapkit.