Основы графического вывода

В Windows существует специальный объект GDI, используемый для закраски внутренних областей фигур; по аналогии с рисованием на бумаге этот объект получил название кисть (brush). Практически кисть представляет собой небольшую (8x8 пикселей) картинку, которая многократно воспроизводится для закраски указанной области.

Кисть является объектом GDI и, соответственно, при работе с ней надо придерживаться общих правил работы с объектами GDI.

Windows содержит несколько стандартных кистей, для выбора которых можно воспользоваться функцией:

HANDLE GetStockObject (nIndex);

HBRUSH GetStockBrush (nIndex); 2

где параметр nIndex может быть:

Белая кисть (WHITE_BRUSH) обычно используется для закраски фона окна (при описании класса окна поле WNDCLASS.hbrBackground задается обычно равным хендлу белой кисти).

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

UINT SetClassWord (hWnd, GCW_HBRBACKGROUND, hbrNewBrush); // Windows 3.x

DWORD SetClassLong (hWnd, GCL_HBRBACKGROUND, hbrNewBrush); // Win32 API

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

Кисти HOLLOW_BRUSH и NULL_BRUSH представляют один и тот же объект -- прозрачную кисть. Вы можете использовать данную кисть для закраски фона замкнутых фигур, если они должны быть представлены только контуром, без заполнения внутренней области.

Если вы хотите создать собственную кисть, то можно воспользоваться одной из следующих функций:

HBRUSH CreateSolidBrush (crColor);

HBRUSH CreateHatchBrush (nStyle, crColor);

HBRUSH CreatePatternBrush (hBitmap);

HBRUSH CreateDIBPatternBrush (hGlobDIB, nColorSpec);

HBRUSH CreateBrushIndirect (lpLogBrush);

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

Так, например, в 16^ти цветном режиме стандартные кисти LTGRAY_BRUSH, GRAY_BRUSH и BLACK_BRUSH могут быть представлены оттенками серого цвета, а кисть DKGRAY_BRUSH будет представлена смесью точек серого и черного цветов.

Функция CreateHatchBrush создает штрихованную кисть. Вы указываете два параметра -- тип штриховки (nStyle) и цвет штриха (crColor), для закраски фона между штрихами в качестве фона используются атрибуты контекста устройства текущий цвет фона и режим заполнения фона.

Рисунок 9. Стили штрихованных кистей

Параметр crColor задает цвет штриховки. GDI будет применять ближайший чистый цвет для рисования линий штриховки. Для задания цвета фона надо воспользоваться функциями

COLORREF SetBkColor (hDC, crColor);

int SetBkMode (hDC, nMode);

С помощью функций CreatePatternBrush и CreateDIBPatternBrush вы можете описать кисть, определяемую образцом (pattern) -- рисунком размером 8x8 пикселей. Для этого надо предварительно получить битмап размером 8x8 пикселей (или больше) и передать его соответствующей функции. Кисть будет создана исходя по изображению размером 8x8 пикселей, находящемуся в верхнем-левом углу битмапа. Подробнее о получении битмапов -- смотри в разделе “Растровые изображения”. Все время, пока существует кисть, вы должны сохранять исходный битмап, по которому эта кисть построена. Один битмап может применяться для создания многих кистей.

Разница между двумя функциями создания кисти по образцу связана с применением разных видов битмапов -- зависимых от устройства (DDB -- device depended bitmap) и независимых от устройства (DIB -- device independed bitmap). Независимый от устройства битмап содержит как данные об изображении, так и данные о применяемых цветах (палитре). При создании кисти на основе DIB требуется два параметра, один из которых указывает образец (независимый от устройства битмап), а другой указывает правила интерпретации логических цветов данного битмапа.

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

Функция CreateBrushIndirect является объединением всех рассмотренных функций: в качестве параметра ей передается указатель на структуру типа LOGBRUSH, которая описывает кисть любого типа.

typedef struct tagLOGBRUSH {

UINT lbStyle;

COLORREF lbColor;

int lbHatch;

} LOGBRUSH;

