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.
The slow screen redraws on the movement of the mouse
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.
Unfortunately, I do not agree that this optimization process. This is a bug. I just have a computer powerful enough (8 gigabytes of RAM), but if I run it on a weaker machine (2 gigibayta RAM), and 200-300 MB of upload to vector map, then retest the program crashes with an error out of memory exception. The same can be seen in other posts that I quoted above. In my opinion the program should not crush, even waiting for a second and resets the memory or even an action, but did not crush at all.
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.
The problem manifests itself in the assembly under x64. Moreover, it is not a solution because I need to run the program and will be for 32-bit builds.
The above test I performed on the machine:
Intel Core i7 3.4Ghz, 8 gb RAM, assembly in x86
Alex,
Thank you for providing that additional information and your opinion. We value your point of view and this is going to be communicated to the Development team. I will let you know as soon as I have the results from the findings of the Development team. Thank you.
Thank you very much,Val, for your cooperation and your answers! It is really nice. With your very nice work.
I’ll wait for news from you!
Hello Alex,
Thanks for your waiting, unfortunately we tried the latest code on a Virtual machine with bad hardware, but seems like the memory usage is normal, here we make a short video about it , please check it out, and let us know what you got.
download.thinkgeo.com/forums/MemoryUsage.zip
Also could you please get the latest version and have another try?
Regards,
Gary
Thank you for your video. Let's deal further.
1) What is your screen resolution? The fact that it directly affects the amount of memory consumed. On the monitor in 17-inch jump in memory of about a factor of 4-5 relative to the original, but on the monitor 24 inch (1600x1200 full screen mode) jump by 10 times or more.
2) You have used too "easy" test. The movement is very slow rotation, too. In real life, this is not always the case. Try to rotate the object does not hold (that did not work the garbage collector) in at least 10-15 seconds with a fast speed on the big screen, and you'll be surprised. I tested it on 4 different machines not connected to each other.
3) Let's analyze the results you got. Initially, your application is 49 megabytes, but at the time the landfill is rising up to 180 megabytes! And it is not fast and not on the big screen. Try the on-screen 24-inch full screen to do the same. We have about 400-600 megabytes, but it's just a huge memory leak in the creation of a simple polygon!!! Do you think this "is normal"?
These problems arise not only from me, as I said above, so what I'm describing is not my imagination :) Add to that the original memory consumption of 200-400 megabytes (vector, tools and so on) in a 24-inch monitor (all the best for cartographers) and full-screen mode, increase the speed of the editor and the program is easy to fall with the exception of out of memory exception. Even in your application blank with a small screen (even if you have 24 inches he is not deployed on the entire screen) and the relatively slow mode of the memory increases by 3-4 times! it is very very much.
For example:
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/10170/afv/topic/Default.aspx
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/9278/afv/topic/Default.aspx
Hello Alex,
Thanks for your further information, as I said in post : gis.thinkgeo.com/Support/Dis...fault.aspx , we cannot control the GC, so there are 2 options you can choose:
1. Set the wpfMap.EditOverlay.RenderMode to RenderMode.GdiPlus.
2. Use the code below
wpfMap1.EditOverlay.Drawn += new EventHandler<DrawnOverlayEventArgs>(EditOverlay_Drawn);
void EditOverlay_Drawn(object sender, DrawnOverlayEventArgs e)
{
GC.Collect();
}
Gary
Thank you for your reply. This code definitely helps (just need to use Drawing but not Drawn).
But I think this is not the correct solution (which incidentally says a well-known Jeffrey Richter), for several reasons:
1) There is no guarantee that the garbage collector is triggered at a time when we are trying to call.
2) increasing the load on the processor and, generally speaking, not very clear until the impact is on other processes or not (permanent call the garbage collector).
I understand that this problem is quite extensive. I watched the memory profiler that you have going on and where it goes memory, and I realized that you’re drawing a Bitmaps all time. Maybe you have not called destruction of Bitmap (System.Windows.Media.Imaging), which we no longer need? Just from memory at time T (with a strong rotation of the object to the scheme that I described above), we get about 200 bitmap-s, each of which is 5 megabytes. Although it is doubtful that we need all 200 pieces. Maybe worth a look in this direction?
I looked at your code by disassembler. Do you have a function in InteractiveOverlay responsible for rendering:
{
int num1 = (int) this.MapArguments.ActualWidth;
int num2 = (int) this.MapArguments.ActualHeight;
if (this.RenderMode == RenderMode.DrawingVisual)
{
DrawingVisualGeoCanvas drawingVisualGeoCanvas = new DrawingVisualGeoCanvas();
RenderTargetBitmap renderTargetBitmap = new RenderTargetBitmap(num1, num2, (double) drawingVisualGeoCanvas.Dpi, (double) drawingVisualGeoCanvas.Dpi, PixelFormats.Pbgra32);
drawingVisualGeoCanvas.BeginDrawing((object) renderTargetBitmap, param0.TargetExtent, this.MapArguments.MapUnit);
this.DrawTileCore((GeoCanvas) drawingVisualGeoCanvas);
drawingVisualGeoCanvas.EndDrawing();
param0.CommitDrawing((GeoCanvas) drawingVisualGeoCanvas, (object) renderTargetBitmap);
}
else
{
using (Bitmap bitmap = new Bitmap(num1, num2))
{
GdiPlusGeoCanvas gdiPlusGeoCanvas = new GdiPlusGeoCanvas();
gdiPlusGeoCanvas.BeginDrawing((object) bitmap, param0.TargetExtent, this.MapArguments.MapUnit);
this.DrawTileCore((GeoCanvas) gdiPlusGeoCanvas);
gdiPlusGeoCanvas.EndDrawing();
param0.CommitDrawing((GeoCanvas) gdiPlusGeoCanvas, hxQ\u003D.yRQ\u003D((object) bitmap));
}
}
}
If you use RenderMode = DrawingVisual (namely the need to use it, and otherwise there are significant gaps in the code). If you use RenderMode! = DrawingVisual (even though it was his and should be used differently, there are significant gaps in the code), then you allocate memory for Bitmap is using {}, so it is automatically cleared. But if RenderMode = DrawingVisual, then you simply create an object renderTargetBitmap and nowhere do with it not happening. I think at the end of
param0.CommitDrawing((GeoCanvas) drawingVisualGeoCanvas, (object) renderTargetBitmap);
param0.CommitDrawing((GeoCanvas) drawingVisualGeoCanvas, (object) renderTargetBitmap);
it should be cleaned at the end (equal null / dispose () and so on).
P.S. I tried to use the gdiplus, but I'm not very pleased with the rapid rotation of the reaction, there is sometimes a half-second delay, but they are visible and unpleasant. If there is no such DrawingVisual. In general, the behavior that got hung on the DrawingVisual + GC.Collect(). I really like it except that it is necessary to cause each time GC.
Hello Alex,
Have you try to update the .net framework 3.5 sp1? because I found that in this service pack, Microsoft solved a memory leak of the RenderTargetBitmap class, support.microsoft.com/kb/967634/ , I did some test on a computer which Memory is 700MB and has applied the .net 3.5 sp1, before I ran the HowDoISamples, the memory has 500MB used, so that means I have only 200MB to run the sample, as I ran the sample and rotate the shape rapidly the memory never reach 700MB and the OutOfMemoryException hasn’t been thrown, so I think the GC took care of the memory.
Please let me know your result.
Regards,
Gary
Thank you, Gary.
1) Windows 7 already has .Net framework 3.5 sp1;
2) I run under .net framework 4.0, which I think contains all fixed bugs of previous versions.
In any case, I have collected a 3.5, but nothing has changed.
We have within the team analyzed the existing problem and discovered that the problem is inside the RenderTargetBitmap from Microsoft.
Many people complain that there is a problem, everybody use GC.Collect (), but then again everyone is saying that this is a bad decision. Microsoft released a patch supposed to fix this bug, but neither we nor the many other users of the patch has not changed anything.
Let’s try to go on the other hand, why do you use this class (RenderTargetBitmap )? There may be other solutions with the use of any other class, for example Bitmap? Thank you.
Hello Alex,
Thanks for your suggestion to use the other classes rather than RenderTargetBitmap in wpf, but as far as we know, there isn’t any other options for us now, we will do more investigation after the 6.0 release, and if we find any way to fix this, I will post here and let you know.
Regards,
Gary
Hello Alex,
We actually considered all of the render solutions in WPF; but finally current way is the best one. For several reasons below,
1. We should know that current way is not a memory leak, for it can be collected by GC, even though it is not be collected in time. MS has a hotfix for this issue, please refer to this article.
support.microsoft.com/kb/967634/
2. Current GeoCanvases are very stabled now, and they work fine in our scenarios. If we want a new drawing way, it will take time on testing all our scenarios and evaluate its performance and compatibility.
3. To find a better balance between the speed and responding, DrawingVisual is the best choice which works with RenderTargetBitmap. Here is a related article.
msdn.microsoft.com/en-us/lib...al_Objects
Quote:
The DrawingVisual object is a lightweight drawing class that is used to render shapes, images, or text. This class is considered lightweight because it does not provide layout or event handling, which improves its performance. For this reason, drawings are ideal for backgrounds and clip art. For more information, see Using DrawingVisual Objects.
4. Other than integrated WPF render methods, they have worse performance and lower responding, so we didn’t choose them.
5. The only last choice is using WritableBitmap, for the drawing performance might be good as this our current one, but it doesn’t support many effect we want to use, so most of our GeoStyles won’t be supported.
6. One comments is that if they want to change to use some other ways for rendering other than the WPF region, we might suggest use Windows Imaging Component extension, but I think it won’t be better than rendering with GDI+ when rendering small features just like editing.
Please feel free to let us know your queries.
Regards,
Gary