Интерфейс графических устройств gdi

Интерфейс графических устройств (Graphics  Device  Interface - GDI)  предназначен  для  взаимодействия  приложений  Windows  с  графическими  устройствами,  такими  как  видеомонитор,  принтер  или  плоттер.  Приложения  Windows  работают  с  логическими  устройствами  вывода,  которые  не  зависят  от  аппаратуры  и  обладают  практически  неограниченными  возможностями.  Реализованный  в  виде  библиотеки  DLL  интерфейс  GDI  является  промежуточным  звеном  между  приложением  и  драйвером  конкретного  физического  устройства.  Для  вывода  текста  или  графического  изображения  на  экран  видеомонитора  или  принтер  приложение  вызывает  одну  из  функций  GDI.  Выполняя  запрос  приложения,  GDI  обращается  к  драйверу  соответствующего  устройства  вывода.  В  процессе  выполнения  запроса  GDI  и  драйвер учитывают  ограниченные  возможности  физического  устройства  вывода  и  его  аппаратные  особенности.  Например,  приложение  может  заказать  для  рисования  линии  любой цвет из примерно 16 млн.цветов.  В  процессе  отображения  линии  GDI  выберет  максимально  подходящий  цвет  из  числа  цветов,  поддерживаемых  физическим  устройством вывода.  Подобная  организация  вывода  на  устройство  освобождает  приложение  от  необходимости  определения  типа  и  характеристик  физического  устройства,  что  было необходимо  при  разработке  программ для MS DOS.  Правильным  образом  написанное  приложение  Windows  будет  при  наличии  соответствующего  драйвера  корректно  работать  с  любым  оборудованием,  как  существующим  на  момент  разработки  приложения,  так  и  с  тем,  которое  появится   в   будущем. 

            При  написании  картины  художник  использует  лист  бумаги  или  холст,  на  который  при  помощи  кистей,  красок  и  других  инструментов  наносит  изображение.  Аналогичным  образом  действуют  и  приложения  Windows.  Приложение  использует  устройство  отображения    в  качестве  “холста”,  на  который  при  помощи  инструментов  для  рисования  наносится  изображение. Устройство  отображения   описывается   структурой  данных  типа  HDC,  которая  называется   контекстом  отображения.  В  этой   структуре  хранятся   различные  характеристики  устройства  отображения  (контекст  устройства) и  набор  инструментов  для  рисования,  выбранных  в  контекст  по  умолчанию.  Инструменты  для  рисования  -  это  перья,  кисти,  цветовые  палитры,  шрифты,  битовые  изображения  и  т. п.   Перед  формированием  изображения  приложение  выбирает  в  контекст  отображения  нужный  ему  инструмент  при  помощи  соответствующих  функций  GDI.  Функции  рисования  не  имеют  параметров, указывающих,  например,  цвет  или  ширину  линии  -  вся   необходимая   информация   извлекается   из  контекста  отображения.

Контекст  отображения  имеет  порядка  двадцати  атрибутов (полей  соответствующей  структуры  данных).  Ниже  кратко  описаны  основные  атрибуты   контекста  отображения.  При  получении  приложением  контекста все  его  атрибуты  имеют  значения ,  выбранные  в  контекст  отображения  по  умолчанию.  Приложение  имеет  возможность  изменить  значение  атрибутов,  выбрав  в  контекст  отображения  новое  значение  атрибута  при  помощи  соответствующих  функций  API. Как  правило,  приложения  выполняют  всю  работу  по  формированию изображения  во  время  обработки  сообщения  WM_PAINT,  хотя  иногда  требуется рисовать  и  во  время  обработки  других  сообщений.  В  любом  случае  приложение  должно  придерживаться   следующей  последовательности  действий :

            1) получить (или  создать)  контекст  отображения;

            2) установить  необходимые  атрибуты  в  контексте  отображения;

            3) выполнить  операции  рисования;

            4) освободить (или  удалить) контекст  отображения.

            Контекст  отображения  является  критическим  ресурсом,  поэтому  его  необходимо  освобождать (удалять)  сразу,как  только  в  нем  отпадет  необходимость.  Если  приложение  не  освободит  контекст  отображения ,  это  может  привести  к  краху операционной  системы.   Можно  выделить  несколько  типов  контекста  отображения.