Поле lbStyle определяет стиль кисти. Оно может принимать одно из следующих значений: BS_SOLID, BS_HATCHED, BS_HOLLOW, BS_NULL, BS_PATTERN и BS_DIBPATTERN (что в какой-то мере соответствует функции, применяемой для создания кисти). Использование других полей структуры LOGBRUSH зависит от стиля кисти:

Структура LOGBRUSH может использоваться также для выяснения свойств кисти с помощью функции GetObject.

Привязка кисти (brush alignment)

Существует совершенно особый прием при работе с кистями -- так называемая привязка кисти. При закраске внутренней области какой-либо фигуры с помощью кисти GDI многократно воспроизводит ее изображение. Однако при этом возникает вопрос: с какого места начинает воспроизводиться изображение кисти? Считается, что GDI по умолчанию повторяет кисть начиная с верхнего левого угла экрана -- то есть от точки с координатами устройства (0,0). Это так называемая начальная точка кисти (brush origin).

Рисунок 10. Пояснения к атрибуту начальная точка кисти (brush origin)

Если кисть представлена каким-либо изображением или штриховкой, то все закрашиваемые фрагменты попадают в одну "фазу". В некоторых случаях надо изменять начало отсчета кисти для того, что бы рисунок или штриховка был согласован с закрашиваемой поверхностью. Для этого применяется прием, называемый выравнивание кисти (brush alignment):

POINT pt;

// brush origin устанавливается в координатах устройства,

// а точка по которой мы будем выравнивать обычно определена

// в логических координатах, поэтому требуется преобразование.

pt.x= 0; pt.y= 0; // выбираем логические координаты новой точки

LPtoDP (hDC, &pt, 1); // переводим их в координаты окна

ClientToScreen (hWnd, &pt); // а теперь в координаты экрана

//-если мы применяем систему координат MM_TEXT(по умолчанию),то

// мы можем не использовать функцию LPtoDP;

// - если контекст соответствует иному устройству, чем дисплей,

// то мы не используем функцию ClientToScreen.

// кисть имеет размер 8x8 пикселей, поэтому координаты начальной точки

// лучше задавать в диапазоне 0..7, то есть остаток от деления на 8

pt.x %= 8; pt.y %= 8;

// теперь нам известны координаты устройства нового brush origin

UnrealizeObject (hNewBrush);

SetBrushOrg (hDC, pt.x, pt.y);

// функция UnrealizeObject разрешает назначить для кисти новую начальную

// точку; это назначение произойдет при выборе кисти в контекст устройства,

// причем начальная точка назначается именно контексту, а не кисти.

SelectObject (hDC, hNewBrush);

При выравнивании кисти надо придерживаться нескольких ограничений:

запрещено применять функцию UnrealizeObject ко всем стандартным кистям;

выравнивать можно только кисть, не выбранную в контекст устройства;

Режим заполнения многоугольников

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

Рисунок 11. Примеры многоугольников с перекрывающимися поверхностями.

В такой ситуации поведение GDI будет определяться текущим режимом заполнения многоугольников (polygon filling mode). Вы можете его изменить или узнать с помощью функций

UINT GetPolyFillMode (hDC);

UINT SetPolyFillMode (hDC, nIndex);

допустимы два значения параметра nIndex: ALTERNATE и WINDING. В режиме ALTERNATE GDI закрашивает на каждой строке развертки отрезок между сторонами с нечетным и четным последовательными номерами. Очень упрощенно -- область, которая повторно закрашивается сохранит первоначальный вид. В режиме WINDING применяется более сложный алгоритм, который позволяет вычислить и закрасить все внутреннюю область многоугольника. Например, заполнение многоугольника в виде пятиконечной звездочки в различных режимах заполнения многоугольников выглядит так:

Рисунок 12. Заполнение пятиконечной звездочки в различных режимах заполнения многоугольников.

Прямоугольники и регионы

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

По мере развития Windows многие функции прямоугольников были переданы более сложным объектам -- регионам (region), которые могут описывать области сложной формы. При этом развился параллельный набор функций, ориентированных на применение регионов вместо прямоугольников.

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

Прямоугольники

Рассмотрение операции над прямоугольниками мы начнем с математических функций. Эти функции рассматривают прямоугольник как некую математическую абстракцию, описываемую структурой типа RECT.

