C# для профессионалов. Том II - Симон Робинсон

Библиотека базовых классов GDI+ очень велика, и мы едва сможем прикоснуться к их свойствам в данной главе. Это обдуманное решение, так как попытка охватить хотя бы минимальную часть доступных классов, методов и свойств превратит эту главу в справочное руководство, которое просто перечисляет классы и т. д. Более важно понять фундаментальные принципы, вовлеченные в рисование, а затем можно будет исследовать доступные классы самостоятельно. (Полные списки всех доступных в GDI+ классов и методов имеются в документации MSDN). Разработчики, имеющие дело с VB, найдут, скорее всего, концепции, вовлеченные в рисование, совершенно незнакомыми, так как фокус VB заключается в элементах управления, обрабатывающих свое собственное рисование. Разработчики с подготовкой C++/MFC окажутся в более выгодном положении, так как MFC требует в большей степени внешнего управления процессом рисования, используя предпроцессор GDI+, GDI. Однако даже при хорошем знакомстве с GDI подавляющая часть материала окажется новой. GDI+ в действительности является оболочкой GDI, но тем не менее GDI+ имеет объектную модель, которая скрывает большую часть работы GDI. В частности GDI+ заменяет почти полностью модель с состоянием GDI, в которой элементы выбирались в контексте устройства, на модель, менее учитывающую состояние, в которой каждая операция рисования происходит независимо. Объект Graphics (представляющий контекст устройства) является единственным объектом, существующим между операциями рисования.

Кстати, в этой главе термины рисование и черчение взаимозаменяемы и описывают процесс вывода некоторого элемента на экране или на другом устройстве вывода.

Прежде коротко перечислим основные пространства имен, которые встречаются в базовых классах GDI+.

Пространство имен Содержимое System.Drawing Большинство классов, структур, перечислений, а также делегатов, связанных с базовой функциональностью рисования. System.Drawing.Drawing2D Более специализированные классы, предоставляющие развитые эффекты при рисовании на экране. System.Drawing.Imaging Различные классы, которые задействованы при манипуляции изображениями (битовые файлы, файлы GIF и т.д.). System.Drawing.Printing Вспомогательные классы, специально предназначенные для случая, когда в качестве устройства "вывода" указан принтер или окно предпросмотра печати. System.Drawing.Design Некоторые предопределенные диалоговые окна, списки свойств и другие элементы интерфейса пользователя, связанные с расширением интерфейса пользователя во время проектирования. System.Drawing.Text Классы для выполнения более развитых манипуляций со шрифтами и семействами шрифтов.

Почти все классы, структуры и т.д., использующиеся в этой главе, взяты из пространства имен System.Drawing.

Основные принципы рисования

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

GDI и GDI+

Одним из достоинств Windows и современных операционных систем в целом является возможность абстрагировать детали работы определенных устройств от разработчика. Например, нет необходимости знать что-либо о драйвере устройства жесткого диска, чтобы программным путем прочитать или записать файлы на диск, достаточно просто вызвать соответствующие методы в подходящих классах .NET (или до появления .NET в эквивалентных функциях Windows API). Этот принцип также вполне справедлив, когда речь идет о рисовании. Когда компьютер рисует что-нибудь на экране, он делает это, посылая инструкции видеоплате с указанием, что рисовать и где. Проблема в том, что на рынке существует много сотен различных видеокарт, сделанных различными производителями. Если принять это в расчет и писать в приложении специальный код для каждого видеодрайвера, который рисует что-то на экране, создание приложения станет практически невозможной задачей. Именно поэтому интерфейс графического устройства (GDI) операционной системы Windows всегда присутствовал в системе с самых первых версий Windows.

GDI скрывает нюансы работы различных видеоплат, так что для выполнения определенной задачи вызывается просто функция API Windows, и внутренне GDI вычисляет, как заставить определенную видеоплату сделать то, что требуется. Однако большинство компьютеров имеют более одного устройства, на которое можно послать вывод. Сегодня это монитор, доступ к которому получают через видеоплату, и принтер. Некоторые машины могут иметь более одной видеоплаты или более одного принтера. GDI проявляет удивительное искусство, заставляя принтер выглядеть так же, как экран, с позиции приложения. Если необходимо напечатать что-то, а не вывести это на экран, то система просто информируется, что устройством вывода является принтер, а затем вызываются те же функции API. Таким образом, истинное предназначение GDI — абстрагировать свойства оборудования на относительно высоком уровне API.

GDI предоставляет для разработчиков относительно высокий уровень API, но это по-прежнему API, который основывается на старом API Windows с функциями в стиле С, и поэтому его не так просто использовать. GDI+ в большой степени позиционируется как слой между GDI и приложением, предоставляя более интуитивно-понятную объектную модель на основе наследования. Хотя GDI+ является по сути оболочкой вокруг GDI, компания Microsoft смогла с помощью GDI+ предоставить новые свойства и при этом повысить производительность.

Контексты устройств и объект Graphics

В GDI устройство, на которое должен направиться вывод, идентифицируется с помощью объекта, известного как контекст устройства (DC — Device Context). Контекст устройства хранит информацию об определенном устройстве и может транслировать вызовы функций API GDI в инструкции, которые необходимо послать на это устройство. Можно также запрашивать контекст устройства, чтобы определить возможности соответствующего устройства (например, может ли принтер печатать в цвете или осуществляет только черно-белую печать), чтобы настроить соответственно вывод. Если запросить устройство сделать что-то, на что оно не способно, контекст устройства обычно это обнаруживает и совершает соответствующее действие (которое, в зависимости от ситуации, может означать порождение ошибки или изменение запроса, чтобы получить ближайшее соответствие тому, на что действительно способно устройство).

Однако контекст устройства имеет дело не только с аппаратным устройством. Оно действует как мост к Windows и способен поэтому учесть любые требования или ограничения, налагаемые на рисование операционной системой Windows. Например, если Windows знает, что необходимо перерисовать только часть окна приложения (возможно, потому что было минимизировано другое окно, которое скрывает часть приложения), контекст устройства может перехватывать и аннулировать попытки рисовать вне этой области. Благодаря связи контекста устройства с Windows работа через контекст устройства может упростить код и другими способами. Например, аппаратным устройствам необходимо сообщать, где рисовать объекты, и обычно координаты задаются относительно верхнего левого угла экрана (или устройства вывода). Но приложение будет считать рисование чем-то происходящим в определенной позиции внутри клиентской области своего собственного окна. (Клиентская область в Windows является частью окна, которая обычно используется для рисования, что означает окно с исключенными границами, таким образом во многих приложениях клиентская область будет областью с белым фоном.) Поскольку окно может быть расположено где угодно на экране и пользователь вправе перемещать его в любое время, трансляция между двумя координатами является потенциально трудной задачей. Но контекст устройства всегда знает, где находится окно, и способен выполнить эту трансляцию автоматически. Это означает, что можно запросить контекст устройства нарисовать элемент в определенной позиции окна, не беспокоясь о том, где на экране в настоящее время расположено окно приложения.

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