Другая причина, по которой не рекомендуется делать процесс рисования видимым для пользователя, заключается в том, что область растровых изображений пользовательского интерфейса обычно не является постоянной. В отличие от внеэкранных битовых карт, принадлежащих вашему коду, экран является разделяемым ресурсом, который совместно используется окнами и элементами управления всех выполняющихся приложений, а также операционной системой. Большинством операционных систем поддержка изображений, которые пользователь может рисовать на поверхности пользовательского интерфейса, не предусматривается. Это означает, что любые изображения, созданные вами в области пользовательского интерфейса, будут утеряны, если окно, в котором ваш код выполнял рисование, будет перекрыто окном другого приложения.
Гораздо менее уязвимым с точки зрения эстетики процесса рисования и подверженности ошибкам является рисование на внеэкранном буфере с последующим копированием результатов на передний план после того, как создание рисунка будет завершено. Кроме того, решения этого типа отличаются лучшей переносимостью, их проще проектировать, сопровождать и отлаживать. Вместо того чтобы погружаться во все тонкости модели рисования, используемой операционной системой, вы можете организовать все так, что изображение будет в максимально возможной степени при надлежать вашему приложению, выполняющему операции рисования в собственном строго определенном окружении и взаимодействующему непосредственно с пользовательским интерфейсом лишь тогда, когда эта работа будет закончена. Подход, основанный на использовании внеэкранных буферов для объектов рисования, почти всегда является наиболее оптимальным для выполнения графических операций любой степени сложности, даже если при этом вам и придется использовать вывод курсора ожидания на период визуализации изображения.
Как уже обсуждалось в предыдущих разделах, в .NET Compact Framework имеются два неплохих способа переноса внеэкранных рисунков в пользовательский интерфейс. Во-первых, это использование элемента управления PictureBox и задание посредством его свойства Image того битового образа, рисование которого вы только что завершили (например, pictureBox1.Image = myNewBitmap).
Второй способ заключается в получении объекта Graphics для того элемента интерфейса, в котором он будет прорисовываться (обычно таковым является объект Form) и вызове метода Graphics.DrawImage() для переноса изображения:
//Получить объект Graphics для формы
System.Drawing.Graphics gfx;
gfx = this.CreateGraphics();
//Нарисовать изображение в объекте с использованием
//начальной точки с координатами x=10, y=15);
gfx.DrawImage(myBitmap, 10, 15);
Следует подчеркнуть, что для метода Graphics.DrawImage() предусмотрено несколько перегруженных версий. Та, которая фигурировала выше, является самой простой и работает быстрее остальных; она просто копирует биты из одного битового образа в другой. Другие перегруженные версии обладают более развитыми возможностями, что позволяет им выполнять такие, например, операции, как перенос в целевое изображение строго определенной области исходного изображения, растягивание или сжатие копируемых изображений или использование масок прозрачности, позволяющих делать прозрачными отдельные области изображения, через которые могут "просматриваться'' другие изображения. Каждая из этих разновидностей метода выполняет определенное преобразование при копировании изображения из объекта-источника в объект назначения. В общем случае, чем сложнее преобразование изображения, которое требует выполнить ваш код, тем дороже оно обходится с точки зрения производительности.
Для поддержания производительности приложения на приемлемом уровне лучше всего стремиться к тому, чтобы исходное и целевое растровые изображения в максимальной степени совпадали друг с другом. По возможности стремитесь к тому, чтобы при переносе изображений создавались их точные битовые копии, а пиксели не растягивались и не сжимались. Маски прозрачности следует использовать лишь тогда, когда в этом есть необходимость. Хотя к .NET Compact Framework это и не относится, но другие среды выполнения могут предлагать вам выбрать количество цветов, которые должны использоваться в изображении, и указать битовую глубину цвета, используемую для поддержания этой информации. Совпадение этой информации для исходного и целевого изображений способно существенно улучшить производительность. Общая задача заключается в сведении к минимуму любых расхождений между исходным и конечным изображениями, чтобы операция переноса изображения была максимально приближена к операции простого копирования битов в память. Оптимизация таких операций для достижения высокой производительности обычно обеспечивается на всех платформах.
Определите собственный процесс визуализации
Нетривиальным рисункам свойственна сложная структура. Сначала создают прототип, позволяющий строить диаграммы. В этот прототип добавляются средства, позволяющие не только строить диаграммы, но и снабжать надписями оси. Далее добавляются метки делений, позволяющие задавать, где располагаются точки данных и соединяющие их линии. Затем добавляется поддержка одновременного отображения нескольких наборов данных. После этого добавляется таблица цветовых ключей, идентифицирующих различные наборы данных. Далее добавляется поддержка нескольких цветов. Затем добавляется возможность рисования изображений поверх фонового изображения. Наконец, добавляется возможность присвоения диаграммам названий. Код, предназначенный для построения диаграмм, совершенно неожиданно для вас разрастается до огромных размеров, причем каждая отдельная его часть предусматривает выполнение узкоспециализированной задачи, рассматриваемой в отрыве от контекста обеспечения высокой производительности приложения в целом. Тем же недостатком "нашествия возможностей" страдает и код игр, когда в список того, что должно быть сделано для визуализации игрового поля, постоянно добавляются все новые и новые члены.
В силу указанных причин очень важно не пожалеть времени и постараться рационализировать используемый вами процесс визуализации. Тем самым вы выжмете из своей системы максимально возможную производительность и приобретете дополнительную гибкость в добавлении новых средств. Эта задача должна быть разбита на этапы, позволяющие анализировать любые изменения, вносимые вами в модель визуализации, и рационализировать их на уровне системы, настроенной на обеспечение максимальной общей производительности. Эта работа не является трудной; для этого требуется только записать, какой ряд последовательных действий необходимо выполнить и какие ресурсы используются на каждом шаге.
Рассмотрим следующий пример.
Не рационализированный процесс построения графиков
1. Создать пустую битовую карту (150×150 пикселей).
2. Скопировать фоновое изображение на пустую битовую карту. (Фоновое изображение имеет размеры 150×150 пикселей, непосредственное копирование.)
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.)