typedef struct tagRECT {

int left;

int top;

int right;

int bottom;

} RECT;

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

void SetRect (lpRect, xLeft, yTop, xRight, yBottom);

позволяет заполнить структуру типа RECT указанными значениями, функция

void SetRectEmpty (lpRect);

обнуляет поля структуры RECT, а функция

void CopyRect (lpRectDst, lpRectSrc);

копирует одну структуру RECT в другую. Рассмотренные функции заменяются на более простые конструкции самым тривиальным образом, причем получаемый код оказывается компактнее и существенно быстрее. Еще две функции осуществляют перемещение прямоугольника по координатной плоскости (OffsetRect) и изменение его размеров (InflateRect):

void OffsetRect (lpRect, nDeltaX, nDeltaY);

void InflateRect (lpRect, nDeltaWidth, nDeltaHeight);

void InsetRect (lpRect, nDeltaWidth, nDelatHeight); 2

Макрос InsetRect соответствует вызову функции:

InflateRect (lpRect, - (nDeltaWidth), - (nDeltaHeight)).

Некоторые функции для работы с прямоугольниками, предоставляемые Windows, все же достаточно удобны, что бы их не заменять собственными:

BOOL IsRectEmpty (lpRect);

проверяет, является ли данный прямоугольник пустым, или нет; Функция

BOOL EqualRect (lpRect, lpRect);

проверяет совпадение прямоугольников (имеют ли они одинаковые размеры и положение); а функция

BOOL PtInRect (lpRect, lpPoint);

проверяет, попадает ли указанная точка в заданный прямоугольник. Еще три функции позволяют выполнить простейшие математические операции над прямоугольниками: вычислить пересечение, объединение и исключение.

BOOL IntersectRect (lpRectDst, lpRectSrc1, lpRectSrc2);

BOOL UnionRect (lpRectDst, lpRectSrc1, lpRectSrc2);

BOOL SubtractRect (lpRectDst, lpRectSrc1, lpRectSrc2);

Рисунок 13. Пересечение, объединение и два варианта исключения прямоугольников.

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

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

void InvertRect (hDC, lpRect);

инвертирует цвет указанного прямоугольника, выполняя операцию BITWISE NOT над всеми пикселями прямоугольника. Эта функция удобна для выделения какого-либо прямоугольника, так как повторное выполнение этой операции восстанавливает первоначальный вид прямоугольника.

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

int FillRect (hDC, lpRect, hBrush);

int FrameRect (hDC, lpRect, hBrush);

Функция FillRect закрашивает указанный прямоугольник требуемой кистью, а функция FrameRect проводит вокруг указанного прямоугольника каемку опять же кистью (не карандашом). Ширина проводимой каемки 1 пиксель как по горизонтали, так и по вертикали.

Вместо функции FillRect можно иногда применять функцию PatBlt, которая позволяет закрасить фон текущей кистью. Эта функция поддерживается непосредственно драйверами устройств, так что ее применение дает наиболее быстрый исполняемый код. Подробнее о функции PatBlt см. в разделе «Операции передачи образов»

Частный случай -- закраска прямоугольной области не кистью, а конкретным цветом. Очевидный способ -- создание однотонной кисти и закраска прямоугольника с помощью функции FillRect или Rectangle -- во-первых достаточно громоздок и, во-вторых, не гарантирует закраски именно чистым цветом -- кисть может оказаться смешанной из точек разных цветов. Наиболее быстрый способ -- использовать функцию ExtTextOut, указав ей пустую строку, ограничивающий прямоугольник и необходимость закраски прямоугольника цветом фона (флаг ETO_OPAQUE).

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

BOOL InvalidateRect (hWnd, lpRect, fEraseBkgnd);

BOOL ValidateRect (hWnd, lpRect);

Если вместо адреса структуры RECT указать NULL, то система будет подразумевать прямоугольник, совпадающий со всей внутренней областью окна.

Регионы

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

Регион является объектом GDI, на него распространяются все правила применения объектов GDI. В Windows описан набор функций, предназначенный для создания регионов, форма которых соответствует основным примитивам GDI, и, кроме того, функцию CombineRgn, которая позволяет из нескольких регионов простой формы построить один регион сложной формы.

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

