Шаблоны оптимизации производительности растровых изображений

Я нашел несколько шаблонов для оптимизации обработки растровых изображений в WPF. Однако я не понимаю, когда использовать каждый шаблон. Поскольку я думаю, что это обычная проблема, я резюмировал то, что понимаю и предполагаю, и прошу вашей помощи.Если вы можете добавить шаблоны , объясните , чем они отличаются , объясните, используют ли они CPU или GPU , и научите , когда использовать каждый ] и как их объединить , это было бы огромным подспорьем!

Контекст - Сценарий «Сетка» изображений:

Мое приложение должно отображать много растровых изображений. Изображения отображаются на экране в виде сетки из строк и столбцов (не обязательно классы Grid или UniformGrid, как, например, представление альбома Window Media Player). Изображения могут перемещаться между разными ячейками сетки. Некоторые изображения в произвольных ячейках могут быть заменены другими. Изображения должны быть интерактивными, должны иметь контекстное меню, должны быть выбираемыми, перетаскиваемыми и т. Д. Другими словами, «объединение маленьких ошибок в одно большое растровое изображение» не применимо, по крайней мере, наивно.

Шаблон 0: Хак

Объедините маленькие жукеры в растровое изображение (как? Контекст рисования?) И используйте его в качестве фона. Наложите это на изображения с пустым содержимым, которое будет обрабатывать обращения, контекстные меню, события и т. Д.

Преимущество состоит в том, что здесь мы говорим только о двух растровых изображениях: текущее отображаемое и то, которое должно его заменить. Это должно быть очень быстро. Однако мой многолетний опыт поднимает красный флаг опасности. Ваши комментарии?

Шаблон 1: Уменьшение размера изображения

Это не проблема, когда вы заранее знаете размер изображения, до которого нужно изменить размер, и когда вы готовы потерять детали (цвет) для производительности:

1. Уменьшите размер растрового изображения с помощью BitmapImage.DecodePixelWidth
2. Уменьшите информацию о цвете с помощью FormatConvertedBitmap.DestinationFormat
3. Задайте для параметра Image.Stretch поведения масштабирования элемента управления значение Stretch.None
4. Установите SetBitmapScalingMode для изображения на LowQuality.
5. Заморозить баггер

См. Код здесь .

Шаблон 2: предварительная выборка фона

Этот шаблон применим, когда вы думаете, что можете воспользоваться преимуществом того, что пользователь смотрит на изображения на экране, и заранее подготовьте следующие изображения для отображения. Минусы вашего проекта, помимо накладных расходов на память, заключаются в том, что он должен поддерживать цель .Net Framework 4, а не только профиль клиента, поэтому он может потребовать установки на клиенте. Вам самому придется испытать боль асинхронного программирования.

В этом шаблоне вы создаете ровно необходимое количество элементов управления изображением. Когда растровые изображения необходимо добавить, переместить или удалить, вы изменяете только BitmapSource (s) элементов управления Image. Задача BackgroundWorker отвечает за предварительную выборку BitmapSource (-ов) (возможно, с использованием шаблона «Уменьшение размера изображения» выше) и их вставку в MemoryCache.

Чтобы это работало, вы должны установить для параметра BitmapImage CacheOption значение OnLoad, чтобы работа передавалась фоновому исполнителю.

Шаблон 3: Контекст рисования

Это было предложено Шелдоном Цзяо из службы поддержки Microsoft на форуме MSDN WPF здесь . См. Стр. 494, главу 15 «2D-графика» в WPF 4 Unleashed Адама Натана для описания DrawingContext. Я не могу сказать, что понимаю это. Согласно ответу здесь , я предполагаю, что это улучшит обработку чертежей геометрии, а не растровых изображений.Далее, я не думаю, что это поддержит требования к фокусу и событиям для изображений (плохо, что не объяснил требования лучше на форуме). Более того, меня беспокоит итоговое предложение книги: «Обратите внимание, что использование DrawingContext не меняет того факта, что вы работаете в системе с сохраненным режимом. Указанный розыгрыш происходит не сразу; команды сохраняются в WPF до тех пор, пока они не понадобятся.Это означает, что после того, как наш обработчик обработан, мы не сможем воспользоваться преимуществами параллелизма, как в случае «предварительной выборки в фоновом режиме».

Шаблон 4: записываемые растровые изображения

В документации MSDN здесь это описывается как система с двумя буферами: поток пользовательского интерфейса обновляет буфер; поток рендеринга WPF перемещает это в видеопамять.

Предполагаемое использование (см. здесь ) для растровых изображений, которые сильно меняются, например, в видеофильме, подобном отображению. Я не уверен, но, возможно, это можно было взломать и объединить с шаблоном предварительной выборки фона и использовать в сценарии сетки.

Шаблон 5: Кэшированное растровое изображение

В MSDN мало информации ( здесь ). В архиве форума WPF ( здесь ) объясняется, что «BitmapCache API предназначен для кэширования вашего контента (при аппаратном рендеринге) в видеопамяти, то есть он остается резидентным на вашем графическом процессоре. Это позволяет сэкономить на повторном рендеринге этого контента при его выводе на экран ». Это кажется отличной идеей. Однако я не уверен, в чем заключаются подводные камни и как это использовать.

Шаблон 6: RenderTargetBitmap

RenderTargetBitmap преобразует визуал в растровое изображение. Я не уверен, уместно ли это здесь. См. здесь .

Правка : Относительно вопроса Пола Хенеке: я написал, что «Мое приложение должно отображать много растровых изображений». Я не упомянул, что мне нужно отображать около 800 изображений одновременно .

О проблемах производительности можно прочитать в моих вопросах SO Производительность WPF Bitmap и Как сделать отображение изображений в WPF более «быстрым»?

Я изменил описание шаблона 1, чтобы подчеркнуть концепцию, согласно которой элементы управления изображением не создаются и не удаляются (если мы не хотим отображать большую или меньшую сетку). Только для их Источников установлены разные, новые или нулевые BitmapSources.

Изменить : Этот вопрос опубликован на форуме поддержки WPF , с некоторыми ответами персонала MS.