Memory leak on macOS with Metal rendering

[ltetak]

Describe the bug

There is a slow memory leak on macOS with metal rendering (does not repro on OpenGL or Software).

To Reproduce

Do anything that requires rendering but to speed things up drag a corner of the window and resize it a lot. This will gain 10MB/s. This memory is never freed up and climbs until the app eventually crashes (after a long time).
You can see this memory in the Activity Monitor under the Memory column. It's not calculated under Real Mem. I can't see it in dotMemory as well (is it a GPU memory?)

Expected behavior

Steady memory as with OpenGL or Software rendering.

Avalonia version

11.x - 11.2.0-beta2

OS

macOS

Additional context

It is more prominent since the Metal is the default renderer now #15994

[Mikolaytis]

We are using metal renderer in our app Lunacy since it was introduced. Zero issues at all. Maybe you are using a specific feature we don't use that causes the problem. This issue can be quickly addressed if you will provide a sample app with repro.

[ltetak]

@Mikolaytis open ControlCatalog.NetCore (desktop) on mac. Keep resizing the window for a while (a minute).

The same steps with OpenGL as the default renderer

[MrBandes]

I can confirm this issue is happening on a simple empty window as well. I move around the cursor resizing the window, and the memory usage jumps from 100 megabytes up to 1 gigabyte just in a second. Other than this, everything seems normal, but this surely needs to be fixed! Thanks in advance!

[almenscorner]

I can also replicate this, will have to hold off on the 11.2.0 update

[ltetak]

@almenscorner you don't have to. Switch to OpenGL and it will be fine.

          .With(new AvaloniaNativePlatformOptions
           {
               RenderingMode = new [] { AvaloniaNativeRenderingMode.OpenGl, AvaloniaNativeRenderingMode.Metal }
           })

[almenscorner]

Now that is looking very promising! thank you @ltetak

[MrBandes]

@ltetak OpenGL is somewhat better option than Metal currently regarding memory usage, but somehow this seems to best option right now : AvaloniaNativeRenderingMode.Software
without resizing any windows, Metal would use 400 Mbytes for a given app, OpenGL uses between 190 and 360 Mbytes, but the Software implementation does not even go above 200 Mbytes (120-190).
it seems to me somehow that for OpenGL(& Metal) the memory used for displaying objects is being doubled.
but this is just an assumption from me.

[maxkatz6]

@MrBandes hardware acceleration backends usually consume more memory, with Skia, regardless of the OS. Though, I don't have expertise to exactly pin-point the reason. Consuming more memory is not a memory leak though.

While this issue is about a specific leak.

[maxkatz6]

@ltetak can you check if leak exists after #17414 PR?
Or after this one #17415

[maxkatz6]

On my local tests, resizing window does increase memory usage, but only temporary, after couple of seconds it falls back.

Upd: Yes, memory usage is much more stable under #17415 for me.

[MrBandes]

@maxkatz6 i know that it's not the same issue. i am just confused now as i see technically the same amount of memory usage of the same application no matter if i choose OpenGL or Software rendering ON Windows. 60 Megabytes +/- 10%.
when opening and closing windows, there are some fluctuations.
but in the same time on MacOS the minimum memory usage is double right away. still would not be that big of a problem, BUT there are memory spikes like +/- 50% or even more. i know that Windows Task Manager does not show the same memory usage as MacOS Activity Monitor, and perhaps more gpu memory is used on Windows, but even then i just don't understand why a 600x400 windows needs 150 megabytes of extra ram in a second just to show up itself.
i would say OpenGL takes up lot of memory here and there suddenly but that memory gets released at least later, whereas the Metal memory leak is like multiplied of that but it never gets released.
i just feel that there are too much memory resources being used on OpenGL too, not leak-wise. compared to windows. as i mentioned on MacOS the Software rendering mode takes at maximum 3x the amount of Windows memory usage and that seems ok to me.
as i know that there is unified memory on MacOS, just because OpenGL needs perhaps more framebuffer memory, it still not should not be the double amount i think.
even different issue though i would notice that on Windows the animation speed is very poor regardless what rendering mode i choose, whereas on MacOS its almost always smooth. perhaps i will post an issue about that later. showing a dialogbox animation is sluggish as hell. could not find any configuration options about such. mac cpu is 3x faster than my windows cpu, but anyway even the OpenGL rendering mode is snail-paced. but whatever.

generally the memory usage of an Avalonia application on Windows seems very optimized already, i don't know what should be "normal" on MacOS, but compared to the other it seems a bit too much. this could be somewhat netcore related also and not just because of rendering, but it would need more digging to find it out, but i am not that advanced on these topics.

[ltetak]

@maxkatz6 I tried this nuget 11.3.999-cibuild0052981-alpha (should be with this PR #17415) and it seems fine there! Thanks a lot!

I don't have strong data but OpenGL seems still a bit better now. Window resizing stutters from time to time with Metal. Memory consumption is about the same.
btw. macOS rendering is subjectively much much better than Windows rendering. Very good job there.

For completeness: I tried the Software rendering as well. Memory is 500MB lower indeed. The performance is not bad but it stutters at moments (OpenGL is almost flawless). It probably depends on the use case. I work on a video player app where stuttering (missed frames) is not an option. On a normal desktop app you might not mind that.

[maxkatz6]

Reopening as #17415 wasn't yet merged

[maxkatz6]

Actually. Just retested on master and #17414 was enough to fix the leak. It does consume more memory than opengl renderer, but that's another issue.