HRGN CreateRectRgn (xLeft, yTop, xRight, yBottom);

HRGN CreateRectRgnIndirect (lpRect);

HRGN CreateRoundRectRgn (xLeft, yTop, xRight, yBottom, xRound, yRound);

HRGN CreateEllipticRgn (xLeft, yTop, xRight, yBottom);

HRGN CreateEllipticRgnIndirect (lpRect);

HRGN CreatePolygonRgn (lpPoints, nCount, nPolyFillMode);

HRGN CreatePolyPolygonRgn (lpPoints, lpCounts, nPolyCount, nPolyFillMode);

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

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

Как и всякий объект GDI регион удаляется с помощью функции DeleteObject.

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

int CombineRgn (hrgnDest, hrgnSrc1, hrgnSrc2, nMode);

Данная функция позволяет выполнить определенную параметром nMode операцию над двумя (или одним) исходными регионами и результат записать в третий регион. При этом новый регион не создается, вы должны предварительно создать какой-либо регион и его хендл передать в качестве hrgnDest. В этом регионе будет размещен результат выполнения операции. Такое, на первый взгляд странное, правило позволяет несколько уменьшить количество создаваемых объектов.

Итак, с помощью функции CombineRgn, мы можем выполнять различные операции, задавая номер нужной операции в параметре nMode:

При этом функция возвращает информацию о том, какой регион получен:

В заголовочном файле windowsx.h включено несколько макросов, основанных на функции CombineRgn:

int CopyRgn (hrgnDest, hrgnSrc); 2

int IntersectRgn (hrgnDest, hrgnSrc1, hrgnSrc2); 2

int SubtractRgn (hrgnDest, hrgnSrc1, hrgnSrc2); 2

int UnionRgn (hrgnDest, hrgnSrc1, hrgnSrc2); 2

int XorRgn (hrgnDest, hrgnSrc1, hrgnSrc2); 2

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

void SetRectRgn (hrgnSrc, lpRect);

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

Во-первых, мы можем применять регионы как абстрактные объекты, и выполнять над ними какие-либо операции, например перемещение, аналогично операциям над прямоугольниками:

int OffsetRgn (hrgnSrc, nDeltaX, nDeltaY);

или проверять совпадение регионов:

BOOL EqualRgn (hrgnSrc1, hrgnSrc2);

Кроме того мы можем проверить принадлежность точки или прямоугольника региону:

BOOL PtInRegion (hrgnSrc, nX, nY);

BOOL RectInRegion (hrgnSrc, lpRect);

И еще одна функция позволяет получить прямоугольник, описанный вокруг указанного региона:

int GetRgnBox (hrgnSrc, lpRect);

Во-вторых, регионы могут отображаться на контексте устройства, например для закраски областей или обведения контура области сложной формы:

BOOL InvertRgn (hDC, hrgnSrc);

BOOL PaintRgn (hDC, hrgnSrc);

BOOL FillRgn (hDC, hrgnSrc, hbrBrush);

BOOL FrameRgn (hDC, hrgnSrc, hbrBrush, nFrameWidth, nFrameHeight);

Функция InvertRgn осуществляет операцию BITWISE NOT над всеми точками, входящими в указанный регион; она аналогична функции InvertRect. Функция PaintRgn закрашивает регион текущей кистью. Она подобна функции FillRgn, которая закрашивает регион указанной вами, а не текущей, кистью. Самая интересная функция -- FrameRgn, которая проводит вокруг региона каемку указанной ширины и указанной кистью. То есть эта функция аналогична функции FrameRect, за исключением того, что область может быть сложной формы и вы можете задать ширину каемки, причем как по горизонтали, так и по вертикали.

Рисунок 14. Применение регионов для закраски и областей и обведения области контуром.

В-третьих, еще один из способов применения регионов связан с обработкой сообщения WM_PAINT. Ранее мы говорили о том, что сообщение WM_PAINT генерируется, когда у окна появляется неверный прямоугольник.

