В каких сценариях делает замораживающийся бенефис объектов WPF значительно?
Этого можно добиться с помощью функции «textconv», используя инструмент fold в качестве фильтра.
Он должен быть настроен в два этапа.
Определить драйвер
Это можно сделать для репозитория, запустив
git config diff.DRIVER.textconv 'fold -s'
или отредактировав .git/config, чтобы он содержал
[diff "DRIVER"]
textconv = fold -s
, или глобально:
git config --global diff.DRIVER.textconv 'fold -s'
Инструмент fold может быть заменен более интеллектуальными языковыми фильтрами по мере необходимости. Опция -s делает сгиб в пробельных символах.
В Windows утилита свертывания может использовать окончания строки DOS, которые могут конфликтовать с вашими настройками для репозитория, что приводит к ложным ^M символам в diff. Это можно исправить, используя вместо этого
sh -c 'fold "[113]" | dos2unix'
Обертку sh, поскольку протокол textconv ожидает, что указанная команда примет одно имя файла в качестве аргумента, и выдаст свой вывод на STDOUT.
Конфигурирование .gitattributes
Установите файл .gitattributes, содержащий
PATTERN diff=DRIVER
Здесь DRIVER - произвольное имя драйвера и PATTERN сопоставление с шаблоном подстановки файлы, к которым он должен быть применен, например * для «всех файлов» или *.EXT для файлов с расширением .EXT.
Пример
Например, для запуска файлов * .tex через фильтр «fold» с помощью «dos2unix»:
=== .gitattributes ===
*.tex diff=tex
=== .git/config ===
[diff "tex"]
textconv = sh -c 'fold "[115]" | dos2unix'
2 ответа
Возможно, вам будет интересен мой опыт работы с Freezable:
Однажды я написал программу просмотра PDF с использованием muPdf, которая рендерит растровые изображения, которые я рендерил с помощью WPF. Что значительно повышает производительность, так это то, что я могу рендерить растровые изображения страниц в фоновом потоке, замораживать их, а затем передавать в поток пользовательского интерфейса. Приятно, что WPF не копирует изображение, чтобы заморозить его, но возможность выполнять всю эту подготовку в фоновом потоке была для меня ключевым преимуществом.
Насколько я понимаю, все визуальные изображения должны быть заморожены, чтобы их можно было безопасно отрисовать в потоке рендеринга WPF. Если вы рендерите большие незамороженные визуальные объекты, то при рендеринге WPF они будут клонированы в замороженные. Если вы заранее заморозите статические растровые изображения, WPF может просто поделиться указателем с потоком рендеринга без клонирования. Незамороженные объекты могут даже копироваться многократно, если WPF не знает, изменился ли объект с момента последнего рендеринга. Замороженные объекты устраняют необходимость в таком копировании.
Эти потенциальные утечки памяти могут произойти, если вы используете элемент управления Image (а не метод Freeze):
a) Вы используете BitmapImage в качестве источника изображения и не выпускаете BitmapImage:
static BitmapImage bi1 = new BitmapImage(new Uri("Bitmap1.bmp",UriKind.RelativeOrAbsolute));
m_Image1 = new Image();
m_Image1.Source = bi1;
//bi1.Freeze()
//if you do not Freeze, your app will leak memory.
MyStackPanel.Children.Add(m_Image1);
б) Вы назначаете несколько BitmapImage в качестве источника изображения и не выпускаете весь BitmapImage, который вы использовали (аналогично (a)). Это введено в .Net 3.5:
static BitmapImage bi1 = new BitmapImage(new Uri("Bitmap1.bmp",
UriKind.RelativeOrAbsolute));
static BitmapImage bi2 = new BitmapImage(new Uri("Bitmap2.bmp",
UriKind.RelativeOrAbsolute));
bi2.Freeze();
m_Image1 = new Image();
//bi1.Freeze()
//even though you are really using bi2 for Image Source,
//you also need to Freeze bi1 it to avoid leak
m_Image1.Source = bi1; // use un-frozen bitmap, which causes the leak
m_Image1.Source = bi2; // use frozen bitmap
MyStackPanel.Children.Add(m_Image1);
Источник: Производительность WPF