High memory usage on UWP when resizing

[charlesroddie]

Tested on latest SkiaSharp release, on fresh blank UWP app with:

var skv = new SkiaSharp.Views.UWP.SKXamlCanvas
{
    HorizontalAlignment = HorizontalAlignment.Stretch,
    VerticalAlignment = VerticalAlignment.Stretch
};
skv.PaintSurface += (_, ea) =>
{
    ea.Surface.Canvas.Clear(SkiaSharp.SKColors.Orange);
};

// Create a Frame to act as the navigation context and navigate to the first page
rootFrame = new Frame
{
    Content = skv
};

• Open the UWP app. Task manager shows 25MB used.
• Resize it to fill a 1440p screen It notw takes 700MB. Sometimes this drops back down to 200MB and sometimes it stays in place.
• When the window is resized to be small again, memory goes down to 400MB.

The numbers are variable and the high memory usage depends on gradual resizing.

I would expect a SkiaSharp view filling a 1440p screen to take 15MB at most (n. of pixels * 4 bytes).

[charlesroddie]

The SKSwapChainPanel doesn't suffer from the memory problems, but does have some update slowness when dragging, resulting in some temporary and permanent visual glitches.

[charlesroddie]

@mattleibow are you able to reproduce this?

[mattleibow]

I had a look and there are some interesting things that happen. For a start, I create the page and resize it as small as it can go. After a few minutes, the GC kicks in and reduces the memory usage to 36 MB.

From this base point, I maximize to a full screen: 3840x2160 at 250% scaling.

A few things happen:

1. The canvas triggers a draw with a view size of 1536x798. This results in a new WriteableBitmap with pixel dimensions of 3840x1995. This is expected with a 2.5 scale from the view(due to screen scaling). This means there are 30,643,200 pixel or 29.22MB.
2. Immediately afterwards, UWP triggers a new size event, but with slightly different dimensions of 1536x792. This again triggers another new bitmap with pixel dimensions of 3840x1980. This is 30,412,800 pixels or another 29MB.

In total, there is an additional 58.22MB from the base 36MB bringing the total to 94.22MB.

I tried again after doing things and it went from 110MB to 176MB (+66MB) and after a second, down to 147MB (-29MB).

When drag-resizing, there also seems to be this double render issue. At this point, it appears that due to scaling, the view's size is getting the decimal point sizes due to scaling, but then settles down to integer values when you release.

However, after a few minutes the GC will kick in and release the backing bitmaps and the usage drops down to the starting value. This also happens on WPF due to the fact that I actually do not control the bitmap, it is the framework that does it. And, unfortunately, there does not appear to be a way to request that the bitmaps be disposed immediately.

[charlesroddie]

Ah I did not wait long enough for GC. Not a leak then, but memory is still a problem and the current architecture doesn't seem right.

Using GCed bitmaps is a problem. Can't an IDisposable type be used to give control? Perhaps SKBitmap itself? We are used to using IDisposables in SkiaSharp and a huge chunk of memory is a perfect candidate to be IDisposable!

[mattleibow]

This is not my memory, this is the UWP WriteableBitmap type which is not disposable unfortunately.

I will have another look and see if I can get a reverse model where I allocate the data and then just wrap it with a WriteableBitmap.

[RChrisCoble]

Not recommended, but you can try:

System.GC.Collect();
System.GC.WaitForPendingFinalizers();

[RChrisCoble]

Or if you really want to get nasty:

    public class MemoryManagement
    {
        [DllImport("kernel32.dll")]
        public static extern bool SetProcessWorkingSetSize(IntPtr proc, int min, int max);

        public static void FlushMemory()
        {
            GC.Collect();
            GC.WaitForPendingFinalizers();
            if (Environment.OSVersion.Platform == PlatformID.Win32NT)
            {
                SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
            }
        }
    } 

[mattleibow]

I got a basic sample here and tried something bad. When you start the app, spam the GC. It drops to 36MB. I then resize like crazy and get it up to 700MB. After spamming the GC, it drops right down to 36MB again.

Another thing is that the GC seems to be some sort of tiered or slow async version. If you watch the GC collect, it is going in steps. Even between manual GCs.

I have a stack of RAM (32GB) and I wonder what the difference would be on a 2 or 4GB machine. Will the GC be more aggressive? If you think about it, my GC does not have to be too aggressive because the big 700MB is just 2% of the available. On a 4 GB machine, it will be a 17%, so maybe it will be more aggressive and keep lower?

[mattleibow]

In fact, I know the GC works asynchronously because I had to fix a bug in the cleanup of skia objects to handle the GC running on a different thread.