Это не совсем точно -- вместо неверного прямоугольника обычно используется регион. Аналогично прямоугольникам, у вас есть две функции, одна из которых объявляет неверный регион, а другая указывает, что регион стал верным:

void InvalidateRgn (hWnd, hrgnSrc, fEraseBkgnd);

void ValidateRgn (hWnd, hrgnSrc);

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

В-четвертых, регион, являясь объектом GDI, может быть выбран в контекст устройства. Регион, выбранный в контекст устройства, определяет область этого контекста, на которой возможно рисование. При этом он является как бы "маской" через которую видно рисуемое изображение.

Рисунок 15. Исходное изображение (слева), регион (в центре) и нарисованное изображение (справа). Светло-серым цветом показан неизменяемый данным рисунком фон.

Для того, что бы выбрать регион в контекст устройства, вы должны воспользоваться функцией

int SelectClipRgn (hDC, hrgnSrc);

Эта функция возвращает целое число, указывающее тип выбранного региона (SIMPLEREGION, COMPLEXREGION, NULLREGION). При выборе региона в контекст устройства он копируется, поэтому вы можете удалить его или использовать иным образом сразу после выбора в контекст устройства.

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

Растровые изображения и метафайлы

В Windows существует возможность хранить изображения в виде картинок, сохраняющих рисунок в виде информации о цветах отдельных точек. Такие изображения иногда называются растровыми, так как информация о цвете точек группируется по строкам растра изображения, или битмапами (bitmap), иногда термин bitmap даже переводят дословно -- битовая карта. В ранних версиях Windows битмапы точно соответствовали образу в графической памяти устройства, на которое осуществлялся вывод. При этом информация о передаче цветов соответствовала в точности формату цветовой памяти устройства. Такие битмапы получили название зависимых от устройства битмапов (device-depended bitmap, DDB)

Так, например, для четырехцветных видеоадаптеров CGA каждый пиксель кодировался двумя последовательными битами в видеопамяти -- такой-же была организация битмапов, отображаемых на дисплее. А если использовался 16^ти-цветный адаптер EGA, в котором для задания каждого пикселя требовалось задать 4 бита лежащих в различных цветовых плоскостях (planes), то и битмап создавался аналогично -- каждая строка растра была представлена 4 раза, для каждой цветовой плоскости по разу. Несомненным достоинством таких изображений была простота их отображения на конечном устройстве и высокая скорость вывода.

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

Все это привело к тому, что был разработан новый стандарт хранения растровых изображений -- так называемые независимые от устройства битмапы (device-independed bitmap, DIB). Этот битмап отличается от DDB как фиксированным способом кодирования цвета каждой точки -- последовательной группой бит -- так и наличием информации о назначении цветов -- так называемой палитры (palette) -- или иной информации, позволяющей определить точное назначение цветов каждой точки.

Начиная с Windows 3.x все битмапы, представленные в виде файлов или ресурсов приложения, являются независимыми от устройства битмапами (DIB), в то время как после загрузки в память приложения эти битмапы могут быть представлены как в виде независимых от устройства, так и в виде зависимых -- смотря по способу загрузки и использования.

Говоря о битмапах надо выделить несколько обсуждаемых аспектов, решаемых для каждого вида битмапов своим способом;

получение битмапа

формирование или коррекция изображения

отображение битмапа

сохранение независимых от устройства битмапов в файлах

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

Помимо растровых изображений (зависимых и независимых от устройства битмапов) в Windows предусмотрен еще один способ сохранения изображений -- сохранение рисунка в метафайлах.

Обзор зависимых от устройства битмапов (DDB)

Зависимый от устройства битмап (DDB) является объектом GDI и работа с ним осуществляется также, как и обычными объектами GDI -- перьями, кистями и прочим. Говоря об идентификации зависимого от устройства битмапа говорят о его хендле -- хендле объекта GDI. Более того, так как независимые от устройства битмапы не являются объектами GDI, то они также не имеют специфичных хендлов. Как только в тексте упоминается некоторый хендл битмапа (HBITMAP), то можно однозначно утверждать, что подразумевается зависимый от устройства битмап, DDB.

