How can I speed up rendering when moving the mouse?
For example, I draw two perpendicular lines on the screen, passing through the mouse.
I made a EditInteractiveOverlay and there override function
<small>protected override InteractiveResult MouseMoveCore(InteractionArguments interactionArguments)</small>
But the lines are appreciably behind the mouse. How can I get rid of this? can show an example? no other logic than to draw two lines, I did not do.
This becomes a real problem if you want to add some beauty to the movement of the mouse. :(
Alex,
You are going to have to give us more info on your scenario. What are you trying to accomplish exactely? Give us more background on your case. Also, there are many samples in the Code Community dealing with InteractiveOverlay. Most of them are in the Desktop version but they can still apply to Wpf. Maybe you can find there something pretty similar to what you are looking for. wiki.thinkgeo.com/wiki/Map_Suite_Wp...ys_Samples. Thank you.
Of course I watched the examples. But, unfortunately, they are also not happy with me in terms of speed. Let us take an example "Snapping to Vertex". I attached to its implementation of WPF. As we can see if the snappint point and give it to another polygon, it follows that the point behind the mouse cursor.
PointSnapToLayer.zip (260 KB)
The application in this post is a little different problem (do not pay attention to the name of the project), but the essence is the same. Drawing can not keep up with the mouse, moving across the screen. How can I speed up the process? I would be very grateful if you could show one of these examples on what you prefer.
001_PointSnapToLayer.zip (259 KB)
Alex,
Thank you for the samples. That always helps when we get something concrete from the users. I will look at all this tomorrow morning.
ok, thank you!
Alex,
I looked at your samples. While playing with them, I have to say that the responsiveness seems to me pretty good. When I drag a vertex or rotate the shape, it is pretty responsive. It is not perfect in the sense that if you go a little fast you are going to see the vertex lagging a little bit behaind the mouse pointer. But I am not sure we can do much about that. I can ask the Development team but I suspect that this is something inherent to the drawing system. Before i do that, I want to make sure that you are experiencing the same thing as I am on my machine. I did a little movie. Please, watch it and tell me if you are seeing basically the same kind of responsiveness. If what you have on your side is noticeably slower, then that would be a different kind of problem and we would have to investigate that route. Thank you.
001_Post10153.zip (377 KB)
Yes, I see the same thing. Simply by creating, for example, just two lines in the WPF, and hang an event on mouse movement, it moves at all keeping up. So I was unpleasantly surprised that the event is handled in its own layer, I see the lag. I understand that the objects which I move is much more complex than a simple line in the WPF.
But there were suspicions that I’m doing something wrong. I will try to profile the situation can get any way to achieve acceleration. I tried to use simple shapes WPF, but it turns very awkward to convert data back and forth, the coordinates, since such a rich logic as you have a simple WPF is not.
If you have any idea which way would be to look to increase the responsiveness, I would be grateful. I’m afraid that will slow when the screen is a lot of objects, since each perturbation of the mouse to draw the new area to the lines that I move, also updated.Perhaps in this direction tell how best to do? Is there a way to redraw lines only, without rendering currentExtent?
Alex,
I don't think that the speed that we are currently seeing in your app will be reduced with more objects on the map. Dragging a vertex involves that vertex and the two adjoining lines only. It does not take into account other objects unless you have snapping logic on (which is not the case in your sample app). In your case, you have a line made of seven vertices. The line could have one thousand vertices, the speed for dragging a vertex would still basically be the same.
The development team did the optimization internally for InteractiveOverlay drawing speed. I think that the slight lag that you see when dragging a vertex compared to the mouse pointer is inherent to the system we have in place and to Wpf and the way we have it drawing system used with MapSuite.
Well, we will assume that this issue is clear. :)
Now, if you do not have hard, pay little attention to the following to my question. It will be all about the same examples. Take 001_PointSnapToLayer.zip archive the message above.
When nothing happens the application "eats" about 100 megabytes. Then I start to rotate the line (that is, it is in edit mode and I'm on the button below to the right start to rotate the line around its axis). Then look in the Task Manager and see that during the rotation adds about 300-400 megabytes of RAM. Why is this happening? The same is true for example in the attachment. I just draw the two lines when moving the mouse, no serious logic there, but I have a memory comes to a 500-600 Mb. Why can occur this memory leak?
Thank you for always quick to respond.
002_001_PointSnapToLayer.zip (257 KB)
I decided to go the other way, discovered an example for WPF and Windows Forms. We compare the behavior of the two systems.
Take the two tasks that we need to see:
1) The move of the polygon while dragging the mouse cursor (Assess the relative speed of rendering mouse movements, as well as the amount of memory consumed).
2) Amount of memory consumed during the rotation of the polygon around its axis.
Input:
Intel Core i7 3.4 Ghz, 8 Gb RAM. Run all tests from Release.
In the initial state of memory consumption:
WPF - ~50 Mb
WinForms ~30 Mb
Run all tests will be in the demo application in the tree:
Editing Feature Layer -> Track and Edit Shape
All tests will be conducted on the critical component that is at a very rapid movement of the mouse on the screen.
Теst 1.1 (winforms + task 1):
The polygon did not lag behind the mouse movements precise, the amount of memory increases slightly (~50mb adding)
Теst 1.2 (wpf + task 1):
The polygon is behind the movement of the mouse (the problem of WPF).
The amount of memory is increased to about 200 megabytes.
Теst 2.1 (winforms + task 2):
Spinning around the axis of the polygon is absolutely behind the mouse, the amount of memory varies roughly as well as in motion (50 Mb).
Теst 2.2 (wpf + task 2):
Here there are significant problems. First, the spinning polygon rather lags behind the mouse cursor during the movement. Second, if the editing is (say) 10-20 objects, markedly inhibits the ground during rotation. But the most interesting is in the memory consumption. A simple constant spinning I was able to make the program instead of 70 Mb began to consume 800-900 megabytes RAM. When the motion stops, and we do not touch the mouse dropped to 400-600 after a while even decreasing. Then I made another interesting test. I drew five polygons (with the lines of the same) and all of them quickly began to rotate around the axis of the inside of your EditInteractiveOverlay. During the traffic program reached 1.2 Gb RAM consumption, and sometimes even fall to a bug in Draw function with an error of insufficient memory. The same situation probably can be done if you run the example in the car and turn the poor is only one landfill, since the memory is leaked rapidly (from 70 to 800-900 megabytes) during a simple spinning. We have also seen just moving / spinning polygon in pure WPF without ThinkGeo and noticed that the growth is almost no memory.
You may like to comment on the situation? why a WPF application is a wild growth of dynamic memory rendering card?
The problem of motion of the mouse in WPF is quite common, we know that WPF does not clearly define the coordinates of mouse movement (compared to the same WinForms), often used for this Drag and Drop. This allows you to make any event more responsive to mouse movement. What do you think about this?
A similar problem was described in the topic:
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/9278/afv/topic/Default.aspx
It’s really problem(
Alex,
Thank you for sharing with us your experience with the Map Suite Wpf Edition when dealing with EditInteractiveOverlay. I will meet with the Wpf development team later today and see what is the best course of action. We really appriciate when receive detailed information on the experienced problems. Thank you.
Alex,
I let you know that we created a support issue in our internal tracking system. This issue will be looked at later this week. I will let you know the findings. Thank you.
Thank you,Val!
We will wait for any information on the two designated issues. This is in many ways our lives easier and make your product even better! Thank you.
Alex,
The development team has not been able to recreate the issue that you are describing. They have not seem the spike in memory usage that you report. We have your PointSnapeToLayer sample. I think that the best would be for you to create a movie where we see what kind of action you do to generate the memory issue. Make sure that you have your Widows Task Manager in the movie so that we can see the memory usage on your side. Thank you.
Example and is not needed. Take your demo application, turn the profiler memory, create a polygon (on the screen> 20 inches) and start its fast spin. Or just create a test site and see bursts of memory. I recorded the video from the desktop and put on YouTube. Here is the link:
youtube.com/watch?v=Py4czoA8u48&feature=youtu.be
If hard to see, please put the highest quality (HD).
It's average. Sometimes before, I went for the 1Gb of RAM. If there is an initial vector, it can easily cause out of memory exception.
A similar problem was described in the topic:
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/9278/afv/topic/Default.aspx
Alex,
Thank you for the video. This is definitely going to help. I created an internal ticket in our tracking system for the Development team to look at. I think this is more an optimization problem than a bug. I will let you know their findings.
In the meantime, can you make sure than you have the option Platform target to x64 under Project/Properties../Build? I think this can help. Thank you.