Avalonia DataGrid Memory Leak: 300MB → 2GB+ with specific data patterns in v12.0.0

[4Darmygeometry]

Describe the bug

When upgrading from Avalonia 11.3.13 to 12.0.0, the DataGrid control exhibits a severe memory leak issue with specific real-world data patterns. Displaying 1000+ rows of warehouse control system (WCS) task data causes memory usage to spike from approximately 300MB to over 2GB. Additionally, the initial query performance degrades significantly.

See the screenshot below:

Important: This issue cannot be reproduced with simple mock data (English strings only). It requires specific data characteristics:

• Mixed Chinese/English text content
• Multiple data types: int, string, DateTime, nullable DateTime?
• 18+ columns with StringFormat bindings for dates
• Real database query results (not synthetic data)

This makes Avalonia 12.x unusable for enterprise applications displaying complex real-world datasets.

To Reproduce

Note: Minimal reproduction with mock data does NOT trigger this issue. The problem only manifests with real database data having the characteristics described above.

Steps:

1. Use the attached complete project WCS.Avalonia.zip (114.5KB)
2. Restore the attached database (contains WCS task data)
3. Run the application with Avalonia 12.0.0
4. Navigate to the task query page
5. Load 1000+ rows of task data
6. Observe memory usage in Task Manager or VS Diagnostic Tools

Attached Files:

• WCS.Avalonia.zip - Complete source code (114.5KB)
• hjltk_data.zip - MySQL database backup with real WCS data

Data Characteristics That Trigger the Issue:

// Model with mixed types and Chinese content
public class TaskItem
{
    public int Id { get; set; }
    public string TaskTypeName { get; set; } // "入库", "出库", "任务完成成功"
    public DateTime CreateTime { get; set; }
    public DateTime? StartTime { get; set; } // Nullable dates
    public DateTime? EndTime { get; set; }
    // ... 14 more columns
}

XAML with date formatting:

<DataGridTextColumn Header="创建时间" 
                    Binding="{Binding CreateTime, StringFormat='yyyy/M/d HH:mm:ss'}" />

What We Tried (Does NOT Reproduce)

We attempted to create a minimal reproduction with:

• Simple English string data only → Memory stays normal (~300MB)
• Mock data with same structure → Cannot reproduce the leak
• Same row count (1000+) → No issue with synthetic data

Only the complete project with real database triggers the 2GB+ memory spike.

Expected behavior

Memory usage should remain stable around 300-400MB for 1000 rows (as in v11.3.13)
Initial query and display should be fast and responsive
No significant memory growth when scrolling or interacting with the DataGrid

Avalonia version

12.0.0

OS

Windows

Additional context

Data Pattern Analysis

The issue appears to be triggered by specific combinations:

1. Chinese characters in string fields (task status descriptions)
2. DateTime formatting via StringFormat in XAML bindings
3. Nullable DateTime fields (DateTime?)
4. 18 columns with mixed data types
5. Real database query results (not in-memory generated data)

Verification

• Downgrading to Avalonia 11.3.13 completely resolves the issue
• Other packages (MySqlConnector, Microsoft.Data.SqlClient, etc.) ruled out
• Same data access code and view models work fine in 11.3.13
• Issue is reproducible 100% of the time with attached files

Impact

This is a critical regression that prevents upgrading to Avalonia 12.x for enterprise applications displaying real-world datasets with:

• International character sets (Chinese, Japanese, etc.)
• Complex data types and formatting
• Database-driven DataGrid displays

[4Darmygeometry]

OS:Windows 11 25H2 x86_64

[Gillibald]

Looks like a font loading / caching issue. Did you profile your application? What objects are leaking?

[4Darmygeometry]

Hi Gillibald,

This is definitely not a font/caching issue, and here's the 100% conclusive proof:

​

• The exact same code, same data, same environment, same fonts works perfectly in Avalonia 11.3.13, with stable ~300MB memory usage.
  ​
• The only change is upgrading to Avalonia 12.0.0, which causes the memory to explode to 2GB+.
  ​
• Downgrading back to 11.3.13 immediately resolves the leak with zero code changes.

If this were a font issue, it would manifest in 11.3.13 as well. The regression is 100% caused by changes in Avalonia 12's DataGrid/text rendering pipeline, specifically for CJK/mixed-language real-world datasets.

WCS.Avalonia project is a software that read and write MySQL/SQL Server database and control stackers

[wanx2026]

Remove the ScrollViewer from the DataGrid's outer layer, and then you'll get a surprise.

Why? It's probably because the DataGrid renders all rows instead of only the visible rows within the viewport.