Более того, зависимые от устройства битмапы в реальной жизни представлены именно как объекты GDI, так как во всех современных версиях Windows изображения хранятся в виде независимых от устройства битмапов. То есть любой сохраняемый на диске (в виде файла или ресурсов приложения) битмап -- всегда независимый от устройства, и только после его загрузки в память в виде объекта GDI он станет зависимым от устройства битмапом.

Конечно, независимые от устройства битмапы могут быть загружены в память непосредственно, однако часто для представления в памяти используются именно DDB, так как его отображение выполняется быстрее и он как правило занимает меньше ресурсов.

Получение битмапа;

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

Формирование или коррекция битмапа;

Для рисования на битмапе создается контекст устройства, ассоциированный с данным битмапом, после чего все функции GDI, применяемые к этому контексту, реально взаимодействуют с битмапом и формируют его изображение. Для выполнения этой задачи предназначен совместимый контекст устройства (compatible DC, memory DC), который предназначен именно для этого.

Отображение битмапа на контексте устройства;

В конце концов все и затевается ради возможности отобразить битмап в окошке или на листе бумаги. GDI не содержит специальных функций для отображения DDB. Вместо этого вы должны ассоциировать битмап с контекстом устройства (как и для рисования), а затем осуществить передачу изображения с одного контекста на другой -- для этого в GDI содержится специальный набор функций, называемых функциями передачи растровых изображений или, дословно, функциями для передачи блоков бит (Bit Block Transfer, BLT -- произносится «блит»)

Обзор независимых от устройства битмапов (DIB)

Независимый от устройства битмап (DIB) объектом GDI не является. Он загружается в виде одного или нескольких блоков данных (подробнее о работе с блоками памяти см. в разделе «Диспетчер памяти»), его идентифицируют либо указатели на эти данные, либо хендл блока памяти, в котором этот битмап располагается (это зависит от применяемых функций). Если битмап сохраняется на диске (в виде отдельного файла или в виде ресурса приложения), то это непременно DIB.

После загрузки в память DIB может быть представлен как непосредственно в виде независимого от устройства битмапа, так и он может быть превращен в DDB. В том случае, если его представление соответствует DIB, то он реализован в виде нескольких взаимосвязанных структур данных, описывающих информацию о битмапе (заголовок и палитра) и непосредственно изображение. Иногда эти структуры размещаются в разных областях данных (тогда битмап идентифицируется указателями на эти данные), а иногда в одной -- в этом случае структура этой области данных примерно соответствует содержимому файла с DIB, но без заголовка файла -- такое представление называется упакованный DIB (packed DIB). В последнем случае для идентификации независимого от устройства битмапа может хватить одного хендла блока, содержащего упакованный DIB, однако этот хендл не является хендлом битмапа (HBITMAP).

При работе с DIB следует выбрать один из трех путей:

1) Работать с DIB непосредственно. Для этого предназначен достаточно большой набор функций, реализованный и в Windows API и в Win32 API.

Получение битмапа из файла или ресурса приложения;

Если битмап представлен в виде файла, то его загрузку необходимо выполнить самостоятельно; по счастью эта процедура может быть сведена всего к нескольким строчкам исходного кода. Можно, конечно, воспользоваться функциями LoadImage 1 или LoadBitmap, но это приведет к получению DDB, причем с организацией, соответствующей дисплею и соответствующего текущей выбранной палитре. Это может быть неудобно, особенно при необходимости этот битмап позже вывести на печать -- для этого лучше воспользоваться либо самим DIB, либо DDB, созданным под характеристики и под палитру, применяемую на устройстве отображения. Такую операцию можно выполнить, используя вместо функции LoadBitmap пару функций FindResource и LoadResource, что позволит получить непосредственно сам DIB. (Вместо LoadImage надо прочитать файл с битмапом).

Сохранение битмапа в файле;

Эту операцию надо выполнить самостоятельно, разобравшись со структурами, описывающими DIB, и записав их в файл в необходимом порядке.

Отображение битмапа на контексте устройства;

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

