ThinkGeo.com    |     Documentation    |     Premium Support

The dynamic redraw. The issue of performance

#1

Hello, ThinkGeo team!! 


Recently, I have not bothered by many complex issues. :)


Let's start. The theme of today's discussion will be issues with the rendering performance (the last time we tried to find out cause of the problem with the memory leak). 


The version of ThinkGeo (WPF Desktop Edition): 6.0


Computer: Intel Core i7-2600 3.4Ghz, 8gb Ram.


______


I work in your demo application. All work is performed under TrackAndEditShapes without changing the code. I'm trying to do the following. Start drawing a polygon (random) and put a lot of points quickly. At some point (after a 20-30 points), the program starts to slow down noticeably when rendering. When I stop moving and put the point, it loads all that I have accents. This is done specifically? At the same time you draw a polygon is engaged in the whole core of processor. I think it is so much. 


youtube.com/watch?v=mFmGU-pV33s&feature=youtu.be


The video clearly shows two things:

1) the rapid establishment of a set of points is fading;

2) when a large number of points can redraw die, waiting for the cancellation of the mouse.


The first reason is probably caused by the second. Get the slow refresh when a large number of editable points. Pretty frustrating. During this movement the whole core is busy.


 


You can comment in any way? Thank you!!!



#2

Alex, 
  
 We have fixed some performance issue in the latest code, please get 6.0.39.0 or 6.0.0.39 and have a try. 
  
 Thanks, 
  
 Ben

#3

I download the new version of the library (6.0.39.0) and add reference to your demo application. On the creation of objects, nothing has changed (visually), but when trying to edit the application is not responding. :(

#4

And we talked in the topic: 
 gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/10194/afv/topic/Default.aspx 
 that we have not handled key events in the InteractiveOverlay. You wrote that in version 6.0.15.0 or higher is fixed. But in 6.0.39.0 bug remained.

#5

Alex, 
  
 We tested 6.0.39.0 again and seems the performance is pretty good, we drew a polygon by adding around 80 vertices and there is no noticeable delay. If we use the 6.0.34.0 version, the performance is getting worse since we added the 30th vertex on the map. So I think this issue is resolved. could you have a check again, please make sure you are using the version 6.0.39.0 instead of 6.0.0.39.  
  
 About the issue gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/10194/afv/topic/Default.aspx , we fixed it in 6.0.15.0 but later we found that fix is not good and it might bring us a new issue, so we rolled the code back, and now still working on a better solution. 
  
 Thanks, 
  
 Ben 


#6

Thank you, Ben. In version 6.0.45.0 Speed ​​is better. Thank you.  
  
 About the issue gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/10194/afv/topic/Default.aspx we will wait for a response.

#7

Hello Alex, 
  
 I’m glad it’s working, please feel free to let us know your problems. 
  
 Regards, 
  
 Gary

#8

Alex, 
  
   I wanted to let you know we are working on the issue regarding editing a complex polygon where the edited vertex lag behind the mouse pointer.  We have made some significant speed improvements so that complex polygons are as fast as simple ones.  One other question is in regards to the memory issues you had mentioned, can you explain it?  I heard that if you edit a shape for along time it increases in memory and gives you a out of memory exception?  Can you explain what you mean by a long time and also do you have the well known text of an exmaple shape so we can setup our own test? 
  
 David

#9

Alex, 
  
   We have made allot of progress on this and have some great change in version 6.0.59.0.  We should have a new post out in the news and announcements forum tomorrow that details the changes and also has a video showing the enhancements.  We have made the dragging of vertexes much faster so the complexity of the polygon or the number of edit polygons do not have an effect.  We have also stabilized the memory so you will not see it spike anymore.  You can checkout the detail as soon as the news is posted. 
  
 David

#10

Hello, David! I watched your video and your comments about the increase in speed. I clearly understood that the number of polygons and points now have no effect on speed. This is good.  
  
 But when I took your demo application with the library version 6.0.63.0,  I did not notice  а significant improvements about а  memory usage and а lag during you drag а vertex. 
  
 May be I did something wrong and therefore could see advantages of the new version.  Could you made a demo application with latest version which show as their advantages when we create or edit a feature? 


#11

My apologies, memory problems are no more. But speed is still not the same as expected, the mouse behind, let’s try an example of your application (as I wrote above).

#12

 Alex,
 
That’s because the vertexes are not enough:). Try drawing 30 circles on the map in the HowDoISamples->Editing Feature Layers->TrackAndEditShapes, click “edit” and try to drag one vertex. In 6.0.45.0 you can hardly move it but with 6.0.63.0 it is very responsive and the memory is more stable. Just have a try.

 
Ben