1. Общий  контекст  отображения (common  display context).  Это  наиболее  часто  используемый  контекст отображения.  Приложения  обычно  используют  этот  контекст  для  формирования  изображения  во  внутренней  области  окна (client  region). Для  получения  общего  контекста  отображения  используются  функции  BeginPaint  или  GetDC,  а  для  освобождения  соответственно функции  EndPaint  или ReleaseDC. Функции BeginPaint и EndPaint используются при обработке сообщения WM_PAINT, а функции GetDC и ReleaseDC – во всех остальных случаях.

            2.  Контекст  отображения  для  класса  окна (class  display  context).  Этот  контекст  создается  Windows  при  регистрации  класса  окна со  стилем  класса  CS_CLASSDC ,  хранится  отдельно  от  других  контекстов  в  единственном  экземпляре  и  используется  для  всех  окон ,  созданных  на  базе  данного  класса.  Однажды  получив  такой  контекст,  приложение  может  не  освобождать  его  (хотя  освобождение такого контекста  не приводит  к  ошибке -  функции  освобождения  контекста  просто возвращают  управление).  Однако ,  приложение  должно  получать данный  контекст каждый  раз при  очередном  вызове  обработчика  сообщения ,  выполняющего  рисование.  Это  связано  с  необходимостью  перенастройки  атрибутов  области  ограничения  и  начала системы  физических  координат.    В  отличие  от  общего  контекста  отображения ,  для  рассматриваемого  контекста  можно  настроить  его  атрибуты  только один раз ,  при  первом  получении  контекста.  Затем  ,  всякий  раз  при  получении  контекста , в  нем  будут  настраиваться  только  два  названных  выше  атрибута.  Для работы  с  этим  контекстом  используются  те  же  функции ,  что и для работы  с  общим  контекстом  отображения.

   3. Личный  контекст  отображения (private  display  context). Этот  контекст  создается  Windows  при  регистрации  класса  окна со  стилем  класса  CS_OWNDC.  Этот  контекст  аналогичен  предыдущему ,  но  экземпляр  контекста  будет  создаваться  Windows  для  каждого  окна ,  созданного  на  базе  данного  класса.   Это  позволяет  приложению  получать  контекст  и  настраивать  его  атрибуты  для  каждого окна только  один  раз  ,  а  не  перед  каждым  вызовом  обработчика  сообщения  ,  выполняющего  рисование ,  как  в  случае  с  общим  контекстом  отображения.  Приложение  может  не  освобождать  полученный  им  личный  контекст  отображения ,  хотя  его  освобождение  не приведет  к  ошибке. Для работы  с  этим  контекстом  используются  те  же  функции ,  что и для работы  с  общим  контекстом  отображения.