2) Работать с создаваемым промежуточным DDB. При этом DIB считывается и записывается также, как и в случае (1), однако дальше он преобразуется в DDB с которым и осуществляется все необходимая работа. Этот вариант является одним из самых эффективных, хотя и громоздких -- он позволяет получить обычный битмап с организацией, наиболее точно соответствующей устройству отображения, что позволяет как сэкономить ресурсы, так и ускорить процесс вывода.

3) Создать ассоциацию DIB с контекстом устройства. Этот путь похож на выбор обычного битмапа в контекст устройства с помощью функции SelectObject, однако осуществляется другими средствами и разным образом в разных API (Windows или Win32).

В случае 16^ти разрядной платформы Windows 3.x вы можете использовать специальный DIB драйвер, поставляемый в составе многих компиляторов

В случае Win32 вы можете использовать так называемую DIB-секцию, которая является своеобразным гибридом обычного битмапа (для нее возвращается HBITMAP, что позволяет применять ее как объект GDI) и независимого от устройства -- в памяти она представлена как нормальный DIB.

Обзор метафайлов

Альтернативный метод сохранения изображений представлен в виде метафайлов (metafile). Метафайл в строгом смысле рисунка не хранит, он сохраняет только последовательность команд (вызовов функций GDI) формирующих изображение.

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

Создание метафайлов;

Для создания метафайла создается специальный контекст устройства; все дальнейшие операции по рисованию на этом контексте запоминаются и сохраняются в виде метафайла. При удалении контекста устройства, связанного с метафайлом, создается объект GDI, представляющий данный метафайл. Этот метафайл может быть представлен либо в оперативной памяти, либо в виде файла -- смотря по тому, как вы создавали контекст устройства метафайла. Никаких специальных шагов для записи метафайла на диск предпринимать не надо.

Воспроизведение метафайла;

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

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

Зависимые от устройства битмапы

Обычный, зависимый от устройства битмап является простым образом видеопамяти. Его организация отражает особенности аппаратуры, на которой он должен воспроизводиться. DDB в приложении представляется как объект GDI; аналогично описанию перьев или кистей DDB описывается с помощью специальной структуры (BITMAP) и доступен посредством хендла этого объекта типа (HBITMAP).

typedef struct tagBITMAP {

int bmType;

int bmWidth;

int bmHeight;

int bmWidthBytes;

BYTE bmPlanes;

BYTE bmBitsPixel;

LPSTR bmBits;

} BITMAP;

Поле bmType должно быть 0, поля bmWidth и bmHeight определяют размеры изображения, bmPlanes и bmBitsPixel используются для указания способа кодирования информации о цвете точки и для указания максимального количества цветов.

Использование двух полей bmPlanes и bmBitsPixel связано с особенностями хранения цветного изображения разными видеоадаптерами. Например, CGA, IBM 8514 или SVGA в некоторых режимах для задания цвета пикселя отводят несколько последовательных бит памяти (CGA -- 2 бита, IBM -- 8 бит, SVGA -- до 32 бит на каждый пиксель). А адаптеры типа EGA или VGA (и, конечно, в некоторых режимах SVGA) содержат несколько так называемых битовых плоскостей, или планов (planes). В каждом плане одному пикселю соответствует только один бит, а цвет задается комбинацией бит в разных планах. Поле bmPlanes структуры BITMAP определяет количество цветовых планов, а поле bmBitsPixel -- количество последовательных бит, отведенных для задания цвета пикселя а одном плане. По крайней мере один из этих параметров равен 1 (или оба -- для монохромных битмапов).

Изображение в битмапе хранится разделенным на строки растра (scan line). Длина каждой строки округляется в большую сторону до ближайшей четной границы (кратна 2 байтам) и задается полем bmWidthBytes. Для вычисления длины строки надо произведение bmWidth * bmBitsPixel разделить на 8 и округлить в сторону завышения до ближайшего четного числа.

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

Поле bmBits теоретически должно указывать на собственно данные битмапа (массив строк растра). Однако оно используется далеко не всегда -- вы его можете задавать, но когда информацию о битмапе вам возвращает система (функция GetObject), то это поле не инициализируется -- для получения данных битмапа существует специальная функция -- GetBitmapBits.

Создание зависимого от устройства битмапа

