Pre loader

ExportToFile is not freeing up memory afterwards

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

0
0

Hi,

I have an application where I can potentially create, plot and export (as png) hundreds of graphs. It all runs smoothly but the “ExportToFile” method of the SciChartSurface. It seems to never de-allocate the memory it uses even after disposing the SciChartSurface itself. After a few hundred graphs, the application ends up using 70Gb+ of ram but if I just comment out the ExportToFile line, the application never uses more than 2Gb of ram (as expected).

I’ve tried putting:
GC.Collect();
GC.WaitForPendingFinalizers();
…both after the ExportToFile and after disposing the graphs, but it makes no difference.

Has anyone experienced this issue? Is there anything else that I can try?

Thanks
/Daniel

Version
4.0.x
  • You must to post comments
0
0

Hi,

I’m still completely blocked by this. It seems like the problem is a memory lead in the BitmapEncoder library, but I can’t work my way around it since SciChart can only return a BitmapSource.

You can see in the attached image that the “Unmanaged Memory” heap grows for each graph image that I save/export and that can never be claimed back….

Using the code: (MainChart is an instance of a SciChartSurface)

using (var fileStream = new FileStream(imgName, FileMode.Create))
{
    var encoder = new PngBitmapEncoder();
    encoder.Frames.Add(BitmapFrame.Create(MainChart.ExportToBitmapSource()));
    encoder.Save(fileStream);
}

..leaks just as much memory as using the:

MainChart.ExportToFile(imgName, expType, false);

Using FreeImage to save the file makes no difference because I still depend on the BitmapEncoder to convert the BitmapSource into a Bitmap:

 using (var outStream = new MemoryStream())
        {
            BitmapEncoder enc = new BmpBitmapEncoder();
            enc.Frames.Add(BitmapFrame.Create(MainChart.ExportToBitmapSource()));
            enc.Save(outStream);
            enc.Frames.Clear();
            using (var bitmap = new Bitmap(outStream))
                FreeImage.SaveBitmap(bitmap, imgName, FREE_IMAGE_FORMAT.FIF_PNG, FR
    EE_IMAGE_SAVE_FLAGS.PNG_Z_DEFAULT_COMPRESSION);
    }

Does anyone have any ideas on how I can circumvent this leak?

Images
  • Andrew Burnett-Thompson
    Hi Daniel, you mention you are using v4.0 of SciChart. Does the same issue occur in the latest release v4.2.4? Best regards, Andrew
  • Jonathan Janesjö
    Hey, thanks for the reply. I think I’m using 4.2.2, but I’m not sure where to check it.
  • Jonathan Janesjö
    As far as I understood it, the leak is in the BitmapEncoder.Save() method. I found a post somewhere saying that this is a known issue by Microsoft but according to them it only happens while debugging the application. This is not the case for me, I get the same behavior when running it too.
  • Heiko Hartmann
    This is still a problem. We have an application based on Scichart 5.1.0.11246 that saves periodically (every 1 sec) images (aprox . 1MB) in png format. sciChartSurface.ExportToFile(filename, ExportType.Png, false, new Size(width, height)); After about 30 minutes we have an increased memory about 2GB. When the images are not saved there is no increase in memory. Did you find any solution for your memory leak?
  • Andrew Burnett-Thompson
    Hi Florentin, we will need code to analyse this problem. If you can reproduce it and sent it to support as a bug report, our team can profile and investigate.
  • You must to post comments
0
0

I was having this same problem: large leaks of unmanaged memory with every call to ExportToFile.

In my case, I was running the chart surface generation and exporting on STA threads, and the fix for the leaking is to run the generation and exporting specifically on the UI thread. It is not sufficient to be on a plain STA thread, the code has to run on the UI thread.

Maybe there’s an issue in Windows or SciChart, and this is a workaround, but at this point, I’m just happy to not be leaking anymore.

I use F#, and it’s been years since I did any C#, so I’d probably get it wrong if I tried to translate my code to C# here. I think it should be clear what I’m doing:

type private ChartDelegate = delegate of unit -> unit
...
let cd = ChartDelegate (fun () -> self.WriteXyScatterChart common tsList ipText)
System.Windows.Application.Current.Dispatcher.BeginInvoke (DispatcherPriority.ContextIdle, cd) |> ignore

…where self.WriteXyScatterChart common tsList ipText is my function + args to create and write a chart.

Really was pulling my hair out trying to sort this problem out. I hope this helps out someone else at some point.

  • Michael Purchine
    I don’t know why those br elements are showing up in the code section above.
  • You must to post comments
0
0

I have same problem by the way, it looks like scichart has this problem like 3-4 years but doesn’t fixed it

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies