Стратегии проектирования высокопроизводительного графического кода
Код, предназначенный для обработки графики, целесообразно рассматривать отдельно от кода высокоуровневого пользовательского интерфейса. Обычно в коде пользовательского интерфейса используются высокоуровневые абстракции, предлагаемые операционной системой или средой программирования. Примерами подобных абстракций могут служить такие понятия, как элементы управления Button, ListBox, ListView, Panel или Grid. На самом нижнем уровне элементы управления реализуются в виде последовательностей инструкций рисования и низкоуровневого взаимодействия с операционной системой и пользователями. Разработчикам приложений почти никогда не приходится иметь дело с элементами управления на этом самом низком уровне абстракции. Обычно, используя элементы управления пользовательского интерфейса, разработчик полагается на уже организованное для него оптимизированное выполнение базовых операций, связанных с рисованием и поддержкой элементов управления; задача разработчика заключается лишь в том, чтобы наиболее эффективным способом использовать эти элементы управления на более высоком уровне абстракции. В отличие от этого, при работе с графикой разработчик должен специально продумать, как должны решаться низкоуровневые задачи рисования и каким образом можно обеспечить их наиболее эффективное выполнение.
С позиций абстрагирования код высокоуровневого пользовательского интерфейса аналогичен организации связи в сети с использованием запросов и ответов по протоколу HTTP; в то же время, графический код аналогичен организации связи на уровне сокетов или же пакетов. Как и в случае сетевых коммуникаций, во всех возможных случаях лучше использовать высокоуровневые абстракции. Высокоуровневые абстракции легко использовать, они эффективны для большинства задач и надежно протестированы. Эффективная работа с низкоуровневыми программными средствами, например, графическими библиотеками, требует более глубокого понимания того, что при этом происходит, и соответствующего активного вмешательства в ход событий, и должна сопровождаться тщательным анализом того, какую пользу с точки зрения эффективности это может принести приложению. Графический код выглядит и работает иначе, чем код пользовательского интерфейса.
Поскольку конечной целью всей низкоуровневой работы с графикой является предоставление отдельных частей многофункционального пользовательского интерфейса, между низкоуровневым графическим кодом и кодом пользовательского интерфейса в какой-то точке должно быть налажено взаимодействие. Можно почти не сомневаться, что создаваемая вами графика будет сосуществовать с такими высокоуровневыми компонентами пользовательского интерфейса, как элементы управления Button, Menu или ListView. Управление всем пользовательским интерфейсом посредством только низкоуровневого графического кода может быть оправданным лишь в самых редких случаях по той простой причине, что приложение ничего не выиграет, если будет самостоятельно прорисовывать элементы управления и обрабатывать низкоуровневое взаимодействие с пользователем. Вместо этого следует прибегать к гораздо более эффективному подходу, в соответствии с которым разработчики используют для обслуживания пользовательского интерфейса готовые библиотеки проверенных на практике функций и привлекают графические функции для управления лишь теми элементами пользовательского интерфейса, которые испытывают в этом крайнюю необходимость. Для этого следует использовать тщательно продуманные модели, описывающие, каким образом код высокоуровневого пользовательского интерфейса и низкоуровневый графический код должны сочетаться друг с другом.
Четырехминутный практикум по работе с графикой в .NET Compact Framework
В документации к .NET Framework и .NET Compact Framework содержится обширная информация по работе с графикой, с которой вам обязательно стоит ознакомиться. Ниже приведены лишь самые основные сведения.
Рабочей лошадкой графики в NET является объект System.Drawing.Graphics. Если вы знакомы с методами разработки приложений в собственных кодах Windows, считайте, что это — объектно-ориентированная версия hDC (Device Context, контекст устройства). Чтобы нарисовать что-либо (например, фигуру, линию, текст, растровое изображение) на поверхности битовой карты, ваш код должен вызвать соответствующий метод объекта Graphics. Не менее важно знать о том, что после того как вы закончите работать с созданным перед этим объектом Graphics, необходимо освободить память от этого объекта при помощи вызова функции Dispose(), иначе он будет занимать драгоценные системные ресурсы. Для того чтобы постоянно держать под рукой какой-либо из объектов Graphics, у вас должны быть веские причины.
Если объект Graphics не создается, а передается, то обычно этот объект вам предоставляет вызывающая функция. В подобных случаях забота о том, чтобы освободить память от этого объекта с помощью метода Dispose(), обычно лежит не на вашем коде; при вызове метода Dispose() объекта, который все еще используется другим кодом, возникают проблемы. Наиболее распространенные ситуации, в которых объект Graphics передается другой функции, возникают, когда вы пишете обработчик Paint для нестандартного элемента управления или подключаетесь к обработчику Paint для формы или стандартного элемента управления. В этих случаях вы выполняете нужные операции рисования при помощи передаваемого вам объекта Graphics.
Перья (Pen), кисти (Brush), шрифты (Font), растровые изображения (Bitmap) также должны создаваться. Эти объекты не принадлежат какому-то одному объекту Graphics; одни и те же объекты могут использоваться различными объектами Graphics. Когда работа с этими объектами в вашем коде закончена, для них также необходимо вызывать метод Dispose(). Тем не менее, в случае мобильных приложений использование глобальных объектов Pen, Brush, Font или Bitmap, если они часто используются, может оказаться полезным и эффективным. Производительность приложения можно значительно повысить, применяя тщательно продуманную стратегию кэширования объектов.
Для указания атрибутов рисования визуализируемых объектов используется класс ImageAttributes. Он передается при помощи перегруженных методов Graphics.DrawImage() и позволяет вашему приложению устанавливать прозрачный цвет для битовых образов, копируемых на другую поверхность. Использование класса ImageAttributes на платформе .NET Compact Framework позволяет вашему приложению назначать один из цветов битового образа в качестве прозрачного; благодаря этому ваш код получает возможность визуализировать на битовых образах объекты, форма которых отличается от прямоугольной. Такая возможность оказывается очень полезной при написании игр. Как и в случае других классов, объекты ImageAttributes по окончании работы должны вызывать метод Dispose().
Способы интеграции графики с кодом пользовательского интерфейса
Существует несколько способов интеграции низкоуровневого графического кода с высокоуровневым кодом пользовательского интерфейса. Очень важно выбрать такой способ, который лучше всего соответствует характеру задач, стоящих перед вашим приложением. Тремя наиболее распространенными способами сопряжения кодов графики и пользовательского интерфейса являются следующие:
1. Отображение растровых изображений в элементе управления PictureBox.
2. Рисование непосредственно в форме.
3. Реализация пользовательских элементов управления.
Перечисленные способы описываются ниже с использованием иллюстративных примеров их применения.
Отображение растровых изображений в элементе управления PictureBox
Рисование графики на внеэкранных битовых картах и отображение полученных битовых образов в элементе PictureBox на форме является самым простым и наиболее мощным способом работы с пользовательской графикой. В силу своей простоты такой подход великолепно подходит для работы почти с любыми видами деловой графики и даже для многих игр.