Создание зависимых от устройства битмапов -- случай сравнительно редкий; обычно битмапы готовятся специальным графическим редактором и позже загружаются в память либо из файла, либо из ресурсов приложения. В связи с этим предлагаемый здесь материал нужен, в основном, для более близкого «фамильярного» знакомства с DDB; на практике использоваться этот материал будет редко. Предположим, что мы хотим создать битмап для использования в качестве кисти. Кисть всегда имеет размер 8x8 пикселей. Кроме того, для упрощения, мы будем предполагать, что используется монохромный битмап. Монохромный -- так как изображение этого битмапа мы опишем сами, а описание цветного битмапа непосредственно в приложении -- крайне неэффективное решение. Кроме того, монохромные битмапы обрабатываются несколько особым образом, так что есть повод обратить внимание на их особенности. Итак, пусть мы хотим получить следующую картинку:

Рисунок 16. Подготавливаемый рисунок монохромного битмапа (при использовании такого битмапа в качестве кисти мы получим "кирпичную стену").

Обратите внимание на нумерацию байтов и бит в байте -- байты (не слова) нумеруются слева-направо, а биты в байте -- справа-налево. Подготовим для этой картинки данные битмапа: так как ширина битмапа 8, количество бит на пиксель 1, то в одной строке растра должно быть 8 бит, значит ее длина 2 байта (четное число) или одно слово.

static WORD wBits[]={

0x00FF, 0x00C0, 0x00C0, 0x00C0, 0x00FF, 0x000C, 0x000C, 0x000C};

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

HBITMAP CreateBitmap (cxWidth, cyHeight, nPlanes, nBitsPixel, lpBits);

HBITMAP CreateBitmapIndirect (lpBitmap);

HBITMAP CreateCompatibleBitmap (hDC, cxWidth, cyHeight);

HBITMAP CreateDiscardableBitmap (hDC, cxWidth, cyHeight);

Функция CreateBitmap позволяет создать битмап с заданными характеристиками. В нашем случае это будет выглядеть так:

HBITMAP hBmp= CreateBitmap (8, 8, 1, 1, wBits);

Функция CreateBitmapIndirect позволяет сначала описать структуру типа BITMAP, а затем создать битмап по этой структуре. В нашем примере эту функцию можно использовать, например, таким образом:

static BITMAP stBmp= {

0, // bmType

8,8, // bmWidth, bmHeight

2, // bmWidthBytes

1,1, // bmPlanes, bmBitsPixel

NULL // bmBits};

HBITMAP hBmp= CreateBitmapIndirect (&stBmp);

SetBitmapBits (hBmp, sizeof (wBits), wBits);

Конечно, мы могли установить адрес образа (wBits) в поле bmBits и обойтись без функции SetBitmapBits но так мы рассмотрим на одну функцию больше.

В некоторых случаях мы будем создавать битмапы, которые должны быть по своим характеристикам совместимы с конкретным контекстом устройства. Для этого предназначена функция CreateCompatibleBitmap, которая создает битмап указанного размера и такой же организации, как указанный контекст устройства. Изображение при этом не задается -- битмап содержит набор случайных данных. Позже вы можете воспользоваться, например, функцией SetBitmapBits для задания данных битмапа.

Внимание! При создании совместимого битмапа надо указывать контекст реального устройства, совместимость с которым требуется. Если указать совместимый контекст устройства в качестве прототипа, то будет создан монохромный битмап.

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

Независимо от способа создания, существует одна особенность в применении монохромных битмапов: при его отображении на цветном устройстве для представления точек битмапа будут использоваться не черный и белый цвета, а текущий цвет фона (для всех бит, равных 0, -- обычно это белый цвет) и текущий цвет текста (для всех бит, равных 1, обычно это черный цвет). Таким образом вы можете в определенной мере управлять отображением монохромного битмапа с помощью функций SetTextColor и SetBkColor.

При необходимости вы можете узнать характеристики битмапа, используя функцию GetObject:

BITMAP stBmp;

GetObject (hBmp, sizeof (stBmp), &stBmp);

Однако эта функция не устанавливает поле bmBits структуры BITMAP. Для получения данных битмапа надо воспользоваться функцией: