Rendertargetbitmap GDI дескриптор утечки в Master-подробная информация
у меня есть приложение с видом Master-Details. Когда вы выбираете элемент из списка "master", он заполняет область "details" некоторыми изображениями (созданными с помощью RenderTargetBitmap).
каждый раз, когда я выбираю другой главный элемент из списка, количество дескрипторов GDI, используемых моим приложением (как сообщается в Process Explorer), увеличивается - и в конечном итоге падает (или иногда блокируется) на 10 000 используемых дескрипторов GDI.
Я в недоумении, как это исправить, поэтому любые предложения о том, что я делаю неправильно (или просто предложения о том, как получить больше информации) будет очень признателен.
я упростил свое приложение до следующего в новом приложении WPF (.NET 4.0) под названием "DoesThisLeak":
В MainWindow.код XAML.cs
public partial class MainWindow : Window
{
public MainWindow()
{
ViewModel = new MasterViewModel();
InitializeComponent();
}
public MasterViewModel ViewModel { get; set; }
}
public class MasterViewModel : INotifyPropertyChanged
{
private MasterItem selectedMasterItem;
public IEnumerable<MasterItem> MasterItems
{
get
{
for (int i = 0; i < 100; i++)
{
yield return new MasterItem(i);
}
}
}
public MasterItem SelectedMasterItem
{
get { return selectedMasterItem; }
set
{
if (selectedMasterItem != value)
{
selectedMasterItem = value;
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs("SelectedMasterItem"));
}
}
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
public class MasterItem
{
private readonly int seed;
public MasterItem(int seed)
{
this.seed = seed;
}
public IEnumerable<ImageSource> Images
{
get
{
GC.Collect(); // Make sure it's not the lack of collections causing the problem
var random = new Random(seed);
for (int i = 0; i < 150; i++)
{
yield return MakeImage(random);
}
}
}
private ImageSource MakeImage(Random random)
{
const int size = 180;
var drawingVisual = new DrawingVisual();
using (DrawingContext drawingContext = drawingVisual.RenderOpen())
{
drawingContext.DrawRectangle(Brushes.Red, null, new Rect(random.NextDouble() * size, random.NextDouble() * size, random.NextDouble() * size, random.NextDouble() * size));
}
var bitmap = new RenderTargetBitmap(size, size, 96, 96, PixelFormats.Pbgra32);
bitmap.Render(drawingVisual);
bitmap.Freeze();
return bitmap;
}
}
В MainWindow.в XAML
<Window x:Class="DoesThisLeak.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="900" Width="1100"
x:Name="self">
<Grid DataContext="{Binding ElementName=self, Path=ViewModel}">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="210"/>
<ColumnDefinition Width="*"/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<ListBox Grid.Column="0" ItemsSource="{Binding MasterItems}" SelectedItem="{Binding SelectedMasterItem}"/>
<ItemsControl Grid.Column="1" ItemsSource="{Binding Path=SelectedMasterItem.Images}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<Image Source="{Binding}"/>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</Grid>
</Window>
вы можете воспроизвести проблему, если вы нажмете на первый элемент в списке, затем, удерживая клавишу курсора.
смотреть на !gcroot в WinDbg с SOS, я не могу найти ничего, что держит эти объекты RenderTargetBitmap живыми, но если я это сделаю !dumpheap -type System.Windows.Media.Imaging.RenderTargetBitmap он по-прежнему показывает несколько тысяч из них, которые не были собраны.
3 ответов
TL; DR: исправлено. Смотри внизу. Читайте дальше для моего путешествия открытия и все неправильные переулки я пошел вниз!
Я немного покопался с этим, и я не думаю, что это утечка как таковая. Если я увеличиваю GC, помещая эту сторону цикла В изображения:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
вы можете шагнуть (медленно) вниз по списку и не увидеть никаких изменений в дескрипторах GDI через несколько секунд. Действительно, проверка с MemoryProfiler подтверждает это - нет .net или GDI объектов утечки при перемещении медленно от предмета к предмету.
вы попадаете в неприятности, быстро двигаясь вниз по списку-я видел, как память процесса движется мимо 1.5 G, а объект GDI поднимается до 10000, когда он ударяется о стену. Каждый раз, когда MakeImage вызывался после этого, ошибка COM была брошена, и ничего полезного не могло быть сделано для процесса:
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in PresentationCore.dll
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in PresentationCore.dll
A first chance exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
System.Windows.Data Error: 8 : Cannot save value from target back to source. BindingExpression:Path=SelectedMasterItem; DataItem='MasterViewModel' (HashCode=28657291); target element is 'ListBox' (Name=''); target property is 'SelectedItem' (type 'Object') COMException:'System.Runtime.InteropServices.COMException (0x88980003): Exception from HRESULT: 0x88980003
at System.Windows.Media.Imaging.RenderTargetBitmap.FinalizeCreation()
Это, я думаю, объясняет, почему вы видите так много RenderTargetBitmaps висит вокруг. Он также предлагает мне стратегию смягчения-предполагая, что это рамочная программа/GDI жук. Попробуйте переместить код рендеринга (RenderImage) в домен, который позволит перезапустить базовый компонент COM. Первоначально я бы попробовал поток в собственной квартире (SetApartmentState (ApartmentState.STA)) и если это не сработает, я бы попробовал AppDomain.
тем не менее, было бы проще попытаться справиться с источником проблемы, который выделяет так много изображений так быстро, потому что даже если я получу его до 9000 дескрипторов GDI и немного подожду, количество падает обратно до базовая линия после следующего изменения (мне кажется, что в COM-объекте есть некоторая праздная обработка, которая требует нескольких секунд ничего, а затем еще одно изменение, чтобы освободить все его дескрипторы)
Я не думаю, что для этого есть какие - либо простые исправления-я попытался добавить сон, чтобы замедлить движение, и даже вызвать ComponentDispatched.RaiseIdle () - ни один из них не имеет никакого эффекта. Если бы мне пришлось заставить его работать таким образом, я бы попытался запустить обработку GDI перезапускаемым способом (и работа с ошибками, которые будут возникать) или изменение пользовательского интерфейса.
В зависимости от требований в детальном представлении, и, самое главное, видимость и размер изображений в правой части, вы можете воспользоваться возможностью ItemsControl виртуализировать свой список (но вы, вероятно, должны по крайней мере определить высоту и количество содержащихся изображений, чтобы он мог правильно управлять полосами прокрутки). Я предлагаю вернуть ObservableCollection изображений, а не чем объект IEnumerable.
на самом деле, только что Протестировав это, этот код, похоже, устранит проблему:
public ObservableCollection<ImageSource> Images
{
get
{
return new ObservableCollection<ImageSource>(ImageSources);
}
}
IEnumerable<ImageSource> ImageSources
{
get
{
var random = new Random(seed);
for (int i = 0; i < 150; i++)
{
yield return MakeImage(random);
}
}
}
главное, что это дает время выполнения, насколько я могу видеть, это количество элементов (которые перечисляемые, очевидно, нет), что означает, что он не должен перечислять его несколько раз, или угадать (!). Я могу бегать вверх и вниз по списку пальцем по клавише курсора без этого дует 10k ручки, даже с 1000 MasterItems, так что это выглядит хорошо, чтобы мне. (Мой код также не имеет явного GC)
Если вы клонируете в более простой тип растрового изображения (и замораживаете), он не будет использовать столько дескрипторов gdi, но он медленнее. Существует клонирование через сериализацию в ответе на Как достичь изображения.Clone () в WPF?"
попробуйте использовать решение, описанное здесь: RenderTargetBitmap.Render () выбрасывает исключение OutOfMemoryException при рендеринге больших визуальных элементов.
обновление: Кроме того, взгляните на RenderTargetBitmap Утечка Памяти.