4.  Родительский  контекст  отображения  (parent  display  context).   Этот   контекст  используется   для  дочерних  окон  и  позволяет  дочерним  окнам  унаследовать атрибуты контекста  отображения у  родительского  окна ,  что  во  многих  случаях  упрощает  процедуру  настройки  этих  атрибутов.  Для  использования  родительского  контекста отображения  в  классе ,  на  базе  которого  создается  дочернее  окно , необходимо  указать стиль класса  CS_PARENTDC. Для работы  с  этим  контекстом  используются  те  же  функции ,  что и для работы  с  общим  контекстом  отображения.

            5.  Контекст  отображения  для  окна (window  display  context).  Особенностью  данного  контекста  является  то,  что  в  нем  выбрана  система  координат,  начало  которой  находится в  левом  верхнем  углу  окна (а не его внутренней области),  что позволяет рисовать в любом месте  окна (в  т. ч.  в  области  заголовка ,  системного  меню  и  т. п.).  Приложение  может  получить  этот  контекст  с  помощью  функции  GetWindowDC и  обязано  освободить  его  при  помощи  функции  ReleaseDC.

  6.  Контекст  физического  устройства ( device  context ).  Этот  контекст  используется  для  формирования  изображения  на  некотором  устройстве  вывода.  Наиболее  часто данный  контекст  используется  при  работе  с  принтером ,  хотя  можно  получить  данный  контекст и  для  дисплея ,  если  имеется  необходимость формировать  изображение  в  произвольной  точке  экрана.  В  отличие  от  раннее  рассмотренных  контекстов  ,  контекст  физического  устройства  не  получается ,  а  создается  приложением  при  помощи  функции  CreateDC.  Созданный  при  помощи  CreateDC контекст  требует  удаления  при  помощи  функции DeleteDC.

            7.  Информационный  контекст ( information  context ). Этот  контекст  не  используется  для  формирования  изображения ,  а  создается  обычно  в  тех  случаях ,  когда  приложению  необходимо  просто  получить  информацию  об  устройстве  вывода, например  при помощи функции GetDeviceCaps. Информационный  контекст  создается  при  помощи  функции  CreateIC  и  удаляется  при помощи  функции  DeleteDC

            8.  Контекст  для  памяти ( memory  device  context ).  При  работе  с  графическими  изображениями  часто  имеет  смысл  предварительно  подготовить  изображение  в  оперативной  памяти ,  а  затем  осуществить  его  вывод  на  некоторое  устройство  вывода.  В  таких  случаях  оперативная  память  рассматривается  как  некоторое  устройство  вывода ,  для  которого и  используется  рассматриваемый  контекст.  Контекст  для  памяти  создается  при  помощи  функции  CreateCompatibleDC  и  удаляется  при  помощи  функции  DeleteDC.

            9.  Контекст  для  метафайла (metafile  contexts).  Этот  контекст  позволяет  записывать  команды (вызовы  функций)  GDI  в  файл  ,  находящийся  в  оперативной  памяти  или  на диске.  Затем  можно  “проиграть” этот  файл  на  устройстве  вывода  с  помощью  функции  PlayEnhMetaFile.  Для  создания  контекста  метафайла  используется  функция  CreateEnhMetaFile ,  а  для  удаления  этого  контекста -  функция  CloseEnhMetaFile.  Для  удаления  самого  метафайла  из памяти  используется  функция  DeleteEnhMetaFile , а  для  записи  метафайла  на  диск  -  функция  CopyEnhMetaFile

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

            Режим  отображения  -  это  атрибут ,  влияющий  на  используемую  функциями  GDI  систему  координат.  При  отображении  GDI  преобразует  логические  координаты ,  используемые  функциями  GDI ,  в  физические  координаты ,  непосредственно  связанные  с  физическим  устройством  вывода.  Способ  преобразования  зависит  от  режима отображения ,  а  также  от  других  атрибутов  контекста  отображения ,  таких  ,  как  расположение  начала  системы  координат  для  окна ,  расположение начала системы  физических  координат ,  масштаб   осей   для   окна   и    масштаб    осей    физических    координат.   Начало  физической  системы  координат  для  экрана  видеомонитора располагается  в  верхнем  левом  углу  экрана,  ось Х  направлена  слева  направо ,  ось Y - сверху  вниз.  В  физической системе координат единицей измерения всегда является пиксел. Для  определения  параметров  физического  устройства   вывода   используется   функция  GetDeviceCaps.     Для  установки  режима отображения,  непосредственно определяющего направление  осей  и  размер  логической  единицы  системы  координат ,  используется  функция  SetMapMode. Параметр этой функции  определяет  один  из  восьми  возможных  режимов  отображения :  MM_TEXT  ,  MM_LOMETRIC  ,  MM_HIMETRIC  ,  MM_LOENGLISH , MM_HIENGLISH  ,  MM_TWIPS  ,  MM_ISOTROPIC  ,  MM_ANISOTROPIC .  Характеристики  каждого  режима  приводятся  в  описании функции.  С  помощью  функции  GetMapMode  приложение  может  определить  текущий  режим  отображения.  Для  изменения  ориентации  и  масштаба  осей  в  режимах  MM_ISOTROPIC  и  MM_ANISOTROPIC  используются  функции  SetViewportExt , SetViewportExtEx , SetWindowExt  и SetWindowExtEx.