#13

Hello, Ben.:)

I tried the example, I fully agree that a large number of vertices is now much better. It's great! For memory issues too categorical no more.

But I was more interested in the issue of performance moving of one figure and one vertex. The lag of the mouse is still there, and it can be seen on your video, and the example that I made ​​myself. This is seen as a feature and a vertex, and on the set of features as in your example.


See the attachment to see what I mean.



002_001_sample.png (42 KB)

#14

 


Hi Alex,
Can you let us know how fast did you drag the vertex? Is it possible to make a video about it? I think the lag of the mouse problem does make sense if we move the mouse fast. Because we need to redraw the vertex always while moving the mouse, there should be a very small delay to get the response, the attached is the demo just using  Microsoft Wpf technology, you see there is also a small delay, but all works fine if we drag with a normal speed. Hope my explanation helps.
 
Thanks,
Johnny
  

DragVertex_Test_Wpf_20120719.zip (10 KB)

#15

Hi Johnny!


I looked at your example. As for the speed with which I carry out editing. I have already sent a few times, I'll send it again.
In this video, the speed at your library:
youtube.com/watch?v=XretKgrseH8&feature=youtu.be
 
And in this video, the speed of software, which is now used in the company (10 years old):
youtube.com/watch?v=x-gTZ8ku2bQ&feature=youtu.be
 
Below I have also attached screenshots of the distance between a point and click in one and two cases at random time. 
(OUR - our system, TG - ThinkGeo)
 
And this difference is not really lets us enjoy the product.
 
If you can make the speed such as it is shown in the examples of our system, it would be good.
 
P.S. By the way, if you draw objects by means of WPF (not GDI+), the results are about the same as in our system.
 
CodeSample:


private void Window_MouseMove(object sender, MouseEventArgs e)
{
Point pt = e.GetPosition(canvas);
ellipse.Margin = new Thickness(pt.X - ellipse.Width / 2, pt.Y - ellipse.Height / 2, 0, 0);
}


 

 




images.zip (117 KB)

#16

Of course, the ideal case is the complete absence of any lag, but I understand that it is too idealized situation. But the lag should not create a nuisance in the work of cartographers.

#17

 Alex,



Finally we isolated the issue.  We created a blank WPF project without using Map Suite, drag a point and it seems fine. We then click a button without hooking up any events and drag the point again, it is lagging then. We tried it on 3 machines and they all have the same results.



Before click the button:



After Click the button:



Here attached is the sample we tried. Also we’ve posted this issue on Microsoft forum and we’ll see how they response.


social.msdn.microsoft.com/Fo...547a4745aa


Ben



005_004_003_002_001_Sample.zip (9.5 KB)

#18

 Hi, Ben!


I looked at your example. It looks really strange. However, I would like to make a clarification, just try to set the focus to the button (using the TAB key for example) and do not even have to click to see the lag. 


In an attachment, you can see my example MainWindow2. If you just moving a mouse, almost no lag (such speed and want to get a result), but if you press TAB, the focus moves to the button and become noticeable lag.


And you can tell precisely how this affects the motion of a point in your map suit?



001_005_004_003_002_001_Sample.zip (67.1 KB)

#19

 And why do you have in your application WinForms is still lagging behind the mouse, but if you create a clean WinForms application, it will not? See the attachment.


 

WindowsFormsApplication1.zip (41.1 KB)

#20

Alex,


Yes, the lag in our wpf edition is caused by the button click. And for you second question I wrote a sample which is more like the desktop edition's behavior, and there is an obvious lag when moving the mouse, besides, the new drawing logic in the wpf edition haven't been put into desktop edition yet, I think it'll be much better when we do the same thing to desktop edition.


Thanks,


Edgar



Ticket7882.zip (8.78 KB)