MKMapView: Can't keep annotations from flashing during an update. Ideas?

  • After the user drags the map, I do a query and update the pins on it.  To
    prevent flashing of all the pins, I add the new (complete) collection of
    annotations before removing the old ones.  I call addAnnotations before
    removeAnnotations.

    But the pins still flash.  The map goes completely blank before the updated
    collection appears.

    Anybody know why?  Thanks for any insight!

    Gavin
  • Out of curiosity, why are you manually removing them in the first place? MKMapView should be handling that logic for you as I understand it. If its for performance, the docs say to make sure you dequeue the MKAnnotationView instead of creating a new one when possible so that it can reuse the views intelligently.

    Im working on a problem where I've got around 30-40k annotations on the map and of course performance is terrible when they are all visible at the same time. I'm looking into ways to only drop one pin per x pixels so that fewer pins that are near each other are visible when zoomed out and more pins are visible when zoomed in. If that's similar to the problem you're trying to address, I'd be interested in your findings as I can't seem to come up with anything that doesn't involve a bunch of overhead and rect calculations.

    ---
    Joe Wollard

    On Jun 26, 2012, at 8:48 PM, Gavin Stokes <stokestack...> wrote:

    > After the user drags the map, I do a query and update the pins on it.  To
    > prevent flashing of all the pins, I add the new (complete) collection of
    > annotations before removing the old ones.  I call addAnnotations before
    > removeAnnotations.
    >
    > But the pins still flash.  The map goes completely blank before the updated
    > collection appears.
    >
    > Anybody know why?  Thanks for any insight!
    >
    > Gavin
  • On Jun 26, 2012, at 7:38 PM, Joe Wollard wrote:

    > Out of curiosity, why are you manually removing them in the first place? MKMapView should be handling that logic for you as I understand it. If its for performance, the docs say to make sure you dequeue the MKAnnotationView instead of creating a new one when possible so that it can reuse the views intelligently.
    >
    > Im working on a problem where I've got around 30-40k annotations on the map and of course performance is terrible when they are all visible at the same time. I'm looking into ways to only drop one pin per x pixels so that fewer pins that are near each other are visible when zoomed out and more pins are visible when zoomed in. If that's similar to the problem you're trying to address, I'd be interested in your findings as I can't seem to come up with anything that doesn't involve a bunch of overhead and rect calculations.

    Check out the "Visualizing Information Geographically with MapKit" 2011 WWDC video.  I believe it is in one of the demos that one approach to this EXACT issue is presented.

    You can also structure your annotations in a manner so as to make finding the right annotation(s) to display in a region easy (or, at least, computationally inexpensive).  For example, look at quadtrees (e.g. http://blog.notdot.net/2009/11/Damn-Cool-Algorithms-Spatial-indexing-with-Q
    uadtrees-and-Hilbert-Curves
    ).

    --
    Conrad Shultz
  • On Tue, Jun 26, 2012 at 7:38 PM, Joe Wollard <joe.wollard...> wrote:

    > Out of curiosity, why are you manually removing them in the first place?
    > MKMapView should be handling that logic for you as I understand it. If its
    > for performance, the docs say to make sure you dequeue the MKAnnotationView
    > instead of creating a new one when possible so that it can reuse the views
    > intelligently.
    >

    Hm, I don't know how it would handle it automatically.  If the user shifts
    the map at all, I requery for all markers within the boundaries of the map.
    Eventually I'd like to retain the markers that are in common between
    queries and only refresh the changed ones, but for now I'm totally
    refreshing the view.

    Right now I'm only dealing with 3000 or so markers at most, but paring them
    down and aggregating within a certain pixel range is what I was intending
    to do.

    I'm going to check out the WWDC materials Conrad recommended.

    Thanks, guys!

    Gavin
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today