[BUG] Suspect memory leak with SKPath on SKCanvas
Description
When I trigger the Draw by resizing the page by constantly dragging to resize, the memory use goes up lots. This is a cut down version and this almost doubles its memory usage. The main app grows by hundreds of mb.
Removing the SKCanvas from the form releases all the memory leaked.
Code
Expected Behavior
A small amount of growth would be ok, and then the GC cleans up to roughly where it was.
Actual Behavior
The memory grows to about double the size.
Basic Information
- Version with issue: 2.80.2
- Last known good version: ?
- IDE: VS 2019 Latest
- Platform Target Frameworks:
- UWP: 19041
- Target Devices
- UPW: Local machine
Screenshots

I have also been using the Skiasharp.SVG which also does the same.
Thankyou.
CONFIRMED. This one is a huge issue for us. We're in production now with crashes that occur, attributed to this memory leak, which goes rampant for certain app modes.
@najak3d I see you already commeneted here :)
Issue #2368 has more information.
@najak3d @radev8 are you able to try the latest stable 3.x version? OP of #2368 said that it was resolved for them.
Out of curiosity, I did some tests to see if this might be a related issue:
Observations:
- 2.80.2 and 2.88.9 behave completely differently in terms of memory usage and short-term memory allocation... (2.88.9 uses about 2x the RAM, VRAM usage is similar, but system GPU memory shows a clear upward trend)
- 2.88.9 is much more "spiky" in terms of memory usage when the canvas size changes rapidly.
- Personally, I wouldn't call the initial "doubling" of memory usage a leak, but that's up for debate...
- (It's more like +20 MB on 2.80.2. On 288.9 RAM usage actually doubles from 120mb to about 240mb)
- The actual memory "leakage" after resizing the canvas is relatively small. (A couple of megabytes) But there is an upwards trend. (This behavior is about the same for both versions.)
Sadly I was not able to update the provided debug project to SkiaSharp 3.x because UAP support was dropped (?) So I can't tell how things have changed since, but I would say that the problem described by @najak3d is different than the one I had.