ThinkGeo.com    |     Documentation    |     Premium Support

Overlay.Refresh Behavior?

I was just curious as to the behavior of Overlay.Refresh(), particularly when many calls to it come in at a short period of time... Does Overlay queue these up and execute each refresh, or if there is already one queued up to go, does it throw the rest away?


I'm running into an issue that without looking into it too much I think is caused by the refreshes being queued up and executing (specific to my case a WMSRasterLayer as download from WMS server can be slow).  Anyhow, just knowing how Refresh works will help me determine the best way to go about figuring out my issue.


Thanks,


.Ryan.



I had another question/issue with Overlay.Refresh( ) 
  
 I have a custom MarkerOverlay that I use.  Each marker has a context menu.  From within the context menu, I update my overlay and call Overlay.Refresh( ), however no changes occur until I close my context menu (IE if I remove the item from my data source and call refresh, the object is displayed on the map until I close the context menu (I know it doesn’t make sense to keep the menu open if I’ve removed my item, this was just an easy example for me to test)).  I can, however, use WpfMap.ZoomTo which updates the map as soon as it is called. 
  
 Any help would be appreciated. 
  
 .Ryan.

Please ignore my second question… I found a bug in my code… 
 .Ryan.

Ryan, 
  
 In fact, the WPF Map Control is not queuing up any WMS request internally. When refreshing an Overlay, all of the Tiles within current extent will be requested. 
  
 For using the Refresh method continuously in a short period of time, the major factor that may affect the responding speed lies in both WMS Server and Map Control. Since a lot of WMS requests will be sent to WMS Server, these requests could be queued up at the server side, which could slow down the server’s responding for incoming requests, meanwhile, when making a new Refresh action, Tiles on Map Control will still be waiting for the sent requests, which will also slow down the Map’s responding.  
  
 So, it’s not suggested to use Overlay.Refresh method if there’s no style or layer changes in the Overlay.  
  
 Further questions please let me know. 
  
 James

Hi James, 
  
  But forgetting the WMS, imagine an application with multiple threads that may call Overlay.Refresh method when other’s thread Overlay.Refresh is still being processed. What would be the result? One of them being ignored because the other is in progress, one of them being cancelled because the second started executing, or one of them being queued and executed after first one completion? (Last one you already answered is not the right one, so we have two options)

Carlos, 
  
 As Overlay.Refresh is interacted with UI Element, when calling it in multiple-thread, there will be an error. So, for now, Overlay.Refresh can only be called in single thread. Anyway, thank you for caring about MapSuiteWpfDesktopEdition.  
  
 Further questions please let me know. 
  
 Thanks. 
  
 James 


Hi James, 
  
  I know that, but independent threads use invoke method to interact with the UI (this is the standard procedure for all the interactions betwen working threads and UI) 


Carlos, just adding to what James said:  Overlay.Refresh() is eventually invoked by the main thread's dispatcher as you indicated.  So, if you have two simultaneous calls to overlay.refresh, these calls will be added to the main dispatcher's queue and processed in a FIFO manner as they will arrive at same priority. 



I do not see a problem here.



Hi Klaus, 
  
  There is no problem, it was a question on how it work, because if it is that way then I (and probably Ryan too) will need to "filter" the calls to the refresh function in a "lazy" way to avoid too often refeshes and loss of responsiveness 


Yes Carlos, that was exactly what I was trying to figure out.  Thanks!

Ryan, I am glad you find the solution, let me know if you have more questions. 
  
 And also Thank Carlos and Klaus, I appreciate your sharing. 
  
 James

James, 
  
 Just a quick question on Refresh().  When Refresh() is called, does it store a snapshot of the map (ie extent, visible layers, etc) for use during that refresh, or does Refresh() take the current state of the map when the refresh actually executes as its state?  Just trying to figure out the best way to filter out unnecessary refresh calls. 
  
 Thanks, 
 .Ryan.

Ryan, 
  
 You can find a property named MapArgument in Overlay, where the extent of the map and other information are stored, and in LayerOverlay, the Layers property holds reference to the layers added to the overlay. When Overlay.Refresh method is called, the entire related state is loaded from these properties. 
  
 Further questions please let me know. 
  
 Thanks. 
  
 James 


I guess my question is assuming we have a bunch of refreshes come in that get queued up… each refresh actually executes (is no longer in the queue)… does it read the extent information etc at that point in time, or is that information stored with the queued up refresh request? 
  
 Just an example to illustrate my question, if for some reason a refresh was queued up for 60 seconds, and in that time the user has panned the map, when that refresh actually gets executed, will it know the new map extent and all other related information, or will it do the refresh of the overlay as if the map was still at the previous map extent? 
  
 Thanks, 
 .Ryan.

Ryan, 
  
 Overlay contains tiles, but tile doesn’t know its parent information because overlay is not a FrameworkElement but just an object. All tiles are quered in the UI thread and proceeding its rendering. After sleeping 60s, the tile maintains its own informations such as tile’s extent, the map draws the quered tiles based on its latest extent and the tiles information. 
  
 Thanks, 
  
 James

Hi James, 
  
 I’ve sent a sample to support to forward on to you.  In the sample, I connect to a WMS server to get layers depending on check boxes.  If you go down the list and select all the check boxes, then while it is loading zoom in with the zoom box and wait, you will see some funny things happen (including it appearing to switch zoom levels without any user interaction due to old tiles being drawn) due to the multiple refresh, then eventually a crash.   
  
 This is just an easy example of some of the problems I’m experiencing.  My application is heavily multithreaded and refreshes can be coming from all over the place.  I’m just curious if you had any ideas for a solution to at least make it work (ie not crash and not appear to zoom to different extents) even if we take the performance hit of the multiple refreshes going through. 
  
 Thanks, 
 .Ryan.

Ryan, 
  
 I haven’t got the sample yet, I will ask support, and once I get it I think I could recreate your problem and give you a solution for it. 
  
 Thanks, 
 James  


Ryan, 
  
 Thanks for your sample. I can recreate your problem that after I select all the check boxes and zoom in and wait, it will throw Object null reference exception eventually, we have fixed this bug in 4.5.128.0 version, please get the latest package(development branch) and try it again. 
  
 Thanks, 
  
 James

Hi James, 
  
 I can confirm that I don’t see the crash anymore?  I was wondering if you were able to see where it will sometimes switch to a different zoom level and if this was fixed?  I know I still see it when I’m switching using the OpenStreetMapOverlay and an overlay with local shapefiles, and I know I’ve seen it in my example app a few times before…  Not sure if the two are related at all and it was just something that got missed in the OSM overlay… if not, I’ll create a new topic w/ a sample app. 
  
 Thanks! 
 .Ryan.

Ryan, 
  
 I am glad that you confirm the crash problem is fixed. But I am still not sure what the appear to zoom to different extents problem is, I think the different zoom level tile is just preview effect, you can try to set TransitionEffect of Overlay to none and see if your problem is still existing. If it is, could you provide more information to us, such as a screen-shot, you can mark something on that image to show your problem. 
  
 Thanks, 
  
 James