ThinkGeo.com    |     Documentation    |     Premium Support

GC.Collect collings when drawing Graphic shape

#1

Hello
We are using GdalRasterLayer in order to display Geographic image. The version in use is 9.0.0.118
We noticed that when we draw a graphic shape there are huge amount of calling to GC.Collect.
The GC.collect calls are not done by our code, so we assume it is caused by your internal logic of shape drawing. This is a major problem for our client, we highly suspect this is even causing to a complete freeze of the application in certain cases.

Attached 3 file:

  • Image of the shape we draw : polyline with 17 points
  • image of GC collect status before starting the drawing (- only 4 GC collect calls)
  • image of GC collect status after the drawing (- 96 GC collect calls !!)
    First we would like to know, what is causing this? What logic on your side triggers this, and why is it needed?
    Secondly, do you have any suggestions how to minimize or eliminate as much GC collect callings while drawing shapes?

I will note that we tried to work
_map.TrackOverlay.RenderMode = RenderMode.GdiPlus;
Instead of the default mode
_map.EditOverlay.RenderMode = RenderMode.DrawingVisual
but did not saw any changes of behavior regarding the problem we described

Thank you

gc collect problem.zip (298.9 KB)

#2

Hi Miri,

Our GdalRasterLayer is a wrapper for Gdal library, please let us know what’s the type layer you need to drawn by GdalRasterLayer.

I cannot make sure what’s the reason of GC collection is called in your scenario, I think more code or a sample can reproduce it should be helpful.

Regards,

Ethan

#3

Thank you.
I understand the licence you provide for the office computer is specific of one computer.
Can I later on move that license to another offline computer?

#4

Hi Miri,

I think your reply is for your other topic: Activating license on an offline computer

Just like I mentioned, the offline deactivate is what’s the problem, we don’t have a guide for it. Please contact your sales to make sure its feasibility.

Regards,

Ethan