Кроме установки режима отображения, приложение обычно выбирает в контекст отображения инструменты для рисования. К ним относятся следующие объекты GDI: перья (pens), кисти (brushes), шрифты (fonts), битовые образы (bitmaps) и прямоугольные области (regions). Приложение может пользоваться встроенными в Windows инструментами для рисования, или создавать собственные при помощи соответствующих функций API. Для использования встроенного объекта GDIследует  получить идентификатор объекта при помощи функции GetStockObject. Выбор инструмента для рисования в контекст отображения выполняется с помощью функции SelectObject. После окончания работы с инструментом для рисования, его следует удалить при помощи функции DeleteObject. При этом необходимо предварительно выбрать в контекст отображения один из встроенных инструментов.

Для  рисования  линий  приложение может  выбрать в контекст отображения одно из  трех  встроенных  перьев  или  создать  собственное  перо. Имеется три встроенных пера:           BLACK_PEN  -  черное  перо , рисующее  сплошную линию шириной в один пиксел ;

            WHITE_PEN   - белое  перо , рисующее  сплошную линию шириной в один пиксел ;

            NULL_PEN  - невидимое  перо , рисующее  сплошную линию шириной в один пиксел.

Для  создания  собственного  пера  приложение  может  воспользоваться  функциями CreatePen или CreatePenIndirect.  Эти  функции  позволяют  создать  перо ,  рисующее  сплошные ,  штриховые , штрихпунктирные и  другие  типы  линий  заданной  толщины  и  цвета.  Функции возвращают  идентификатор  пера  типа  HPEN ,  который  потом  необходимо  использовать  в  качестве  параметра  функции SelectObject.

Для  установки  режима  фона  предназначена  функция  SetBkMode ,  а  для  определения  текущего  режима  фона -  функция  GetBkMode.  С  помощью  функций  SetBkColor  и GetBkColor  можно  соответственно установить  и  определить текущий  цвет  фона ,  который  используется  для  закрашивания  промежутков  между  штрихами  и  точками  линий. Для  выбора  режима  для  рисования  используется  функция  SetROP2  ,  а для  определения  текущего  режима  -  функция  GetROP2. Для  установки  текущей  позиции  пера  используется  функция MoveToEx,  а  для  определения  текущей  позиции  пера  -  функция  GetCurrentPositionEx.

В Windows используются два типа битовых образов bitmap: аппаратно-независимый формат DIB и аппаратно-зависимый формат DDB. Формат DIB используется обычно для хранения битовых образов в файлах и передачи их между процессами через Clipboard. Именно в формате DIB сохраняют битовые образы графические редакторы, например редактор Paint, входящий в комплект поставки Windows95 и Windows NT 4.0. Приложение имеет возможность непосредственно считать содержимое файла в формате DIB в оперативную память. При этом в выделенный блок памяти следует поместить все содержимое файла, за исключением заголовка, определенного структурой BITMAPFILEHEADER. Содержимое полученного таким образом блока памяти называют упакованным форматом хранения DIB. Затем приложение может отобразить битовый образ в заданном контексте отображения. Для отображения битового образа в формате DIB служат функции StretchDIBits и SetDIBitsToDevice. Этим функциям требуется указатель на структуру BITMAPINFO, с которой начинается блок памяти, хранящий упакованный формат DIB. Упакованный формат DIB может быть использован также для создания кисти при помощи функции CreateDIBPatternBrush. Приложение может сформировать в памяти битовый образ в формате DIB при помощи функции CreateDIBSection.

