I am working with ArcGIS Pro and have built a configuration AddIn on the application. My configuration helps in creating drawing and attribute rules for the new features created via a feature service. After a feature is created, it is necessary for me to Redraw the map to insure that I have the latest values from our ArcGIS Server and Database. This keeps our mapping system upto date with values that might have changed via database updates.
Anyway I use await MapView.Active.RedrawAsync(true); which works fine for a while. Then after some time, the process becomes very slow and takes almost a minute to complete. My ArcGIS Pro toolbars go Gray until it is complete. I can also use the OOB Redraw and it does the same thing and takes upwards of a minute to complete
Is there a way for me to do this in a more efficient manner (to update my features, map, cache?). Or am a missing a setting somewhere that would improve my map. I have 17 maplayers that all get redrawn, where only 2 of them probably need the redraw. But the only way I can think to redraw is on the the MapView.Active map. This slowness kills my ArcGIS Pro session.
Any Ideas?
Solved! Go to Solution.
private static void Cleanup(MapMember inMapMember)
{
FeatureLayer fl = inMapMember as FeatureLayer;
fl.ClearDisplayCache();
}
This doesn't appear to have any positve affect. The only fix is to remove and readd the layer. This appears to happen when loading an Inspector in the onchange or oncreate events.
I will try the ClearDisplayCache and probably update to 2.5 right now to get the latest and greatest. I am monitoring performance degredation using the Diagnostics Monitor and seeing how long the redrawasync takes after my code runs. Just click the recycle button on the bottom right and watch the RedrawAsync in the Diagnostics Monitor. It will gradually go from 500ms and continually rise. What I am doing is on the RowChange event or RowCreate I am loading an inspector with the Arg.Row. If I do this an number of times the redraw async takes longer and longer everytime
I can reproduce this in 2.4.3 with the simple inspector load in an event. In my case the redraw increases to 3000ms then stabilizes. I dont see this in 2.5/2.6 so let us know what results you get.
I think the reason this was happening is because when I enter a rowcreate or rowchange event I load the inspector with the row. In those events I have WPF forms that show, which works just fine. HOWEVER, when the Row with a certain shape comes in, I need to change the shape of that Row based on what it interesects or what other shapes it needs to be confined within. When you use Row.Store, the UI doesn't reflect the shape change immediatly, so I was using inspector.apply, which immediatly changed the shape on the UI. When I now set the Shape, and perform Row.Store, the UI doesn't reflect this behind the WPF form that is loaded as a dialog. I need the UI to reflect the shape changes or refresh the UI, and I think I will have this fixed. Inspector.ApplyAsync was the problem for sure.
row.store isnt needed if the additional edits occur in the workspace of the row returned by the events. In row events the edit operation is still executing which is also why you cant see the results of additional edits in this event until the execute completes. In 2.4 you can access the running editoperation through RowChangedEventArgs.Operation where you can add additional edits that are queued but again any changes here wont be seen during the event.
Creating a new editoperation or calling Inspector.Apply isn't supported in rowevents. How are you calling .ApplyAsync in the rowevent?
I think we can close this discussion. I launch a wpf form from the Row Create or Row Change. I use to use applyasync on any changes made to my object that was loaded as an inspector from the ROW. I still load the inspector from the row, but I now store the row and not apply on the inspector. This seems to have fixed almost everything. Except I need to MapView.Active.RedrawAsync(false) in order to see the shape change in the Row Create (and before i show the wpf). This seems to work pretty well for now.