Как уже обсуждалось в предыдущих разделах, в .NET Compact Framework имеются два неплохих способа переноса внеэкранных рисунков в пользовательский интерфейс. Во-первых, это использование элемента управления PictureBox и задание посредством его свойства Image того битового образа, рисование которого вы только что завершили (например, pictureBox1.Image = myNewBitmap).

Второй способ заключается в получении объекта Graphics для того элемента интерфейса, в котором он будет прорисовываться (обычно таковым является объект Form) и вызове метода Graphics.DrawImage для переноса изображения:

Следует подчеркнуть, что для метода Graphics.DrawImage предусмотрено несколько перегруженных версий. Та, которая фигурировала выше, является самой простой и работает быстрее остальных; она просто копирует биты из одного битового образа в другой. Другие перегруженные версии обладают более развитыми возможностями, что позволяет им выполнять такие, например, операции, как перенос в целевое изображение строго определенной области исходного изображения, растягивание или сжатие копируемых изображений или использование масок прозрачности, позволяющих делать прозрачными отдельные области изображения, через которые могут "просматриваться'' другие изображения. Каждая из этих разновидностей метода выполняет определенное преобразование при копировании изображения из объекта-источника в объект назначения. В общем случае, чем сложнее преобразование изображения, которое требует выполнить ваш код, тем дороже оно обходится с точки зрения производительности.

Для поддержания производительности приложения на приемлемом уровне лучше всего стремиться к тому, чтобы исходное и целевое растровые изображения в максимальной степени совпадали друг с другом. По возможности стремитесь к тому, чтобы при переносе изображений создавались их точные битовые копии, а пиксели не растягивались и не сжимались. Маски прозрачности следует использовать лишь тогда, когда в этом есть необходимость. Хотя к .NET Compact Framework это и не относится, но другие среды выполнения могут предлагать вам выбрать количество цветов, которые должны использоваться в изображении, и указать битовую глубину цвета, используемую для поддержания этой информации. Совпадение этой информации для исходного и целевого изображений способно существенно улучшить производительность. Общая задача заключается в сведении к минимуму любых расхождений между исходным и конечным изображениями, чтобы операция переноса изображения была максимально приближена к операции простого копирования битов в память. Оптимизация таких операций для достижения высокой производительности обычно обеспечивается на всех платформах.

Нетривиальным рисункам свойственна сложная структура. Сначала создают прототип, позволяющий строить диаграммы. В этот прототип добавляются средства, позволяющие не только строить диаграммы, но и снабжать надписями оси. Далее добавляются метки делений, позволяющие задавать, где располагаются точки данных и соединяющие их линии. Затем добавляется поддержка одновременного отображения нескольких наборов данных. После этого добавляется таблица цветовых ключей, идентифицирующих различные наборы данных. Далее добавляется поддержка нескольких цветов. Затем добавляется возможность рисования изображений поверх фонового изображения. Наконец, добавляется возможность присвоения диаграммам названий. Код, предназначенный для построения диаграмм, совершенно неожиданно для вас разрастается до огромных размеров, причем каждая отдельная его часть предусматривает выполнение узкоспециализированной задачи, рассматриваемой в отрыве от контекста обеспечения высокой производительности приложения в целом. Тем же недостатком "нашествия возможностей" страдает и код игр, когда в список того, что должно быть сделано для визуализации игрового поля, постоянно добавляются все новые и новые члены.

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

Рассмотрим следующий пример.

Не рационализированный процесс построения графиков

1. Создать пустую битовую карту (150x150 пикселей).

2. Скопировать фоновое изображение на пустую битовую карту. (Фоновое изображение имеет размеры 150x150 пикселей, непосредственное копирование.)

3. Вычертить координатные оси. (Создаются и уничтожаются перья Red Pen, Blue Pen и Yellow Pen.)

4. Рассчитать количество делений на каждой из осей.

5. Вычертить все линии делений.

6. Вывести текст для каждого деления. (Создается и уничтожается кисть White Brush, создается и уничтожается шрифт 8 пунктов.)

7. Нарисовать данные для каждого из наборов данных, для которых строятся графики. (Создаются и уничтожаются перья Red Pen, Orange Pen, Yellow Pen и Green Pen.)

8. Нарисовать линии между точками.

9. Вычертить квадраты вокруг каждой точки.

10. Нарисовать название графика. (Создается и уничтожается кисть White Brush.)

11. Нарисовать таблицу цветовых ключей, идентифицирующих наборы данных.

12. Нарисовать рамку. (Создается и уничтожается перо White Pen.)

13. Нарисовать шаблонные линии для каждого набора данных. (Создаются и уничтожаются перья Red Pen, Orange Pen, Yellow Pen и Green Pen.)

14. Нарисовать текстовые подписи для каждого набора данных. (Создаются и уничтожаются кисти Red Brush, Orange Brush, Yellow Brush и Green Brush, создается и уничтожается шрифт 8 пунктов.)

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