Skiasharp: SKGLView does not dispose or release memory [Xamarin Forms UWP]

[comfr3ak]

Description

When using SKGlView in UWP on a page in a grid and then navigating away from that page, the SKGLView never disposes. If you create a new page with a new SKGLView they just keep building up in memory. There is no dispose method on SKGLView to release the underlying UWP native drawing objects.

Code

Expected Behavior

After the page is gone from the navigation stack and the SKGLView is disconnected from the PaintSurface event, it should release and dispose with the page.

Actual Behavior

SKGLView remains in memory and each time a new one is created, none of them dispose themselves according to VS2017 memory profiler.

Basic Information

• Version with issue: 1.60.3
• Last known good version:
• IDE: VS2017
• Platform Target Frameworks: UWP
  
  
  
  • Android:
  
  
  • iOS:
  
  
  • Linux:
  
  
  • macOS:
  
  
  • Tizen:
  
  
  • tvOS:
  
  
  • UWP:
  
  
  • watchOS:
  
  
  • Windows Classic:
  
  
• Target Devices:
  
  
  
  
  

Screenshots

Reproduction Link

VS bug #735693

[charlesroddie]

We are also seeing this. CC @sir-deenicus

[charlesroddie]

This also applies to 1.68.0.

This makes SkiaSharp an extremely large memory leak.

@mattleibow do you have any ideas?

It's a little surprising that SKGLView is not IDisposable, since a lot of other SkiaSharp objects are.

[mattleibow]

Thanks for reporting this, I am having a look at this. I'll let you know what I find, and if there are any workarounds/solutions.

[charlesroddie]

There is some work exploring this in the CSharpMath repo: https://github.com/verybadcat/CSharpMath/issues/23

[mattleibow]

Thanks for that issue. I'll see if I can get back to you today.

[mattleibow]

I am having a look at this, and the sample attached to the CSharpMath issue has cycles - the renderer keeps a reference to the native view which has a reference to the renderer, and the cycle is complete.

[mattleibow]

Although, something is happening here...

I know this is the SKCanvasView... Will try the SKGLView in a sec.

The first block is the start/baseline. Then I add a SKCanvasView, and it goes up high. I cleared the view and did a snapshot - for some reason it still had 40 items. Then, 3 seconds later, it magically cleared up again:

[mattleibow]

I am still looking at this...

After several tests and all sorts of hacks, I can pretty much say that there is no leak on the MANAGED side of the GL view and SkiaSharp. If I add hundreds to the UI and then clear and do a GC, the number of objects returns to the same number. Also, all managed objects in the SkiaSharp world get collected. In fact, the actual managed memory usage stays around 6MB throughout this entire process.

But, the native memory still keeps growing. 😭

I am trying to find out what is happening and what objects are still living...

[mattleibow]

Yay! 🎉🎉🎉 Found the issue - I had to dig deep! Not really, just a lot of testing.

What was happening was the view was initializing ANGLE, and then releasing all the references and things - except for the final context. This left all sorts of references on the native side still hooked up _inside_ the ANGLE library. As a result, even though the managed GC was all free, ANGLE was never told that it should let go of the views.

Just doing some final tests. As soon as CI is ready with a build, I'll link to it here so you can give it a go.

[mattleibow]

The new graph! I took the same sample, and upgraded to my "preview" NuGets and this is what we see with a nested loop of creating 150 panels, 30 times:

_(not only are the object cleaned up, but we also don't reach those crazy gigabyte amounts of memory)_

[comfr3ak]

How can I get the fix within vs2017? Is there a new preview version to
install from nuget?

On Wed, Dec 26, 2018 at 3:19 AM Matthew Leibowitz [e-mail]
wrote:

Closed #705 https://github.com/mono/SkiaSharp/issues/705.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mono/SkiaSharp/issues/705#event-2044313490, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Amjxo4LwGTz2GyNTvSXZ_Wxe9C4jYcDZks5u8zEbgaJpZM4YzFz3
.

[Happypig375]

I think we'll need to wait for a new NuGet prerelease to be published.

[mattleibow]

I am working on merging a few branches and then I hope to get a preview release out. Can't say for sure, but might be next week sometime.

[mattleibow]

@comfr3ak @charlesroddie @Happypig375 I have pushed out a preview release to our Early Access Program feed - let me know if this works for you: https://www.myget.org/F/skiasharp-eap/api/v3/index.json

[Happypig375]

There is a new crash with 1.68.1-preview71.

Reproduction:

1. Start debugging skia-leak-min (the sample in CSharpMath)
2. Click "GL View Mathview"
3. Wait for UI to respond
4. Click "GL View Mathview" again
5. Wait for debugger to break
6. Debugger breaks at

#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
    if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
#endif

Exception message:

System.Exception: Failed to create EGL surface
   at SkiaSharp.Views.GlesInterop.GlesContext.CreateSurface(SwapChainPanel panel, Nullable`1 renderSurfaceSize, Nullable`1 resolutionScale)
   at SkiaSharp.Views.UWP.AngleSwapChainPanel.EnsureRenderSurface()
   at SkiaSharp.Views.UWP.AngleSwapChainPanel.OnSizeChanged(Object sender, SizeChangedEventArgs e)

[mattleibow]

Darn, let me have a look.

[mattleibow]

This was fixed in #1024