MaterialDesignInXamlToolkit: Button styles: MaterialDesignRaisedButton used with MahApps.Metro causes serious memory leak

@AndrewKeepCoding Yes, I just tested your solution, setting the shadow effect to DP0, and it indeed solves the issue. materialDesignWpf:ElevationAssist.Elevation="Dp0"

@AndrewKeepCoding @gitjsdr26 Yes, this method does work: RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly; However, from what I understand, setting the rendering mode to software rendering can potentially lead to a performance drop in terms of graphics, especially when dealing with complex graphics or animations. Sacrificing more for the sake of resolving a memory leak issue caused by a specific button animation might not align with the expectations of most projects. It would be ideal if the issue could be resolved while still allowing GPU acceleration.

This might be the reason that you can’t reproduce the memory leak.

After spending quite a bit of time trying to reproduce this the other day, I was very close to concluding that this must be a hardware-dependent (or at least system-dependent) issue. I think the issue you link to here is very interesting, and quite possible the issue we’re seeing. Could you, @shushu789, provide information about which graphics card you’re using. I am on NVIDIA GeForce which is likely why I can’t reproduce.

I also tried this on another computer (Win7 x64 English with Japanese IME installed) but didn’t reproduce the memory increase issue.

I think that this dotnet/wpf#7704 is somehow related to the issue. The computer that doesn’t reproduce the issue, has a NVIDIA GeForce GPU, whereas my laptop that does reproduce the issue, has an Intel Iris Xe Graphics GPU.

This might be the reason that you can’t reproduce the memory leak.

I totally missed @gitjsdr26 comment on ProcessRenderMode. It actually prevents the memory increasing.

RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;

I was able to reproduce this issue on a test app.

<mah:MetroWindow x:Class="Issue3065ReproApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:Issue3065ReproApp"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800"
        xmlns:mah="clr-namespace:MahApps.Metro.Controls;assembly=MahApps.Metro"
        xmlns:materialDesign="http://materialdesigninxaml.net/winfx/xaml/themes">
    <Grid>
      <Button
        materialDesign:ButtonProgressAssist.IsIndeterminate="True"
        materialDesign:ButtonProgressAssist.IsIndicatorVisible="True" />
    </Grid>
</mah:MetroWindow>

These are the facts that I’ve found so far:

• The issue can be reproduced:
  • by just running the repro-app and minimize it
  • whether the keyboard input is on English or Japanese IME
• The issue cannot be reproduced:
  • on the Sandbox environment
  • with a plain MainWindow
  • with just a ProgressBar without the Button
• Memory increasing slows down with longer animation key frames.
• Testing machine:
  • DELL XPS13
  • Windows 11 Pro 22H2
  • English by default
  • Japanese IME installed

I need to find some time to dig deeper so might take another few days. Since I’m not familiar with MaterialDesign, any tips are appreciated.

@nicolaihenriksen I’m having a similar issue, but I’m not using the MahApps.Metro library. There are also differences in the triggering method, see for details #3282

The problem looks like this：

thank you for your reply,I uploaded a demo project for this problem: https://github.com/shushu789/DotWPFDemo/tree/master