Однако, битовый образ в формате DIB не является объектом GDI. Если приложению необходимо динамически изменять битовый образ с использованием средств GDI, оно должно преобразовать полученный из файла упакованный формат DIB в битовый образ формата DDB, который является объектом GDI. Для этого служит функция CreateDIBitmap. Кроме того, для создания битового образа в формате DDB можно воспользоваться функциями CreateBitmap, CreateBitmapIndirect, CreateCompatibleBitmap или  загрузить  его  из  ресурсов  приложения  при помощи функции LoadBitmap. Вновь созданный или загруженный битовый образ может быть заполнен символьным массивом, содержащим биты битового образа при помощи функции SetBitmapBits. Обратную операцию выполняет функция GetBitmapBits. Затем следует создать контекст отображения для памяти с помощью функции CreateCompatibleDC и выбрать битовый образ в формате DDB в этот контекст при помощи функции SelectObject. Особо следует отметить, что битовый образ может быть выбран только в контекст отображения для памяти. После выполнения этой операции поверхность отображения в выбранном контексте будет иметь те же ширину, высоту и организацию цвета, что и соответствующий битовый образ. Теперь приложение имеет возможность модифицировать битовый образ при помощи функций GDI. К сожалению, в GDI отсутствует функция, позволяющая непосредственно отобразить битовый образ в другом контексте отображения. Вместо этого используется функция BitBlt, осуществляющая перенос битов из одного контекста отображения в другой. Именно при помощи этой функции можно отобразить битовый образ в контексте отображения, связанном с устройством вывода.

            Последним из рассматриваемых нами объектов GDI является регион – описание области вывода, состоящей из комбинации многоугольников и эллипсов. Регионы используются обычно для закрашивания некоторых областей произвольной формы, а также для ограничения вывода (отсечения). Регион создается одной из следующих функций: CreateRectRegion, CreateRectRegionIndirect, CreateEllipticRegion, CreateEllipticRegionIndirect, CreateRoundRectRe-gion, CombineRegion. Созданный регион может быть выбран в контекст физического устройства при помощи функций SelectObject или SelectClipRgn. Затем следует вызвать функцию InvalidateRgn с тем, чтобы окно получило сообщение WM_PAINTи перерисовало свое содержимое. При этом изображение, находящееся вне выбранного в контекст физического устройства региона не будет перерисовываться.

Многие  функции  GDI требуют  в  качестве  одного из  своих  параметров  ссылку  на  используемый  цвет.  Цвет  указывается  при  помощи  переменной,  имеющей  тип  COLORREF. Значение переменной этого типа представляет собой целое 32-разрядное число, три младших байта которого задают интенсивность красного, зеленого и синего цвета, а старший байт всегда равен нулю.        В  простейшем  случае  цвет  можно определить с  помощью  макрокоманды  RGB , комбинирующей  цвет  из  отдельных  компонент.  Эта  макрокоманда  определена следующим  образом :

#define RGB(r,g,b)     ((COLORREF)(((BYTE)(r)|((WORD)(g)<<8))|(((DWORD)(BYTE)(b))<<16)))

Кроме того, определены также макрокоманды ,  извлекающие из переменной  типа COLORREF отдельные  цветовые компоненты :

            #define GetRValue(rgb)      ((BYTE)(rgb))

            #define GetGValue(rgb)      ((BYTE)(((WORD)(rgb)) >> 8))

            #define GetBValue(rgb)      ((BYTE)((rgb)>>16))

                В  зависимости  от  используемого  видеорежима Windows  предоставит  приложению  приближенный  цвет,  который максимально  соответствует  запрошенному  через  макрокоманду  RGB  логическому  цвету.  Функция  GetNearestColor  возвращает  для  запрошенного  логического цвета  физический  цвет ,  составленный  только  из  компонент  чистого цвета. Приложение  имеет  также  возможность воспользоваться  для  формирования  изображения  набором  системных  цветов ,  определяемых  через  приложение “Control  Panel” (“Панель  управления”).  Для  этого используется  функция  GetSysColor.

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

Open Graphics Library

OpenGL (Open Graphics Library — открытая графическая библиотека, графическое API) — спецификация, определяющая независимый от языка программирования платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику.

Включает более 250 функций для рисования сложных трёхмерных сцен из простых примитивов. Используется при создании компьютерных игр, САПР, виртуальной реальности, визуализации в научных исследованиях. На платформе Windows конкурирует с Direct3D.

