ThinkGeo.com    |     Documentation    |     Premium Support

Unsynchronized overlays

#1

     Hi guys,


 For some time now my users have been experiencing a very odd (and certainly annoying) issue when they make zoom operatins in the MapSuite component. It does not happen always but in some installations and sometimes.


 I was unable to reproduce it in my own PC so please don't ask me for a simple sample, but I saw it in a couple of different customers PCs. 


 As you can see in this video: dl.dropbox.com/u/6792052/VID_20130121_101114.mp4 after changing the scale the "targets" (orange icons with red track lines) LayerOverlay get rescalled, but the background Shapefile (shorelines) not. Just by starting a map drag the background overlay gets synced again instantly.


 By doing tests I localiced the issue in the folloging pice of code


         If SelectedScale <> WpfMap1.CurrentScale Then


          'Center to the mouse position


          WpfMap1.RestrictExtent = Nothing 'Disables termporally the RestrictExtent


          WpfMap1.CenterAt(ScreenMouseX, ScreenMouseY)


          WpfMap1.RestrictExtent = New RectangleShape(-3600, 89, 3600, -89)


          'Zoom to the new scale


          WpfMap1.ZoomToScale(SelectedScale)


        End If


  If I comment the center at code it works fine (despite it does not center to the selected location first), but as soon as I try to center to the selected point and then zoom to other scale I have a chance of getting this odd issue


 Actually I'm ussing 6.0.260.0 dlls, and it also failed with 6.0.200.0. Older version (don't remember which one) didn't fail.


 Could you please look at your internal threading in order to see if you can determine and fix the root cause of the issue?


 Thanks in advance


Carlos



#2

Hi Carlos, 
  
 I tried to recreate it but failed, you said you have a chance of getting the issue by the code above, so that means you have a sample? Would you mind providing to us because we need to see the other code and maybe the issue is caused by some settings. 
  
 Thanks, 
 Edgar

#3

Hi Carlos, 
  
 I tried to recreate it but failed, you said you have a chance of getting the issue by the code above, so that means you have a sample? Would you mind providing to us because we need to see the other code and maybe the issue is caused by some settings. 
  
 Thanks, 
 Edgar

#4

Hi Edgar, 
  
  As I told you in the first post, I can’t reproduce the issue in my own PC so I don’t think I could extract a simple sample. Anyway extract a simple sample from a complex software is not that easy. I know it makes debugging far lot easier for you, but you should understand is not always possible, even more when the issue happens only in some installations and the component is embedded in a much more complex solution. I will be working couple of days only removing unrelated code from the whole solution to extract a piece of code that you will test and say you cannot reproduce the issue from it. 
  
  Wound’t it be possible your engineering team look at the component internal architecture and try to find out how it would be possible such a result? maybe creating a special built that logs whatever diagnostics information could be needed so I can run it in on of the PCs that present the issue more oftenly trying to catch it up 
  
  Your help on this will be highly appreciated

#5

Carlos,


The CenterAt and ZoomToScale will both cause the map refresh, so there might be some problems in synchronizing, according to your requirement, there is a simpler way to do it.



        Dim center = ExtentHelper.ToWorldCoordinate(Map1.CurrentExtent, ScreenX, ScreenY, CType(Map1.ActualWidth, Single), CType(Map1.ActualHeight, Single))
        Map1.RestrictExtent = New RectangleShape(-3600, 89, 3600, -89)
        Map1.ZoomTo(center, scale)

Regards,


Edgar


 



#6

Hi Edgar, 



It seems you have hit it. With the proposed workarround the issue doesn't happen (at least till now).  



Now the question is, will it be easy for you to fix it in the component? (I mean to properly sync your internal threads to avoid this issue even when CenterAt and Zoom are called at the same time) There are some code execution paths where I cannot warrantee that CenterAt will not be called just close to a Center or even a more common Overlay.Refresh. In fact an Overlay.Refresh may happen while component is zooming at any time. 

Do you know why this happens more easily in some PCs but not others? May it be related to the graphic card, TileCache, CPU or anything else? 



Regards, 



Carlos



#7

Carlos, 
  
 Glad to hear that, but I’m afraid we’ll not do any change in the component, this is like we can’t modify a Dictionary in different threads at the same time without any locker, you may want to avoid the calls which will leed the map to refresh. As you said it happens more easily in some PCs, so I think it might happen in some low-end machines? 
  
 Regards, 
 Edgar

#8

No, it is not low-end or high-end related. In fact I don’t find a commonality on it, that’s why I were asking. 
  
  .NET 4.0 introduced the System.Collections.Concurrent (msdn.microsoft.com/en-us/library/dd997305.aspx) namespace that handles internally locking mechanism to allow concurrent use. 
  
   May you reconsider to change the component?

#9

Carlos, 
  
 I think you misunderstood what I say, I didn’t mean we are using some Dictionary in our code, I mean the Dictionary things are just like our dlls, we cannot do too much checking internally cause the performance might be bad, and the callers should handle the multithread calling outside. So we may not change the component. 
  
 Regards, 
 Edgar

#10

Ok, I see. But don’t you have kind of refresh queue or any basic synchronization algorithm? 
  
  It isn’t anything you can do to improve this? Take in mind that form the component consumer point of view there is absolutely no way of avoiding this as we have no control over component internals. if for instance I call a refresh, I have no way of knowing when it finished executing completely in order to avoid other thread calling a zoom, and even if I could, user might initiate a zoom with the mouse. Trying to syncronize this would be a nightmare. So I really thing it should be any kind of internal protection

#11

Hi Carlos, 
  
 Please don’t worry about the thread synchronization, I think the problem is that we set the Extent in both CenterAt() and ZoomToScale(), could you use the walkaround which we figure out where the bug is, we will keep tracking this issue in next few days, if you have more information, that will be highly appreciated. 
  
 Thanks, 
  
 Johnny 


#12

Hi Johnny, 
  
 I’ll try to apply the workarround where possible. I really appreciate it as at least solves partially the issue. Thanks a lot!!! 
 Please let me know if you find some solution over next few days. 
  
  Regards 
  
 Carlos

#13

Thanks, Carlos, I have refered the issue to our development team now. I will update the anwser here once they get a fix. 
  
 Thanks again. 
 Johnny