На базовом уровне, OpenGL — это просто спецификация, то есть документ, описывающий набор функций и их точное поведение. Производители оборудования на основе этой спецификации создают реализации — библиотеки функций, соответствующих набору функций спецификации. Реализация использует возможности оборудования там, где это возможно. Если аппаратура не позволяет реализовать какую-либо возможность, она должна быть эмулирована программно. Производители должны пройти специфические тесты (conformance tests — тесты на соответствие) прежде чем реализация будет классифицирована как OpenGL реализация. Таким образом, разработчикам программного обеспечения достаточно научиться использовать функции, описанные в спецификации, оставив эффективную реализацию последних разработчикам аппаратного обеспечения.

Эффективные реализации OpenGL существуют для Windows, Unix-платформ, PlayStation 3 и Mac OS. Эти реализации обычно предоставляются изготовителями видеоадаптеров и активно используют возможности последних. Существуют также чисто программные реализации спецификации OpenGL, одной из которых является библиотека Mesa. Из лицензионных соображений Mesa является «неофициальной» реализацией OpenGL, хотя полностью с ней совместима на уровне кода.

Спецификация OpenGL пересматривается Консорциумом ARB (Architecture Review Board), который был сформирован в 1992 году. Консорциум состоит из компаний, заинтересованных в создании широко распространённого и доступного API. Согласно официальному сайту OpenGL, членами ARB с решающим голосом на ноябрь 2004 года являются производители профессиональных графических аппаратных средств SGI, 3Dlabs, Matrox и Evans & Sutherland (военные приложения), производители потребительских графических аппаратных средств ATI и NVIDIA, производитель процессоров Intel, и изготовители компьютеров и компьютерного оборудования IBM, Apple, Dell, Hewlett-Packard и Sun Microsystems, а также один из лидеров компьютерной игровой индустрии id Software. Microsoft, один из основоположников Консорциума, покинула его в марте 2003 года. Помимо постоянных членов, каждый год приглашается большое количество других компаний, становящихся частью OpenGL ARB в течение одного года. Такое большое число компаний, вовлеченных в разнообразный круг интересов, позволило OpenGL стать прикладным интерфейсом широкого назначения с большим количеством возможностей.

Курт Экли (Kurt Akeley) и Марк Сигал (Mark Segal) являются авторами оригинальной спецификации OpenGL. Крис Фрэзиер (Chris Frazier) редактировал версию 1.1. Йон Лич (Jon Leech) редактировал версии с 1.2 по версию 2.0.

OpenGL ориентируется на следующие две задачи:

Скрыть сложности адаптации различных 3D-ускорителей, предоставляя разработчику единый API.

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

Основным принципом работы OpenGL является получение наборов векторных графических примитивов в виде точек, линий и многоугольников с последующей математической обработкой полученных данных и построением растровой картинки на экране и/или в памяти. Векторные трансформации и растеризация выполняются графическим конвейером (graphics pipeline), который по сути представляет собой дискретный автомат. Абсолютное большинство команд OpenGL попадают в одну из двух групп: либо они добавляют графические примитивы на вход в конвейер, либо конфигурируют конвейер на различное исполнение трансформаций.

OpenGL является низкоуровневым процедурным API, что вынуждает программиста диктовать точную последовательность шагов, чтобы построить результирующую растровую графику (императивный подход). Это является основным отличием от дескрипторных подходов, когда вся сцена передается в виде структуры данных (чаще всего дерева), которое обрабатывается и строится на экране. С одной стороны, императивный подход требует от программиста глубокого знания законов трёхмерной графики и математических моделей, с другой стороны — даёт свободу внедрения различных инноваций.

Для подтверждения независимости от языка программирования были разработаны различные варианты привязки (binding) функций OpenGL или полностью перенесены на другие языки. Одним из примеров может служить библиотека Java 3D, которая может использовать аппаратное ускорение OpenGL. Прямая привязка функций реализована в Lightweight Java Game Library, которая имеет прямую привязку OpenGL для Java. Sun также выпустила версию Java OpenGL (JOGL), которая предоставляет прямую привязку к Си-функциям OpenGL, в отличие от Java 3D, которая не имеет столь низкоуровневой поддержки. Официальный сайт OpenGL имеет ссылки на привязки для языков Java, Фортран 90, Perl, Pike, Python, Ada, Visual Basic и Pascal. Имеются также варианты привязки OpenGL для языков C++ и C#.