СЕРИЯ >М>^ i*0* ло^' ,0^° д^° лв«ллЛ ЛОА* в^°° ;;^^>-' tgniTTEP*
WINDOWS GRAPHICS PROGRAMMING Win32 GDI and DirectDraw Feng Yuan Hewlett-Packard Company m invent www.hp.com/hpbooks Prentice Hall PTR Upper Saddle River, New Jersey 07458 www.phptr.com
Фень Юань Программирование графики для Windows МАСТЕР-КЛАСС Санкт-Петербург • Москва • Харьков • Минск 2002
Фень Юань Программирование графики для Windows Перевел с английского Е. Матвеев Главный редактор Е. Строганова Заведующий редакцией И. Корнеев Руководитель проекта А. Васильев Научный редактор Е. Матвеев Литературный редактор А. Жданов Художник Н. Биржаков Иллюстрации В. Шендерова Корректор В. Листова Верстка Ю. Сергиенко ББК 32.973-018.3 УДК 681.327.1 Юань Фень Ю12 Программирование графики для Windows (+CD). — СПб.: Питер, 2002. — 1072 с: ил. ISBN 5-318-00297-8 Книга посвящена графическому программированию для Windows с использованием Win32 GDI API. Кроме того, в ней приведены начальные сведения о DirectDraw и краткое введение в непосредственный режим Direct3D. Рассматриваются стандартные возможности, поддерживаемые на всех платформах Win32, 32-разрядные возможности, реализованные только в Windows NT/2000, и новейшие расширения GDI, появившиеся только в Windows 2000 и Windows 98. В книге приведено множество фрагментов кода, подходящих для практического применения. Помимо простейших тестовых и демонстрационных программ, вы найдете в ней множество функций, классов C++, драйверов, утилит и нетривиальных программ, вполне подходящих для использования в коммерческих проектах. На компакт-диске находятся полные исходные тексты, файлы рабочих областей Microsoft Visual C++, заранее откомпилированные двоичные файлы (в отладочных и окончательных версиях) и файлы в формате JPEG для глав, посвященных графическим алгоритмам. Original English language Edition Copyright © by Hewlett-Packard Company, 2001 © Перевод на русский язык, Е. Матвеев, 2002 © Издательский дом «Питер», 2002 Права на издание получены по соглашению с Prentice Hall, Inc. Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав. Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственность за возможные ошибки, связанные с использованием книги. ISBN 5-318-00297-8 ISBN 0-13-086985-6 (англ.) ЗАО «Питер Бук». 196105, Санкт-Петербург, Благодатная ул., д. 67. Лицензия ИД № 01940 от 05.06.00. Налоговая льгота - общероссийский классификатор продукции ОК 005-93, том 2; 953000 - книги и брошюры. Подписано в печать 25.12.01. Формат 70x100/16. Усл. п. л. 86,43. Тираж 5000 экз. Заказ№2493. Отпечатано с диапозитивов в ФГУП «Печатный двор» им. А. М. Горького Министерства РФ по делам печати, телерадиовещания и средств массовых коммуникаций. 197110, Санкт-Петербург, Чкаловский пр., 15.
Краткое содержание Глава 1. Основные принципы и понятия зо Глава 2. Архитектура графической системы Windows .... 84 Глава 3. Внутренние структуры данных GDI/DirectDraw . . 143 Глава 4. Мониторинг графической системы Windows .... 240 Глава 5. Абстракция графического устройства 282 Глава 6. Системы координат и преобразования 340 Глава 7. Пикселы 380 Глава 8. Линии и кривые 422 Глава 9. Замкнутые области 479 Глава 10. Основные сведения о растрах 535 Глава 11. Нетривиальное использование растров 608 Глава 12. Графические алгоритмы и растры Windows . . . . 663 Глава 13. Палитры 697 Глава 14. Шрифты 744 Глава 15. Текст 801 Глава 16. Метафайлы 897 Глава 17. Печать 947 Глава 18. DirectDraw и непосредственный режим Direct3D 1000 Алфавитный указатель 1058
Содержание Благодарности 21 Введение 22 О чем эта книга 23 Как организована эта книга 24 Как читать эту книгу . 27 Что находится на компакт-диске 28 Что дальше? 29 От издательства 29 Глава 1. Основные принципы и понятия зо Основы программирования для Windows на C/C++ 31 Hello World, версия 1: запуск браузера 32 Hello World, версия 2: вывод текста на рабочем столе 34 Hello, World, версия 3: создание полноэкранного окна 35 Hello, World, версия 4: вывод средствами DirectDraw 42 Ассемблер 46 Среда программирования 50 Разработка и тестирование 50 Компиляторы 52 Microsoft Platform SDK 55 Microsoft Driver Development Kit 58 Microsoft Developer Network 59 Формат исполняемых файлов Win32 61 Каталог импорта 65 Каталог экспорта 69 Архитектура операционной системы Microsoft Windows 71 HAL 73 Микроядро 73 Драйверы устройств 74 Управление окнами и графическая система 76 Исполнительная часть 77 Системные функции 78 Системные процессы 79 Службы 81 Платформенные подсистемы 81 Итоги 82 Примеры программ 82
Содержание 7 Глава 2. Архитектура графической системы Windows 84 Компоненты графической системы Windows 84 Мультимедиа 87 Video for Windows 88 Still Image 89 OpenGL 89 Windows Media 91 Компоненты режима ядра 92 Драйверы режима ядра 92 Архитектура GDI 93 Функции, экспортируемые из GDI32.DLL 94 Группы функций GDI 94 Вызовы системных функций GDI 97 От Win32 GDI API к системным функциям механизма GDI 98 Архитектура DirectX 99 Компоненты DirectX 100 Архитектура DirectDraw 102 Архитектура системы печати 105 Клиент спулера Win32 108 Служба спулера 108 Маршрутизатор спулера 108 Провайдер печати 109 Процессор печати ПО Языковой монитор и монитор порта 112 Процесс спулера изнутри 113 Графический механизм 114 Системные функции графического механизма 116 Механизм графической визуализации 118 Структуры данных графического механизма 120 Преобразование в примитивы 121 Шрифтовые драйверы 122 Драйверы экрана 123 Драйвер видеопорта и мини-драйвер видеопорта 123 Назначение драйвера экрана 124 Инициализация драйвера экрана 124 Вывод на поверхность, перехват и возврат 125 Дополнительные возможности драйвера 127 Поддержка DirectDraw/Direct3D на уровне драйвера экрана 127 Драйверы принтеров 129 Управляющие драйверы принтеров от Microsoft 130
Содержание Графическая библиотека DLL драйвера принтера 131 Драйвер принтера для вывода документа HTML 134 Итоги 141 Примеры программ 142 Глава 3. Внутренние структуры данных GDI/DirectDraw ... из Манипуляторы и объектно-ориентированное программирование 144 Класс и объект 144 Инкапсуляция и маскировка реализации 145 Указатели и манипуляторы 148 Тождественное отображение 149 Табличное отображение 149 Когда манипулятора недостаточно 150 Расшифровка манипуляторов объектов GDI 151 Манипуляторы стандартных объектов —константы 153 HGDIOBJ не является указателем 153 Максимальное количество манипуляторов GDI на уровне процесса —12 000 153 Максимальное количество манипуляторов GDI на уровне системы —16 384 154 Часть HGDIOBJ содержит индекс 154 Часть HGDIOBJ содержит тип объекта GDI 154 Поиск таблицы объектов GDI 156 Расшифровка таблицы объектов GDI 162 Указатель pKernel ссылается на выгружаемый пул 166 Поле nCount иногда используется как счетчик выбора объектов 166 Поле nProcess связывает манипулятор GDI с конкретным процессом .... 167 nUpper: дополнительная проверка 168 пТуре: внутренний тип объекта 169 pUser: указатель на структуру данных пользовательского режима 169 Структуры данных пользовательского режима 170 Структура данных пользовательского режима для кистей: оптимизация создания однородных кистей 170 Структура данных пользовательского режима для регионов: оптимизация прямоугольных регионов 171 Структура данных пользовательского режима для шрифтов: таблица значений ширины 172 Структура данных пользовательского режима для контекста устройства: атрибуты 172 Обращение к адресному пространству режима ядра 177
Содержание 9 WinDbg и расширение отладчика GDI 183 Структуры данных режима ядра 195 Таблица объектов GDI в механизме GDI 196 Типы объектов GDI в механизме GDI 196 Контекст устройства в механизме GDI 198 Структура PDEV в механизме GDI 202 Поверхности в механизме GDI 207 Аппаратно-зависимые растры в механизме GDI 210 DIB-секции в механизме GDI 211 Кисти в механизме GDI 212 Перья в механизме GDI 214 Палитры в механизме GDI 214 Регионы в механизме GDI 216 Траектории в механизме GDI 220 Шрифты в механизме GDI 224 Другие объекты GDI в механизме GDI 231 Структуры данных DirectDraw 231 Итоги 238 Примеры программ 238 Глава 4. Мониторинг графической системы Windows 240 Отслеживание вызовов функций Win32 API 241 Построение программы мониторинга 242 Внедрение DLL-разведчика 243 Подключение к цепочке вызовов функций API 246 Сбор информации 248 Вывод данных 254 Управляющая программа 257 Отслеживание вызовов Win32 GDI 260 Файл определения GDI API 260 Декодер данных GDI 262 Полный мониторинг API 264 Отслеживание СОМ-интерфейсов DirectDraw 268 Таблица виртуальных функций 268 Определение DirectDraw API 269 Модификация таблицы виртуальных функций . 270 Отслеживание системных вызовов GDI 271 Отслеживание интерфейса DDI 275 Итоги 279 Примеры программ 280
10 Содержание Глава 5. Абстракция графического устройства 282 Современные видеоадаптеры 282 Кадровый буфер 283 Формат пикселов 286 Двойная буферизация, z-буфер и текстуры 290 Аппаратное ускорение 293 Экранное устройство и перечисление режимов 293 Контекст устройства 296 Создание контекста устройства 298 Получение информации о возможностях устройства 299 Атрибуты в контексте устройства 304 Связь контекста устройства с окном 307 Графический вывод в многооконной среде 307 Получение контекста устройства, связанного с окном 309 Общий контекст устройства 313 Классовый контекст устройства 313 Закрытый контекст устройства 314 Родительский контекст устройства 315 Прочие контексты устройств 315 Информационный контекст устройства 315 Совместимый контекст устройства 316 Метафайловый контекст устройства 316 Формальное представление контекста устройства 318 Пример: родовой класс рамочного окна 321 Класс панели инструментов 322 Класс строки состояния 323 Класс холста 323 Класс рамочного окна 324 Тестовая программа 326 Пример программы: графический вывод в контексте устройства 328 Обновляемый регион окна 328 Сообщение WMJ>AINT 329 Наглядное представление сообщений перерисовки окна 331 Итоги 339 Примеры программ 339 Глава 6. Системы координат и преобразования 340 Физическая система координат 341 Система координат устройства 343 Страничная система координат и режимы отображения 345 Режим отображения MMJTEXT 348
Содержание 11 Режимы отображения MM_L.OENGL.ISH и MM_HIENGLISH 348 Режимы отображения MMJ.OMETRIC и MMJHIMETRIC 350 Режим отображения MMJTWIPS 351 Режим отображения MM JSOTROPIC 351 Режим отображения MM_ANISOTROPIC 352 Базовые точки окна и области просмотра 355 Другие функции окна и области просмотра 357 Мировая система координат 357 Аффинные преобразования 358 Функции мировых преобразований в Win32 API 361 Использование мировых преобразований 363 Использование систем координат 370 Реализация преобразований в GDI 372 Пример программы: прокрутка и масштабирование 373 Игра го в классе KScrollCanvas 377 Итоги 378 Примеры программ 379 Глава 7. Пикселы 380 Объекты GDI, манипуляторы и таблица объектов 380 Хранение объектов GDI 382 Таблица объектов GDI 383 Манипулятор объекта GDI 384 API объектов GDI 385 Обнаружение утечки объектов GDI 387 Отсечение 390 Конвейер отсечения 390 Простые регионы 391 Регион отсечения 392 Метарегион 396 Пять регионов контекста устройства 398 Наглядное представление регионов в контексте устройства 398 Цвет 402 Цветовое пространство RGB 403 Цветовое пространство HLS 406 Индексируемые цвета и палитры 411 Нетривиальные возможности 415 Вывод пикселов 415 Пример: множество Мандельброта 418 Итоги 421 Примеры программ 421
12 Содержание Глава 8. Линии и кривые 422 Бинарные растровые операции 422 Режим заполнения фона и цвет фона 426 Перья 427 Объект логического пера 427 Стандартные перья 429 Простые перья 430 Расширенные перья 433 Получение информации о логических перьях 439 Класс для работы с объектами перьев GDI 440 Линии 442 Кривые Безье 447 PolyDraw 451 Альтернативное определение кривых Безье 453 Дуги 454 Определение дуги в градусах: функция AngleArc 455 Рисование дуг пером со стилем PSJNSIDEFRAME 456 Преобразование дуг в кривые Безье 457 Траектории 461 Построение траектории 461 Получение информации о траектории 463 Преобразование объекта траектории 467 Графические операции с использованием траекторий 471 Преобразование пути в регион 473 Пример: рисование нестандартных стилевых линий 473 Итоги 477 Пример программы 478 Глава 9. Замкнутые области 479 Кисти 479 Объект логической кисти 479 Стандартные кисти 480 Пользовательские кисти 481 Кисти системных цветов 488 Структура LOGBRUSH 489 Прямоугольники 490 Прямоугольник как структура данных 490 Рисование прямоугольников 492 Прорисовка границ и элементов управления 495 Эллипсы, секторы, сегменты и закругленные прямоугольники 497
13 Многоугольники 500 Режим заполнения многоугольников 501 Замкнутые траектории 504 Регионы 506 Создание объекта региона 507 Операции с объектами регионов 510 Прорисовка регионов 521 Градиентные заливки 523 Градиентная заливка прямоугольников 525 Применение градиентных заливок для создания объемных кнопок 527 Практическое использование заливок 528 Полупрозрачная заливка 528 Реализация градиентных заливок в цветовом пространстве HLS 529 Радиальные градиентные заливки 530 Текстурные и растровые заливки 532 Узорные заливки 532 Итоги 533 Пример программы 534 Глава 10. Основные сведения о растрах 535 Аппаратно-независимые растры 535 Файловый формат BMP 536 Упакованный аппаратно-независимый растр 545 Разделенный аппаратно-независимый растр 546 Класс для работы с DIB 546 Отображение DIB в контексте устройства 556 StretchDIBits 556 Исходный прямоугольник 556 Приемный прямоугольник и режимы масштабирования 557 Преобразование цветового формата 559 Растровая операция 559 Пример использования функции StretchDIBits 560 SetDIBitsToDevice 561 Совместимые контексты устройств 563 Аппаратно-зависимые растры 564 CreateBltmap 565 CreateBitmapIndirect 566 GetObjectnDDB 567 CreateCompatibleBitmap и CreateDiscardableBitmap 567 CreateDIBitmap 569 LoadBitmap 570
Содержание Копирование растров между форматами DIB и DDB 571 Прямой доступ к массиву пикселов DDB 575 Использование DDB-растров 576 Отображение DDB-растров 576 Использование растров в меню 584 Использование растра в качестве фона окна 589 CreateDIBSection 594 Класс для работы с DIB-секциями 596 Функции GetObjectType и GetObject для DIB-секций 598 GetDIBColorTable и SetDIBColorTable 599 Применение DIB-секций: аппаратно-независимый вывод 600 Применение DIB-секций: вывод в высоком разрешении 603 Итоги 607 Примеры программ 607 Глава 11. Нетривиальное использование растров 608 Тернарные растровые операции 608 Коды растровых операций 609 Диаграмма тернарных растровых операций 612 Часто используемые растровые операции 614 Прозрачные растры 627 Функция PlgBIt 628 Кватернарные растровые операции: MaskBIt 635 Цветовые ключи: TransparentBIt 640 Прозрачность без маски 644 Прозрачный вывод с использованием геометрических фигур 644 Прозрачный вывод с использованием отсечения 646 Предварительная подготовка изображений 647 Альфа-наложение 649 Пример альфа-наложения с постоянным коэффициентом 652 Постепенное проявление и исчезновение растров 653 Прозрачные окна 653 Альфа-канал: класс AirBrush 655 Имитация альфа-наложения 659 Итоги 661 Примеры программ 661 Глава 12. Графические алгоритмы и растры Windows .... 663 Прямой доступ к пикселам 664 Аффинные преобразования растров 667 Быстрые специализированные преобразования растров 670
Содержание 15 Преобразования цветов 672 Преобразование растров в оттенки серого 675 Гамма-коррекция 676 Преобразование пикселов в растрах 678 Родовой класс преобразований пикселов 678 Родовой класс цветоделения 682 Пример выделения каналов 684 Гистограмма 686 Пространственные фильтры 686 Фильтры сглаживания и резкости 691 Выделение границ и рельеф 692 Морфологические фильтры 693 Итоги 695 Примеры программ 696 Глава 13. Палитры 697 Системная палитра 697 Параметры экрана 698 Получение системной палитры 699 Статические цвета 702 Логическая палитра 704 Палитра по умолчанию 705 Полутоновая палитра 706 Создание специализированной палитры 708 Сообщения палитры 710 WM_QUERYNEWPALETTE 710 WM_PALETTEISCHANGING 711 WM_PALETTECHANGED 711 Тестовая программа 712 Палитра и растры 716 Аппаратно-зависимые растры и палитры 717 Аппаратно-независимые растры и палитры 720 Индекс палитры в цветовой таблице DIB 723 DIB-секции и палитра 725 Квантование цветов 726 Сокращение цветовой глубины растра 736 Итоги 742 Пример программы 743 Глава 14. Шрифты 744 Что такое шрифт? 745 Наборы символов и кодировки 745
16 Содержание Глифы 751 Шрифт 753 Семейство шрифтов и начертание 754 Растровые шрифты 758 Векторные шрифты 762 Шрифты TrueType 765 Формат файлов шрифтов TrueType 765 Заголовок шрифта 768 Максимальный профиль 769 Отображение символов в индексы глифов 770 Индексная таблица 772 Данные глифов 773 Инструкции глифа 781 Горизонтальные метрики 786 Кернинг 789 Метрики OS/2 и Windows 790 Другие таблицы 791 Коллекции TrueType 792 Установка и внедрение шрифтов 793 Ресурсные файлы шрифтов 793 Установка открытых шрифтов 794 Установка закрытых шрифтов и шрифтов Multiple Master ОрепТуре 794 Установка шрифтов из образа в памяти 795 Внедрение шрифтов 795 Системная таблица шрифтов 799 Итоги 800 Примеры программ 800 Глава 15. Текст 801 Логические шрифты 801 Метрики шрифтов в Windows 802 Стандартные шрифты 804 Создание логических шрифтов 805 Подстановка шрифта 810 Система подстановки шрифтов PANOSE 811 Получение информации о логическом шрифте 817 Метрики растровых и векторных шрифтов 819 Метрики шрифтов TrueType/OpenType 822 Структура LOGFONTj* метрики шрифта 827 Точность шрифтовых метрик 827
Содержание 17 Простой вывод текста 833 Выравнивание текста 833 Вывод текста справа налево 836 Дополнительные интервалы 839 Ширина символа 841 Нетривиальный вывод текста 846 Преобразование символов в глифы 846 Кернинг 847 Расположение символов 848 Функция ExtTextOut 850 Uniscribe 854 Доступ к данным глифов 855 Форматирование текста 864 Вывод текста с табуляцией 864 Простое абзацное форматирование 866 Аппаратно-независимое форматирование текста 868 Эффекты при выводе текста 871 Цветтекста 872 Начертания 875 Геометрические эффекты 877 Работа с текстом в растровом формате 882 Текст как совокупность кривых 888 Текст как регион 894 Итоги 895 Пример программы 896 Глава 16. Метафайлы 897 Общие сведения о метафайлах 897 Создание расширенного метафайла 898 Воспроизведение расширенного метафайла 900 Получение информации о расширенном метафайле 903 Передача расширенных метафайлов 907 Строение расширенных метафайлов 911 Записи EMF 912 Классификация типов записей EMF 914 Расшифровка записей EMF 916 Простые объекты GDI в EMF 918 Растры в EMF 919 Регионы в EMF 921 Траектории в EMF 922 Палитры в EMF 922
Содержание Системы координат в EMF 924 Команды вывода в EMF 926 Аппаратная независимость EMF 929 Перечисление записей EMF 930 Класс C++ для перечисления записей EMF 931 Замедленное воспроизведение EMF 932 Трассировка воспроизведения EMF 933 Динамическое изменение EMF 935 Построение производных метафайлов 937 EMF как средство программирования 941 Декомпилятор EMF 941 Сохранение EMF-файла спулера 943 Итоги 945 Дополнительная информация 946 Примеры программ t 946 Глава 17. Печать 947 Знакомство со спулером 947 Процесс печати 948 Язык управления принтером 949 Прямой вывод в порт 952 Печать с использованием спулера 954 Процессор печати EMF 958 Перечисление принтеров 959 Получение информации о принтере 961 Настройка драйвера принтера 961 Базовая печать средствами GDI 965 Стандартные диалоговые окна печати 965 Создание контекста устройства принтера 971 Получение информации о контексте устройства принтера 973 Последовательность формирования заданий печати 975 Поддержка печати в программах 978 Единая логическая система координат . . 978 Имитация внешнего вида страницы 981 Одновременный вывод страниц 982 Печать нескольких страниц на одном листе 983 Родовой класс печати 984 Вывод в контексте устройства принтера .% 989 Единицы измерения 989 Текст 990
Содержание 19 Растры 993 Печать графики в формате JPEG 993 Итоги 998 Дополнительная информация 999 Примеры программ 999 Глава 18. DirectDraw и непосредственный режим Direct3D юоо Технология СОМ 1001 СОМ-интерфейсы 1001 СОМ-классы 1002 Создание СОМ-объекта 1004 HRESULT 1004 DirectX и СОМ 1005 Общие сведения о DirectDraw 1007 Интерфейс IDirectDraw7 1008 Интерфейс IDirectDrawSurface7 1010 Вывод на поверхности DirectDraw 1014 Подбор цветов 1018 Интерфейс IDirectDrawClipper 1020 Простое окно DirectDraw 1021 Построение графической библиотеки DirectDraw 1023 Вывод пикселов 1024 Вывод линий 1026 Заливка замкнутых областей 1029 Отсечение 1031 Внеэкранные поверхности 1033 Поддержка прозрачности посредством цветовых ключей 1035 Шрифт и текст 1035 Спрайты 1039 Непосредственный режим Direct3D 1043 Подготовка среды непосредственного режима Direct3D 1044 Изменение размеров окна 1047 Двухэтапный вывод \ 1048 Использование Direct3D в окне 1049 Текстурные поверхности 1050 Пример использования непосредственного режима Direct3D 1052 Итоги 1055 Примеры программ , 1056 Алфавитный указатель 1058
С любовью и благодарностью посвящаю эту книгу своим родителям... маме и светлой памяти отца, а также жителям моего родного города, восточного сада Сучжоу
Благодарности Эта книга никогда бы не появилась на свет без помощи, поощрения и поддержки многих людей, которым я искренне благодарен. Я хочу поблагодарить редактора HP Press Сьюзен Райт (Susan Wright) и редактора Prentice Hall PTR Джилл Пайсони (Jill Pisoni) — они доверили неизвестному программисту написание 650-страничной книги, которая в итоге разрослась до 1200 страниц, и прощали все задержки. В Prentice Hall PTR ведущий редактор Джеймс Маркхэм (James Markham) и выпускающий редактор Фей Геммеларо (Faye Gemmelaro) давали ценные указания по структуре книги и представлении технической информации, предлагали новые способы подачи материала, улучшали авторский стиль, помогали найти и решить многие проблемы. В Hewlett Packard действует замечательная программа, которая предоставляет работнику, пожелавшему написать техническую книгу, организационную поддержку со стороны HP. Спасибо моему начальнику и вдохновителю этой книги Айвену Креспо (Ivan Crespo) за постоянное содействие на протяжении всей работы над книгой. Четыре года назад я перешел в научно-исследовательскую лабораторию Hewlett-Packard в Ванкувере, где были разработаны всемирно известные принтеры HP DeskJet, обладая некоторыми навыками программирования Win 16. За изучением исходных текстов программ, в обсуждениях и спорах с коллегами, за программированием и трассировкой ассемблерного кода в SoftICE/W я узнал так много, что через полтора года решил обратиться в HP Press и предложить этот проект. Я благодарен работникам научно-исследовательской лаборатории Hewlett-Packard в Ванкувере за все, чему я у них научился, и за их поддержку. Перехожу к самому важному. Я вечно благодарен своей жене Инь Пен за то, что она поверила, поняла и поддержала меня во время моих долгих сражений с GDI на выходных, по вечерам и даже ночью. Наш сын, Чао Чу, тоже старался помочь и каждый вечер перед сном разглядывал экран монитора. Наконец-то у меня появится свободное время и этим летом мы непременно достроим его подводного робота. Фень Юань
Введение Новая книга, посвященная программированию для Windows, принесет пользу лишь в том случае, если будет содержать глубокую, полную, современную, достоверную и практичную информацию. Глубокая книга не останавливается на уровне API, а проникает в архитектурные концепции, внутренние структуры данных и принципы реализации API. Кроме того, она должна предоставить читателю средства для самостоятельных исследований. Полная и современная книга уделяет основное внимание лучшей из существующих на сегодняшний день реализаций Win32 API — Windows 2000, основе будущих операционных систем Microsoft, и описывает ее новые возможности. Достоверная книга базируется на экспериментальных исследованиях Win32 API и внимательной проверке всей информации. Отталкиваться только от документации Microsoft нельзя, поскольку в ней описывается абстрактный интерфейс Win32 API, также зачастую попадается неполная, устаревшая и неточная информация. Практичная книга выходит за рамки простого описания API и тривиальных пояснительных примеров. Она ориентируется на практические задачи; содержит программный код, который может использоваться в реальных программах; предоставляет в распоряжение читателя полезные утилиты и помогает ему в написании профессиональных программ. Как известно, Win32 GDI (и графическое программирование для Windows в целом) является одним из краеугольных камней любой Windows-программы. Этой теме посвящено немало книг, но все сообщество программистов, часто работающих с Windows GDI, определенно нуждается в более глубокой, более полной, более современной, более достоверной и более практичной информации. Именно этими целями автор руководствовался при написании книги.
О чем эта книга 23 О чем эта книга Книга посвящена графическому программированию для Windows с использованием Win32 GDI API. Кроме того, в ней приведены начальные сведения о DirectDraw и еще более краткое введение в непосредственный режим Direct3D. Рассматриваются стандартные возможности, поддерживаемые на всех платформах Win32, 32-разрядные возможности, реализованные только в Windows NT/ 2000, и новейшие расширения GDI, появившиеся только в Windows 2000 и Windows 98. В частности, приведено полное описание альфа-ргаложения, прозрачного блиттинга, градиентных заливок, правостороннего вывода текста, прозрачных окон и передачи на принтер изображений в формате JPEG/PNG. Книга дает читателю хорошее представление о том, как работает графическая система Windows, и учит его более уверенно и эффективно пользоваться Win32 API. Книга учит тому, что любая документация Win32 требует аналитического и критического подхода. Прежде всего необходимо понять, какой логикой руководствовались разработчики, а эксперименты и здравый смысл помогут вам лучше разобраться в Win32 API, самостоятельно найти отсутствующую информацию или ошибки в документации. Книга научит вас эффективно пользоваться утилитами, помогающими лучше понять Win32 API. Что еще важнее, она научит вас создавать такие утилиты самостоятельно (нередко с использованием хитроумных приемов системного программирования) и проводить интересные эксперименты при исследованиях недокументированных аспектов Win32 API. Несколько начальных глав содержат общие сведения о внутренней работе системы, применимые в других областях Windows-программирования. В книге приведено множество фрагментов кода, подходящих для практического применения. Помимо простейших тестовых и демонстрационных программ, вы найдете в ней множество функций, классов C++, драйверов, утилит и нетривиальных программ, вполне подходящих для использования в коммерческих проектах. В книге разрабатывается целая библиотека классов C++, при помощи которых вы сможете работать с простыми окнами, окнами SDI и MDI, стандартными и пользовательскими диалоговыми окнами, панелями инструментов, строками состояния и т. д. Классы, входящие в библиотеку, упрощают работу с DIB-растрами, DDB-растрами и DIB-секциями, воспроизведение EMF, применение растровых алгоритмов, квантование цветов, кодирование/декодирование изображений в формате JPEG, расшифровку файлов шрифтов, подстановку шрифтов по метрикам PANOSE, вывод глифов, построение объемного текста и т. д. Программы, приведенные в книге, не зависят ни от MFC (Microsoft Foundation Classes), ни от каких-либо других библиотек классов, поэтому они могут использоваться в любой программе на C++. Все имена классов начинаются с префикса «К», поэтому вы можете использовать их в MFC, ATL, OWL или в вашей персональной библиотеке классов.
24 Введение Как организована эта книга Графическое программирование для Windows рассматривается на трех уровнях: на уровне реализации, на уровне API и на прикладном уровне. К уровню реализации относится все, что осталось «за кулисами» Win32 GDI API и С ОМ-интерфейсов DirectX, — недокументированный мир графического механизма и клиентских библиотек DLL подсистем Windows. Материал, изложенный в главах 2, 3 и 4, закладывает прочную основу для понимания уровня API. На уровне API предоставляется четкое, точное, последовательное описание Win32 GDI API, а также (хотя и менее подробрю) DirectDraw и непосредственного режима Direct3D. Прикладной уровень расположен над уровнем API. К нему причисляется решение практических задач, создание функций, подходящих для повторного использования, классов C++ и нетривиальных программ. При изложении материала уровень API переплетается с прикладным уровнем. Обычно каждая глава начинается с описания уровня API, а затем переходит к практическим примерам. При изложении особо сложного материала (например, описания растров) в одной главе излагается основной теоретический материал, а в последующих главах — его нетривиальные применения. Глава 1, «Основные принципы и понятия», посвящена базовым концепциям Windows-программирования, используемым во всей книге. В ней приводятся общие сведения о программировании для Windows, языке ассемблера процессоров Intel, среде разработки программ, формате исполняемых файлов Win32 и архитектуре операционной системы Windows. Моя любимая часть посвящена простейшему перехвату функций API посредством модификации каталогов импорта/экспорта в модулях Win32. В главе 2, «Архитектура графической системы Windows», приведен общий обзор графической системы Windows, от DLL различных подсистем Win32 до драйверов графических устройств. В ней рассматриваются компоненты графической системы Windows, архитектура GDI, архитектура DirectX, архитектура подсистемы печати, графический механизм, драйверы экрана и принтеров. На мой взгляд, самое интересное в этой главе — описание системных функций, объединяющих реализацию GDI пользовательского режима с графическим механизмом режима ядра, утилита для составления списка вызовов недокументированных системных функций (в GDI32.DLL, USER32.DLL, NTDLL.DLL и WIN32K.SYS) и простой драйвер принтера, генерирующий страницы HTML с внедренными растровыми изображениями. Глава 3, «Внутренние структуры данных GDI/DirectDraw», читается как детектив или книга о поисках сокровищ. Глава начинается с объяснения парадигмы объектно-ориентированного программирования Win32, основанной на использовании манипуляторов. Затем мы пытаемся разобраться, что же собой представляет манипулятор объекта GDI, переходим к поиску таблицы объектов GDI и ее расшифровке. Далее описывается сложная иерархия структур данных, используемых во внутренней работе графической системы Windows. При поиске таблицы объектов GDI применяются отладочные файлы символических имен, специально написанные утилиты и отладчик Visual C++. Мы даже напишем драйвер устройства для чтения данных из адресного пространства режима ядра.
Как организована эта книга 25 В программе Fosterer, написанной для главы 3, используется расширение отладчика Microsoft для расшифровки таблицы объектов GDI и внутренних структур данных графического механизма DirectX — притом на одном компьютере! Не упускайте такой шанс и непременно опробуйте программу Fosterer на компьютере с Windows NT или 2000. Впрочем, сначала вам придется установить отладочные файлы с символическими именами и отладчик WinDbg. Считайте описание внутренних структур данных своего рода справочным материалом, который помогает разобраться в процессе отладки на уровне DDI, поскольку подробности реализации могут изменяться в зависимости от версии операционной системы и даже от версии Service Pack. Вы можете пропустить любой раздел, который покажется недостаточно интересным, и вернуться к нему, когда вам понадобится дополнительная информация — например, чтобы лучше понять использование ресурсов объектами GDI или проблемы быстродействия. В главе 4, «Мониторинг графической системы Windows», представлены различные приемы и инструменты для слежения за графической подсистемой и за системой Windows в целом. Вы узнаете, как внедрять свои DLL во внешние процессы, как подключиться к цепочке вызовов API, как отслеживать и перехватывать вызовы функций Win32 API, как перехватывать вызовы системных функций и методы СОМ-интерфейсов и, наконец, вызовы функций интерфейса DDI режима ядра. Мои любимые темы — написание заглушек на ассемблере, перехват внутримодульных вызовов, вызовов системных функций и функций DDI; все это дает представление о том, как же в действительности работает система. Глава 4 рассчитана на опытного программиста; если она вам пока не нужна — пропустите ее. С главы 5, «Абстракция графического устройства», начинается описание функций API графического программирования Windows и примеров их практического применения. В главе 5 рассматриваются видеоадаптеры, кадровые буферы, объекты контекстов устройств, родовой класс рамочного окна и вывод в окне. Моя любимая тема — программа WinPaint, которая дает наглядное представление о сообщениях перерисовки окна. В главе 6, «Системы координат и преобразования», рассматриваются четыре системы координат, поддерживаемые в GDI, отображение окна в область просмотра, мировые (аффинные) преобразования и их роль в прокрутке и изменении масштаба. Во время работы над книгой мне не удавалось вдоволь поиграть в любимую настольную игру «вэйчи», поэтому для главы 6 я написал простую программу, рисующую доску для вэйчи. Глава 7, «Пикселы», содержит краткий обзор объектов GDI, манипуляторов и таблицы объектов на уровне GDI API. Далее рассматривается программа, при помощи которой можно следить за использованием манипуляторов GDI на уровне системы. От регионов мы переходим к механизму отсечения, цветовым пространствам и выводу отдельных пикселов, а напоследок напишем программу для вывода множеств Мандельброта. Самое полезное в этой главе — это описание системных регионов, метарегионов, регионов отсечения и регионов Рао, используемых при отсечении, а также программы ClipRegion для их наглядного представления. В главе 8, «Линии и кривые», рассматриваются бинарные растровые операции, режимы заполнения фона, фоновые цвета, объекты логических перьев,
26 Введение линии, кривые Безье, дуги, траектории и стилевые линии, не поддерживаемые в GDI напрямую. На мой взгляд, в этой главе стоит обратить внимание на математические выкладки, связанные с преобразованием эллиптических кривых в кривые Безье. В главе 9, «Замкнутые области», описываются кисти, прямоугольники, эллипсы, секторы и сегменты, закругленные прямоугольники, многоугольники, замкнутые траектории, регионы, градиентные заливки и различные приемы заполнения замкнутых фигур, используемые в графических приложениях. Особый интерес представляет применение градиентных заливок для рисования трехмерных кнопок и описание структур данных регионов. Глава 10, «Основные сведения о растрах», посвящена трем растровым форматам, поддерживаемым в GDI, — аппаратно-независимым растрам (DIB), аппа- ратно-зависимым растрам (DDB) и DIB-секциям. В этой главе описаны классы для работы с DIB, DDB и DIB-секциями, совместимые контексты устройств и стандартные применения этих растровых форматов. Обратите внимание на классы, особенно на применение DIB-секций для аппаратно-независимого воспроизведения EMF. В главе И, «Нетривиальное использование растров», рассматриваются тернарные растровые операции, вывод прозрачных растров, реализация прозрачности без применения масок, альфа-наложение и одна из новых возможностей Windows 2000 — прозрачные окна. Моя любимая часть — полное описание растровых операций и имитация кватернарных растровых операций использованием нескольких тернарных операций. В главе 12, «Графические алгоритмы и растры Windows», описан прямой доступ к пикселам растров, аффинные преобразования растров, преобразования цветов и пикселов, а также пространственные фильтры. Глава 13, «Палитры», посвящена системным и логическим палитрам, сообщениям палитр, палитрам в растрах, квантованию цветов и распределению ошибок при сокращении количества цветов. Приведенная реализация алгоритма квантования цветов по октантному дереву часто строит более качественную палитру, чем коммерческие приложения. В главе 14, «Шрифты», рассматриваются наборы символов, кодировки, глифы, гарнитуры, семейства шрифтов, растровые и векторные шрифты, шрифты TrueType, установка шрифтов в системе и их внедрение в документы. Особенно интересный материал приведен в разделе, посвященном внутреннему формату файлов шрифтов TrueType. Глава 15, «Текст», посвящена логическим шрифтам, подстановке шрифтов, системе PANOSE, текстовым метрикам, простому и сложному выводу текста, форматированию и эффектам при выводе текста. Последняя тема заслуживает особого внимания; вы узнаете, как наложить растровое изображение на выводимый текст, как создать тени и имитировать рельеф, как вывести текст наклонно и вертикально, как разместить символы вдоль кривой, как преобразовать текст в растр или контур и как создается простейший объемный текст. В главе 16, «Метафайлы», рассматривается процесс создания и воспроизведения метафайлов, их внутреннее строение и особенности внедрения в них объектов GDI. Вы познакомитесь с расшифровкой EMF, перечислением записей,
Как читать эту книгу 27 декомпиляцией и сохранением данных спулера в формате EMF. На мой взгляд, самое интересное в этой главе — декомпилятор EMF и программа EMFScope, предназначенная для сохранения файлов спулера в Windows 95/98. Глава 17, «Печать», посвящена спулеру, простейшей печати средствами GDI, поддержке печати в приложениях, выводу графики в формате JPEG (включая непосредственную передачу JPEG драйверу принтера) и печати программ C++ с цветовым выделением синтаксических конструкций. Самое интересное в этой главе — набор универсальных классов для одновременного вывода нескольких страниц независимо от разрешения и масштаба устройства. Эти классы используются и в программе вывода JPEG, и в программе вывода исходных текстов. Глава 18, «DirectDraw и непосредственный режим Direct3D», содержит вводный курс программирования для DirectX, ориентированный на опытных программистов GDI. В ней излагаются основы СОМ, приводятся классы среды DirectDraw и поверхностей DirectDraw. Здесь описаны три способа вывода в DirectDraw, объекты отсечения, внеэкранные поверхности и вывод текста в DirectDraw. Кроме того, приведены классы для простейших операций непосредственного режима Direct3D, двойной буферизации, работы с текстурами и окон с поддержкой DirectDraw. Моя любимая часть — использование GDI для создания шрифтовых поверхностей DirectDraw, обеспечивающих эффективный вывод текста на поверхностях DirectX. Как читать эту книгу Книга предназначена в основном для опытных программистов, которые работают с Win32 API непосредственно или через библиотеки классов. Вероятно, новичку лучше начать с другой книги. Прежде всего необходимо познакомиться с принципами строения Windows-программ и внимательно разобраться в том как они работают. Если вас интересует только само графическое программирование и вы не хотите разбираться с подробностями реализации на уровне системы, прочитайте главы 1 и 2, пропустите главы 3 и 4 и продолжайте читать с главы 5. При желании вы даже можете пропустить некоторые разделы глав 1 и 2. Начиная с главы 5 материал излагается последовательно и систематично. Если вы принадлежите к числу опытных, квалифицированных программистов, значит, вы точно знаете, что именно вам нужно. Возможно, вам стоит бегло просмотреть начало книги и сразу перейти к главе 3. Если вас интересует программирование системного уровня (например, отслеживание вызовов API), прочитайте соответствующие части глав 1 и 2, а также главы 3 и 4. Наконец, если вы вообще не программист (например, если ваша работа связана с тестированием программ), в главе 2 вы найдете общий обзор графической системы Windows. Вероятно, стоит прочитать начало главы 3 — вы узнаете все, что необходимо знать об утечке ресурсов GDI, и получите в свое распоряжение полезные диагностические утилиты.
28 Введение Что находится на компакт-диске К книге прилагается компакт-диск с множеством программ-примеров, функций и классов. Точнее говоря, диск содержит свыше 1300 Кбайт исходных текстов C++, 400 Кбайт заголовочных файлов C++ и слегка видоизмененную версию исходных файлов библиотеки, основанной на свободно распространяемом коде Independent JPEG Group (www.ijg.org). Программы откомпилированы в 49 исполняемых файлов, три драйвера режима ядра и одну динамическую библиотеку пользовательского режима. Разумеется, в книге приведена лишь часть программного кода. На компакт- диске находятся полные исходные тексты, файлы рабочих областей Microsoft Visual C++, заранее откомпилированные двоичные файлы (в отладочных и окончательных версиях) и файлы в формате JPEG для глав, посвященных графическим алгоритмам. На компакт-диске имеется автоматически запускаемая программа установки, которая устанавливает программные файлы, создает в меню соответствующие ссылки и включает в него важные web-адреса, по которым можно загрузить утилиты Microsoft и найти техническую информацию. Программы были разработаны и протестированы в окончательной версии Windows 2000 (сборка 2195) на видеоадаптере, поддерживающем аппаратное ускорение двумерной и трехмерной графики DirectX 7.0, хотя многие программы успешно работают в Windows 95/98/NT 4.0 и не требуют поддержки DirectX. Для самостоятельной компиляции программ в вашей системе должны быть установлены следующие компоненты. О Компилятор Visual C++ 6.0. О Обновление Visual Studio 6.0 Service Pack 3 (msdn.microsoft.com/vstudio/sp/vs6sp3). О Электронная документация библиотеки MSDN. О Обновленные заголовочные и библиотечные файлы, а также утилиты из пакета Platform SDK (www.microsoft.com/downloads/sdks/platform/platform.asp). Убедитесь, что компилятор VC 6.0 настроен на использование заголовочных файлов и библиотечных каталогов Platform SDK. О Отладочные файлы символических имен Windows 2000 используются некоторыми утилитами и оказывают немалую помощь в отладке (www.microsoft.com/ windows200/downloads/otherdownloads/symbols). О Windows 2000 DDK (www.microsoft.com/ddk) используется некоторыми драйверами режима ядра. Добавьте каталог inc DDK к каталогам заголовочных файлов VB. Добавьте каталог Iibfre\i386 DDK к каталогам библиотечных файлов VC. О WinDebug (www.microsoft.com/ddk/debugging) используется системными утилитами главы 3. Хотя все примеры в этой книге написаны на C++ без применения MFC, программисты MFC, ATL или OWL смогут без особого труда воспользоваться этим кодом. Даже программисты Visual Basic или Delphi найдут немало полезного в примерах, поскольку эти среды разработки поддерживают прямой вызов функций Win32 API.
От издательства 29 Что дальше? Работая над книгой, автор должен привести в порядок свои мысли, провести необходимые исследования и представить материал в логичной, последовательной манере. Надеюсь, эта книга, в которой я постарался подробно передать приобретенные знания, сможет чему-то научить и моих коллег-программистов. Но теперь читатели со всего мира становятся моими учителями и соучениками. Если вы обнаружите какую-нибудь ошибку или неточность, если у вас появятся комментарии, предложения или жалобы, свяжитесь со мной через мой персональный web-сайт http://www.fengyuan.com. На этом сайте также можно найти ответы на часто встречающиеся вопросы, обновления, описания наиболее сложных примеров и т. д. От издательства Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! Подробную информацию о наших книгах вы найдете на web-сайте издательства http://www.piter.com.
Глава 1 Основные принципы и понятия Мы отправляемся в путешествие по графической системе Windows и исследуем ее вдоль и поперек, от гладкой поверхности (уровня графических функций Win32 API) до каменистого дна (уровня драйверов экрана/принтера). Графическая система Windows содержит немало важных элементов, однако наше внимание будет сосредоточено на ее главных составляющих: интерфейсе Win32 GDI (Graphics Device Interface — интерфейс графических устройств) и компоненте DirectDraw интерфейса DirectX. Функции Win32 GDI API реализованы на многих платформах, в том числе на Win32s, Win95/98, Win NT 3.5/4.0, Windows 2000 и WinCE, причем между этими реализациями существуют значительные отличия. Например, Win32s и Win95/98 основаны на старой 16-разрядной реализации GDI с многочисленными ограничениями, а полноценные 32-разрядные реализации Windows NT 3.5/4.0 и Windows 2000 обладают гораздо большими возможностями. Интерфейсы DirectDraw характерны для платформ Win95/98, Win NT 4.0 и Windows 2000. Эта книга в основном ориентируется на платформы Windows NT 4.0 и Windows 2000, обладающие самыми мощными реализациями этих интерфейсов. Замечания, относящиеся к другим платформам, будут приводиться по мере необходимости. Но прежде чем переходить к углубленному изучению графической системы Windows, необходимо разобраться в некоторых базовых концепциях, играющих очень важную роль для дальнейших исследований. В этой главе описываются основные принципы программирования для Windows на C/C++, приводится краткий обзор программирования на ассемблере, сред программирования и отладочных средств, а также рассматриваются формат исполняемых файлов Win32 и общая архитектура операционной системы Windows.
Основы программирования для Windows на C/C++ 31 ПРИМЕЧАНИЕ Предполагается, что читатель уже обладает некоторым опытом программирования для Windows, поэтому материал излагается очень кратко. Основы программирования для Windows на C/C++ Профессия программиста прошла драматический путь развития от «средневековых» машинных кодов до современных языков программирования — таких, как С, Visual Basic, Pascal, C++, Delphi и Java. Считается, что количество строк программного кода, написанных программистом за день, практически не зависит от используемого языка. Следовательно, чем выше продвигается язык по уровню абстракции, тем продуктивнее становится работа программиста. До недавнего времени самым распространенным языком программирования для Windows считался С — в этом нетрудно убедиться по примерам программ, включенным в пакеты Microsoft Platform Software Development Kit (Platform SDK) и Device Driver Kit (DDK). Объектно-ориентированные языки — такие, как C++, Delphi и Java — быстро набирают темп и постепенно вытесняют С и Pascal. Они составляют новое поколение языков программирования для Windows. Несомненно, объектно-ориентированные языки являются шагом вперед по сравнению со своими предшественниками. Скажем, C++ даже без применения «чистых» объектных средств (классов, наследования, виртуальных функций и т. д.) превосходит С по таким современным возможностям, как жесткая прототипизация, шаблоны и подставляемые (inline) функции. Однако написание объектно-ориентированных программ для Windows — задача не из простых, поскольку прикладной интерфейс Windows (Windows API) разрабатывался без учета поддержки объектно-ориентированных языков. Например, функции косвенного вызова (в частности, обработчики сообщений и процедуры диалоговых окон) должны быть глобальными. Компилятор C++ не позволяет передать обычную функцию класса в качестве функции косвенного вызова. Для «упаковки» Windows API в иерархию классов была разработана библиотека Microsoft Foundation Classes (MFC), которая фактически превратилась в стандарт объектно-ориентированного программирования для Windows. MFC в значительной степени решает проблему интеграции объектно-ориентированного языка C++ с интерфейсом Win32 API, ориентированным на язык С. MFC передает одну глобальную функцию в качестве общего обработчика сообщений окна. Эта функция преобразует HWND в указатель на объект CWnd, переходя таким образом от манипулятора (handle) окна Win32 к указателю на объект окна C++. С ростом популярности технологий OLE, COM и ActiveX даже компания Microsoft обеспокоилась огромными размерами и сложностью MFC, поэтому для написания облегченных СОМ-серверов и элементов ActiveX сейчас рекомендуется использовать другую библиотеку классов от Microsoft — Active Template Library (ATL).
32 Глава 1. Основные принципы и понятия С учетом тенденций перехода на объектно-ориентированное программирование примеры программ в этой книге написаны в основном на C++, а не на С. Чтобы приведенный код приносил пользу программистам, работающим на С, C++, MFC, ATL, C++ Builder и даже Delphi с Visual Basic, в книге не используются ни экзотические возможности C++, ни специфические средства MFC/ATL. Hello World, версия 1: запуск браузера Довольно теории — перейдем к написанию несложных Windows-программ на C++. Ниже приведен исходный текст нашей первой программы. //Hellol.cpp #define STRICT #include <windows.h> #include <tchar.h> #include <assert.h> const TCHAR szOperation[] = _T("open"); const TCHAR szAddress[] = _T("www.helloworld.com"); int WINAPI WinMain(HINSTANCE hlnst. HINSTANCE. LPSTR IpCmd. int nShow) { HINSTANCE hRslt = ShellExecute(NULL, szOperation. szAddress. NULL. NULL. SWJHOWNORMAL); assert( hRslt > (HINSTANCE) HINSTANCE JRROR): return 0; } ПРИМЕЧАНИЕ Примеры программ на прилагаемом компакт-диске находятся в каталогах, имена которых соответствуют номерам глав — ChaptOl, Chapt02 и т. д. Весь общий код расположен в дополнительном каталоге include на одном уровне с каталогами глав. В каталоге каждой главы находится один файл рабочей области Microsoft Visual C++, содержащий все проекты данной главы. Каждый проект находится в отдельном подкаталоге; например, проект Hello 1 расположен в каталоге Chapt_01\Hellol. В ссылках на общие файлы (например, win.h) в исходном тексте используются относительные пути вида ..\\..\include\win.h. Перед вами не стандартная программа «Hello, World», ограничивающаяся выдачей текстового сообщения, а новый представитель этого семейства из эпохи Интернета. Если выполнить эту программу, функция Win32 API Shell Execute запустит браузер и откроет в нем заданную web-страницу. В этой простой программе следует обратить внимание на некоторые особенности, которые редко встречаются в тривиальных примерах, приводимых в других книгах. Автор включил в нее эти аспекты, поскольку они способствуют развитию правильного стиля программирования. Программа начинается с определения макроса STRICT. Это сделано для того, чтобы при включении заголовочных файлов Windows различные типы объектов
Основы программирования для Windows на C/C++ 33 интерпретировались по-разному, и компилятору было проще выдавать программисту предупреждения о том, что он путает HANDLE с HINSTANCE или HPEN — с HBRUSH. Когда читатели жалуются, что примеры из некоторых книг даже не компилируются, скорее всего, эти примеры не были протестированы с определением макроса STRICT. Дело в том, что новые версии заголовочных файлов Windows включают STRICT по умолчанию, а старые версии этого не делают. Включение файла <tchar.h> обеспечивает возможность компиляции одного исходного текста в двоичный код как с поддержкой Unicode, так и без нее. Программы, предназначенные для операционных систем из семейства Windows 95/98, не рекомендуется компилировать в режиме Unicode, а если это все же делается — программист должен действовать очень внимательно и избегать применения функций API на базе Unicode, не реализованных в Win95/98. Помните, что параметр lpCmd функции WinMain никогда не кодируется в Unicode; для получения TCHAR-версии полной командной строки следует воспользоваться функцией GetCommandLineO. Включение файла <assert.h> относится к области защищенного программирования. Желательно, чтобы программист в пошаговом режиме выполнил каждую строку своей программы и убедился в отсутствии ошибок. Проверка параметров и возвращаемых значений функций директивой assert помогает обнаруживать непредвиденные ситуации на протяжении всей фазы разработки. Существует и другой способ перехвата ошибок программирования — обработка исключений в программе. Два определения массивов const TCHAR гарантируют, что эти строковые константы будут размещены в области данных, доступных только для чтения, окончательной версии двоичного кода, сгенерированной компилятором и компоновщиком. Если включить строки вида _Т( "print") прямо в вызов Shell Execute, скорее всего, они в итоге попадут в область данных, доступных для чтения/записи. Размещение констант в области данных, доступных только для чтения, гарантирует, что эти данные будут только читаться, а при попытке записи в них произойдет общая ошибка защиты (General Protection Fault, GPF). Кроме того, эти данные могут совместно использоваться разными экземплярами программы, что позволяет экономить память при запуске нескольких экземпляров одного модуля в системе. Имя второго параметра функции WinMain (обычно он называется hPrevInstance) при вызове не указывается, поскольку в программах Win32 он не используется. В Winl6 параметр hPrevInstance содержал манипулятор предыдущего экземпляра текущей программы. В Win32 каждая программа работает в отдельном адресном пространстве. Даже если в системе работают несколько экземпляров одной программы, обычно они не «видят» друг друга. Написать идеальную программу трудно, а то и вовсе невозможно, однако при помощи некоторых приемов вы можете заставить компилятор построить идеальный двоичный код. Для этого необходимо правильно выбрать тип процессора, runtime-библиотеку, тип оптимизации, способ выравнивания полей структур и базовый адрес DLL. Отладочная информация, файл символических имен или даже листинг на языке ассемблера помогут в процессе отладки, анализа отчетов или тонкой настройки быстродействия. Другой подход заключается в анализе двоичного кода с применением символических данных, средств быстрого про-
34 Глава 1. Основные принципы и понятия смотра Проводника Windows 95/98/NT и Dumpbin; вы должны убедиться в том, что программа экспортирует нужные функции, не импортирует никаких необычных функций, а также в том, что двоичный код не содержит неожиданных фрагментов. Например, программа, импортирующая функцию 420 библиотеки oleauto.dll, не будет работать в ранних версиях Win95. Если программа загружает несколько DLL по одному и тому же базовому адресу, ее выполнение замедляется из-за динамического перемещения. Если откомпилировать проект Hello 1 с параметрами по умолчанию, размер исполняемого двоичного файла в окончательной (release) версии равен 24 Кбайт. Программа импортирует три десятка функций Win32 API, хотя в исходном тексте используется лишь одна функция. В программе задействовано около 3000 байт инициализированных глобальных данных, хотя непосредственно в программе никаких данных не используется. Если попытаться выполнить программу в пошаговом режиме, вскоре выясняется, что WinMain в действительности не является начальной точкой нашей программы. Вызову WinMain в настоящей начальной функции WinMainCRTStartup предшествует немало других событий. В таких простых программах, как Hellol.cpp, можно воспользоваться DLL- версией runtime-библиотеки С и написать свою собственную реализацию функции WinMainCRTStartup — в этом случае компилятор и компоновщик сгенерируют действительно небольшой двоичный код. Эта возможность продемонстрирована в следующем примере. Hello World, версия 2: вывод текста на рабочем столе Поскольку книга посвящена программированию графики в Windows, основное внимание в ней должно уделяться графическим функциям API. Исходя из этого, следующая версия «Hello, World» работает несколько иначе. #define STRICT #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <tchar.h> #include <assert.h> void CenterText(HDC hDC. int x. int y. LPCTSTR szFace, LPCTSTR szMessage. int point) { HFONT hFont - CreateFont( -point * GetDeviceCaps(hDC. LOGPIXELSY) / 72. 0. 0. 0. FW_B0LD, TRUE. FALSE. FALSE. ANSI_CHARSET. 0UT_TT_PRECIS. CLIP_DEFAULT_PRECIS. PR00F_QUALITY. VARIABLE_PITCH. szFace); assert(hFont); HGDI0BJ hOld = Select0bject(hDC. hFont): SetTextAlign(hDC. TA_CENTER | TA_BASELINE);
Основы программирования для Windows на C/C++ 35 SetBkModeChDC. TRANSPARENT); SetTextColorChDC. RGB(0. 0, OxFF)): TextOut(hDC. x, y, szMessage. _tcslen(szMessage)); SelectObject(hDC. hOld); DeleteObject(hFont); } const TCHAR szMessage[] = _T("Hello. World"); const TCHAR szFace[] = _T("Times New Roman"); #pragma comment(linker, "-merge:.rdata=.text") #pragma comment(linker. "-align:512") extern "C" void WinMainCRTStartupO { HDC hDC = GetDC(NULL); assert(hDC); CenterText(hDC. GetSystemMetrics(SM_CXSCREEN) / 2. GetSystemMetrics(SM_CYSCREEN) / 2. szFace, szMessage. 72); ReleaseDC(NULL. hDC); ExitProcess(O); } Приведенная выше программа при помощи простых функций GDI выводит строку «Hello, World» в центр экрана, не создавая окна. Программа получает контекст устройства для окна рабочего стола (или основного монитора при наличии нескольких мониторов), создает курсивный шрифт с высотой символов в 1 дюйм и выводит строку «Hello, World» в прозрачном режиме сплошным синим цветом. Чтобы двоичный код занимал как можно меньше места, программа создает собственную функцию WinMainCRTStartup вместо того, чтобы использовать стандартную реализацию, предоставленную runtime-библиотекой C/C++. Последняя команда программы, ExitProcess, завершает выполнение процесса. Программа также приказывает компоновщику объединить область данных, доступных только для чтения (. rdata), с областью кода, доступной для чтения и исполнения (.text). Исполняемый файл, сгенерированный в окончательной версии, имеет размер всего 1536 байт. Hello, World, версия 3: создание полноэкранного окна Первая и вторая версии «Hello, World» не относились к числу обычных Windows-программ, работающих в окне. В них использовались лишь немногочисленные вызовы функций Windows API, которые показывали, как написать элементарную программу для Windows. Обычная оконная программа, написанная на C/C++, сначала регистрирует несколько классов окон, после чего создает главное окно (возможно — несколь-
36 Глава 1. Основные принципы и понятия ко дочерних окон) и входит в цикл, в котором все поступающие сообщения направляются соответствующим обработчикам. Вероятно, многие читатели хорошо знакомы с подобными примерами простейших Windows-программ. Чтобы не создавать очередной дубликат, мы попробуем написать простую объектно-ориентированную оконную программу на C++, не используя MFC. Для этого нам понадобится очень простой класс KWindow, реализующий основные операции по регистрации класса окна, созданию окна и доставке оконных сообщений. Первые две задачи решаются просто, но с третьей дело обстоит сложнее. Конечно, нам хотелось бы оформить функцию обработки сообщений как виртуальную функцию класса KWindow, но Win32 API запрещает использование подобных функций в качестве функции окна. При вызове функций классов C++ передается неявный указатель this, а их схемы передачи параметров могут отличаться от той, которая используется функцией окна. Одно из распространенных решений заключается в применении статической функции окна, которая передает запросы соответствующей функции класса C++. Для этого статическая функция окна должна иметь указатель на экземпляр KWindow. В нашем примере эта задача решается передачей указателя на экземпляр KWindow при вызове CreateWindowEx и его сохранением в структуре данных, связанной с каждым окном. ПРИМЕЧАНИЕ Имена всех классов C++ в этой книге начинаются с буквы «К» вместо традиционного префикса «С». Это упрощает работу с классами в программах, использующих MFC, ATL или другие библиотеки классов. Ниже приведен заголовочный файл класса KWindow. // win.h #pragma once class KWindow { virtual void OnDrawCHDC hDC) { } virtual void OnKeyDownCWPARAM wParam. LPARAM IParam) { } virtual LRESULT WndProc(HWND hWnd, UINT uMsg. WPARAM wParam. LPARAM IParam); static LRESULT CALLBACK WindowProcCHWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam); virtual void GetWndClassEx(WNDCLASSEX & vie): public: HWND m hWnd;
Основы программирования для Windows на C/C++ 37 KWindow(void) { m_hWnd - NULL; } virtual -KWindow(void) virtual bool CreateExCDWORD dwExStyle. LPCTSTR IpszClass. LPCTSTR IpszName, DWORD dwStyle, int x. int y, int nWidth, int nHeight. HWND hParent. HMENU hMenu. HINSTANCE hlnst); bool RegisterClassCLPCTSTR IpszClass. HINSTANCE hlnst); virtual WPARAM MessageLoop(void); BOOL ShowWindow(int nCmdShow) const { return ::ShowWindow(m hWnd, nCmdShow); BOOL UpdateWindow(void) const { return ::UpdateWindow(m_hWnd); Класс KWindow содержит всего одну переменную m_hWnd, в которой хранится манипулятор окна. В классе присутствует конструктор, виртуальный деструктор, функция для создания окна, а также функции цикла обработки сообщений, отображения и обновления окон. Закрытые (private) функции класса KWindow определяют структуру WNDCLASSEX и обрабатывают сообщения данного окна. Статическая функция WindowProc создается в соответствии с требованиями Win32 API; она передает сообщения виртуальной функции WndProc. Многие функции класса определяются как виртуальные, чтобы их поведение могло быть изменено в классах, производных от KWindow. Например, разные классы будут иметь разные реализации OnDraw, а в их реализации GetWndClassEx будут использоваться разные меню и курсоры. Удобная директива компилятора Visual C++ (#pragma once) помогает избежать многократного включения одного заголовочного файла. Чтобы добиться того же эффекта, можно определить дкя каждого заголовочного файла уникальный макрос и пропускать заголовочный файл в том случае, если макрос уже определен. Ниже приведена реализация класса KWindow. // win.cpp #define STRICT #define WIN32 LEAN AND MEAN #include <windows.h> #include <assert.h> #include <tchar.h>
38 Глава 1. Основные принципы и понятия #include "Awin.h" LRESULT KWindow::WndProc(HWND hWnd. UINT uMsg, WPARAM wParam, LPARAM IParam) { switch( uMsg ) { case WM_KEYDOWN: OnKeyDown(wParam. IParam); return 0; case WM_PAINT: { PAINTSTRUCT ps; BeginPaint(m_hWnd. &ps); OnDraw(ps.hdc); EndPaint(m_hWnd. &ps); } return 0; case WM_DESTROY: PostQuitMessage(O); return 0; } return DefWindowProcChWnd. uMsg. wParam. IParam); } LRESULT CALLBACK KWindow::WindowProc(HWND hWnd, UINT uMsg. WPARAM wParam, LPARAM IParam) { KWindow * pWindow; if ( uMsg—WMJICCREATE ) { assert( ! IsBadReadPtr((void *) IParam, sizeof(CREATESTRUCT)) ); MDICREATESTRUCT * pMDIC - (MDICREATESTRUCT *) ((LPCREATESTRUCT) 1Param)->1pCreateParams; pWindow - (KWindow *) (pMDIC->lParam); assert( ! IsBadReadPtr(pWindow, sizeof(KWindow)) ); SetWindowLong(hWnd, GWL USERDATA, (LONG) pWindow); } else pWindow-(KWindow *)GetWindowLong(hWnd. GWLJJSERDATA); if ( pWindow ) return pWindow->WndProc(hWnd. uMsg, wParam, IParam); else return DefWindowProc(hWnd. uMsg. wParam, IParam); } boo! KWindow::RegisterClass(LPCTSTR IpszClass. HINSTANCE hlnst)
Основы программирования для Windows на C/C++ 39 WNDCLASSEX wc: if ( ! GetClassInfoExChlnst. IpszClass. &wc) { GetWndClassEx(wc); wc.hlnstance = hlnst; wc.lpszClassName = IpszClass; if ( !RegisterClassEx(&wc) ) return false; } return true; bool KWindow::CreateEx(DWORD dwExStyle. LPCTSTR IpszClass. LPCTSTR IpszName, DWORD dwStyle. int x. int y, int nWidth. int nHeight, HWND hParent. HMENU hMenu. HINSTANCE hlnst) { if ( ! RegisterClassdpszClass, hlnst) ) return false; // Использовать MDICREATESTRUCT для поддержки дочерних окон MDI MDICREATESTRUCT mdic; memset(& mdic, 0. sizeof(mdic)); mdic.1 Pa ram = (LPARAM) this; m_hWnd = CreateWindowExCdwExStyle. IpszClass. IpszName, dwStyle. x. y. nWidth. nHeight. hParent. hMenu. hlnst. & mdic): return m hWnd!=NULL; void KWindow::GetWndClassEx(WNDCLASSEX & wc) { memset(& wc, 0, sizeof(wc)); wc.cbSize - sizeof(WNDCLASSEX); wc.style - 0; wc.lpfnWndProc - WindowProc; wc.cbClsExtra - 0: wc.cbWndExtra - 0; wc.hlnstance - NULL; wc.hlcon = NULL; wc.hCursor - LoadCursor(NULL. IDC_ARR0W); wc.hbrBackground - (HBRUSH)GetStockObject(WHITE_BRUSH); wc.lpszMenuName - NULL: wc.lpszClassName - NULL wc.hlconSm - NULL
40 Глава 1. Основные принципы и понятия WPARAM KWindow::MessageLoop(void) { MSG msg; while ( GetMessage(&msg, NULL. 0. 0) ) { TranslateMessage(&msg); DispatchMessage(&msg); } return msg.wParam; } Реализация KWindow довольно проста, если не считать статической функции WindowProc. Функция WindowProc отвечает за передачу сообщений от операционной системы Windows соответствующим обработчикам класса KWindow. Для этого мы должны иметь возможность получить указатель на экземпляр класса KWindow в функции окна Win32. С другой стороны, указатель передается только при вызове CreateWindowEx. Чтобы значение, передаваемое всего один раз, могло использоваться многократно, мы должны его где-то сохранить. В MFC информация хранится в глобальной карте, связывающей значения HWND с указателями на экземпляры класса CWnd, поэтому каждый раз, когда требуется доставить сообщение, производится хэшированный поиск нужного экземпляра CWnd. В нашей простой реализации класса KWindow было выбрано другое решение — указатель на экземпляр KWindow хранится в структуре данных, поддерживаемой в операционной системе Windows для каждого окна. WindowProc обычно получает указатель на KWindow во время обработки сообщения WMNCCREATE, которое обычно отправляется перед сообщением WM_CREATE и содержит то же значение указателя на структуру CREATESTRUCT. Указатель сохраняется вызовом SetWindowLong(GWLJJSERDATA) и позднее читается вызовом GetWindowLong(GWLUSERDATA). Так в нашем простом примере организуется связь между WindowProc к KWindow: :WndProc. У традиционных обработчиков сообщений (на базе С) есть существенный недостаток: при необходимости обратиться к дополнительным данным им требуются глобальные данные. При создании нескольких экземпляров окна, использующих общий обработчик сообщений, этот обработчик обычно не работает. Чтобы разные экземпляры окна могли использовать один общий класс окна, каждый экземпляр должен иметь собственную копию данных, доступ с которой осуществляется через общий обработчик сообщений. В классе KWindow эта проблема решена: мы создаем обработчик сообщений C++, который получает доступ к данным экземпляров. Функция KWindow: :CreateEx не передает указатель this непосредственно при вызове функции Win32 CreateWindowEx; вместо этого указатель передается в поле структуры MDICREATESTRUCT. Это необходимо для поддержки многодокументного интерфейса MDI (Multiple Document Interface) с использованием того же класса KWindow. Чтобы создать дочернее окно MDI, приложение посылает клиентскому окну MDI сообщение WM_MDICREATE и передает ему структуру MDICREATESTRUCT. Именно клиентское окно, реализуемое операционной системой, отвечает за итоговый вызов функции создания окна CreateWindowEx. Также следует учитывать, что функция CreateEx регистрирует класс окна и создает окно за один вызов. Каж-
Основы программирования для Windows на C/C++ 41 дый раз, когда требуется создать окно, функция проверяет, не был ли класс зарегистрирован ранее, и регистрирует класс только в случае необходимости. После создания класса KWindow нам уже не придется снова и снова решать задачи регистрации класса, создания окна и организации цикла сообщений — достаточно создать класс, производный от KWindow, и определить в нем только специфические аспекты. Ниже приведена третья версия программы «Hello, World» — вполне обычная программа C++, работающая в оконном режиме. // НеПоЗ.срр #define STRICT #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <assert.h> #include <tchar.h> #include ". Л. .\include\win.h" const TCHAR szMessage[] = JC'Hello. World !"); const TCHAR szFace[] = _T("Times New Roman"); const TCHAR szHint[] = _T("Press ESC to quit."); const TCHAR szProgram[] - _T("HelloWorld3"); // Функция CenterText копируется из Не11о2.срр class KHelloWindow : public KWindow { void OnKeyDown(WPARAM wParam, LPARAM IParam) { if ( wParam—VKJSCAPE ) PostMessage(m_hWnd. WM_CL0SE. 0. 0); } void OnDraw(HDC hDC) { TextOut(hDC, 0. 0. szHint, lstrlen(szHint)); CenterText(hDC. GetDeviceCaps(hDC. H0RZRES)/2. GetDeviceCaps(hDC. VERTRES)/2. szFace, szMessage. 72); } public: }: int WINAPI WinMain(HINSTANCE hlnst. HINSTANCE, LPSTR lpCmd. int nShow) { KHelloWindow win; win.CreateEx(0, szProgram. szProgram, WSJWUP. 0. 0,
42 Глава 1. Основные принципы и понятия GetSystemMetrics( SM_CXSCREEN ). GetSystemMetrics( SM_CYSCREEN ). NULL, NULL, hlnst): win.ShowWi ndow(nShow); win.UpdateWindowO: return win.MessageLoopO; } В этой программе класс KHelloWindow создается как производный от класса KWindow. Виртуальная функция OnKeyDown переопределяется в нем для обработки клавиши Esc, а виртуальная функция OnDraw переопределяется для обработки сообщения WM_PAINT. Главная программа создает в стеке экземпляр класса KHelloWorld, строит полноэкранное окно, отображает его и входит в обычный цикл обработки сообщений. Где же наше сообщение «Hello, World»? Функция OnDraw выводит его в процессе обработки сообщения WM_PAINT. Итак, мы написали на C++ программу для Windows, в которой нет ни одной глобальной переменной. Hello, World, версия 4: вывод средствами DirectDraw Вторая и третья версии «Hello, World» напоминают старые DOS-программы, которые обычно захватывали весь экран и записывали данные прямо в видеопамять. Интерфейс DirectDraw, изначально разработанный компанией Microsoft для программирования быстрой графики в играх, позволяет программам работать на еще более низком уровне, обращаясь к экранному буферу и используя нетривиальные возможности современных видеоадаптеров. Ниже приведена простая программа, в которой вывод осуществляется средствами DirectDraw. // Hello4.cpp #define STRICT #define WIN32_LEAN_AND__MEAN #include <windows.h> #include <assert.h> #include <tchar.h> #include <ddraw.h> #include ". Л..\include\win.h" const TCHAR szMessage[] - _T("Hello. World !'*); const TCHAR szFace[] - _T("Times New Roman"); const TCHAR szHint[] - JCPress ESC to quit."); const TCHAR szProgram[] - J"("HelloWorld4"); // Функция CenterText копируется из Hello2.cpp class KDDrawWindow : public KWindow {
Основы программирования для Windows на C/C++ 43 LPDIRECTDRAW lpdd; LPDIRECTDRAWSURFACE lpddsprimary; void OnKeyDown(WPARAM wParam. LPARAM IParam) { if ( wParam—VKJSCAPE ) PostMessage(m_hWnd. WM_CL0SE. 0. 0); } void Blend(int left, int right, int top. int bottom); void OnDraw(HDC hDC) { TextOut(hDC. 0. 0. szHint. lstrlen(szHint)): CenterText(hDC. GetSystemMetri cs(SM_CXSCREEN) /2. GetSystemMetrics(SM_CYSCREEN)/2. szFace. szMessage. 48); Blend(80. 560. 160. 250); } public: KDDrawWindow(void) { lpdd - NULL; lpddsprimary - NULL; } -KDDrawWindow(void) { if ( lpddsprimary ) { lpddsprimary->Release(); lpddsprimary - NULL; } if ( lpdd ) { lpdd->Release(); lpdd - NULL; } } bool CreateSurface(void); bool KDDrawWindow::CreateSurface(void) { HRESULT hr; hr - DirectDrawCreate(NULL. &lpdd. NULL); if (hr!=DD_0K) return false;
44 Глава 1. Основные принципы и понятия hr = lpdd->SetCooperativeLevel(m_hWnd. DDSCLJULLSCREEN | DDSCLJXCLUSIVE); if (hr!=DD_0K) return false; hr = lpdd->SetDisplayMode(640. 480. 32); if (hr!=DD_0K) return false; DDSURFACEDESC ddsd; memset(& ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; return lpdd->CreateSurface(&ddsd, &lpddsprimary, NULL) ==DD_0K; } void inline Blend(unsigned char *dest. unsigned char *src) { dest[0] - (dest[0] + src[0])/2; dest[l] = (dest[l] + src[l])/2; dest[2] = (dest[2] + src[2])/2; void KDDrawWindow:;BlendCint left, int right, int top. int bottom) { DDSURFACEDESC ddsd; memset(&ddsd. 0. sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); HRESULT hr - lpddsprimary->Lock(NULL. &ddsd. DDLOCKJURFACEMEMORYPTR | DDLOCK_WAIT. NULL); assert(hr==DD_OK); unsigned char *screen - (unsigned char *) ddsd.IpSurface; for (int y=top; y<bottom; y++) { unsigned char * pixel - screen + у * ddsd.lPitch + left * 4; for (int x-left; x<right; x++. pixel+-4) if ( pixel[0]!=255 || pixel[1]'=255 || pixel[2]!-255 ) // He белый цвет { ::Blend(pixel-4. pixel); // Слева ::Blend(pixel+4, pixel); // Справа ;;Blend(pixel-ddsd.lPitch, pixel); // Сверху :;Blend(pixel+ddsd.lPitch, pixel); // Снизу
Основы программирования для Windows на C/C++ 45 } } lpddsprimary->Unlock(ddsd.lpSurface); } int WINAPI WinMainCHINSTANCE hlnst. HINSTANCE, LPSTR lpCmd. int nShow) { KDDrawWindow win: win.CreateEx(0, szProgram, szProgram, WSJWUP. 0. 0. GetSystemMetrics( SM_CXSCREEN ), GetSystemMetrics( SM_CYSCREEN ), NULL. NULL, hlnst); win.CreateSurfaceO; wi n.ShowWi ndow(nShow); win.UpdateWindowO; return win.MessageLoopO; } В этой простой программе с помощью DirectDraw организуется непосредственная запись в экранный буфер. Вероятно, вы заметили, что мы снова воспользовались классом KWi ndow, не добавив ни единой строки кода для создания окна, простейшей обработки сообщений и организации цикла сообщений. При работе с DirectDraw в каждом экземпляре класса KDDrawWindow, производного от KWi ndow, приходится хранить дополнительные данные, а именно указатель на объект DirectDraw и указатель на объект DirectDrawSurface; оба указателя инициализируются при вызове функции CreateSurface. Функция CreateSurface переключает экран в разрешение 640 х 480 с глубиной цвета 32 бит/пиксел и создает одну первичную поверхность DirectDraw. Интерфейсные указатели освобождаются при вызове деструктора. Функция OnDraw выводит небольшое справочное сообщение в левом верхнем углу и большое синее сообщение «Hello, World» в центре экрана; в обоих случаях, как и в предыдущем примере, используются обычные вызовы функций GDI. Впрочем, есть и отличия — после отображения текста вызывается новая функция Blend. В начале своей работы функция KDDrawWindow::Blend фиксирует в памяти экранный буфер и возвращает указатель, по которому можно напрямую работать с памятью экрана. До появления DirectDraw получить прямой доступ к экранному буферу при помощи функций GDI (и даже непосредственно в GDI) было невозможно, поскольку доступ находился под контролем драйверов графических устройств. В нашем примере используется режим с цветовой глубиной 32 бит/пиксел, поэтому каждый пиксел занимает в памяти 4 байта. Адрес пиксела в памяти вычисляется по следующей формуле: pixel = (unsigned char *) ddsd.lpSurface + у * ddsd.lPitch + left * 4;s
46 Глава 1. Основные принципы и понятия Функция сканирует прямоугольную область экрана сверху вниз и слева направо и ищет в ней пикселы, цвет которых отличен от белого (фон окрашен в белый цвет). При обнаружении не белого пиксела его цвет размывается по отношению к соседям, расположенным слева, справа, сверху и снизу. В результате размывания пикселу присваивается значение, равное среднему арифметическому значений двух пикселов. На рис. 1.1 изображен результат плавного размывания надписи «Hello, World!» на белом фоне. Hello, Wwta I Рис. 1.1. Размывание текста средствами DirectDraw Если вы еще никогда не работали с DirectDraw API, не огорчайтесь. Эта тема подробно рассматривается в главе 18. Ассемблер Все мы любим подниматься вверх — в социальном и даже в техническом смысле. Представители нашей профессии давно перешли от программирования в машинных кодах на C/Win32 API, C++/MFC, Java/AWT (Abstract Window Toolkit - классы для построения графического пользовательского интерфейса на Java)/ JFC (Java Foundation Classes — новая библиотека классов пользовательского интерфейса, превосходящая AWT по своим возможностям), и лишь некоторым невезучим личностям приходится создавать связи между абстрактными языками и машинным уровнем. Прогресс — вещь хорошая, печально другое. Делая очередной шаг вперед, мы быстро привыкаем к нему как к единственно возможному стандарту и забываем все, что было раньше. В наши дни уже никто не удивляется, когда книги по Visual C++ ограничиваются описанием MFC, а программисты спрашивают: «А как это сделать на MFC?» С каждым новым уровнем абстракции появляется новый промежуточный уровень взаимодействия программы с компьютером. Реализация нового уровня должна опираться на возможности более низких уровней — а самом низким уровнем в конечном счете является ассемблер. Даже если вы не принадлежите к узкому кругу системных программистов, глубокое понимание языка ассемблера обеспечит немалые преимущества в вашей профессиональной деятельности. При помощи ассемблера можно отлаживать программы и разбираться в принципах работы операционной системы (представьте, что у вас возникло исключение в kernel32.dll). Ассемблер поможет оптимизировать программу и добиться от нее максимального быстродействия. Ассемблер предоставляет в ваше распоряжение средства процессора, обычно недоступные в языках высокого уровня, — например, инструкции процессора, относящиеся к технологии Intel MMX (Multimedia Extensions).
Ассемблер 47 В этой книге будет рассматриваться ассемблер для процессоров Intel. Возможно, в будущих изданиях внимание будет уделено и другим процессорам. За основными сведениями о процессорах Intel обращайтесь к документу «Intel Architecture Software Developer's Manual», находящемуся на web-странице разработчиков (developer.intel.com). В дальнейшем предполагается, что вы имеете хотя бы базовое представление о процессорах семейства Intel и языке ассемблера. Обычно считается, что 16-разрядные программы работают в режиме 16-разрядной адресации, а 32-разрядные программы — в режиме 32-разрядной адресации. На процессорах Intel это неверно; и 16-, и 32-разрядные программы работают в 48-разрядном режиме логической адресации. При каждом обращении к памяти указывается 16-разрядный адрес сегмента и 32-разрядное смещение. Таким образом, логический адрес состоит из 48 бит. Процессоры Intel работают в 16- и 32-разрядном режимах. В 16-разрядном режиме максимальная длина сегмента равна 64 Кбайт, а в указателях на код и данные по умолчанию используются 16-разрядное смещение. В 32-разрядном режиме длина сегмента ограничивается значением 4 Гбайт, а в указателях на код и данные по умолчанию используется 32-разрядное смещение. Впрочем, разрядность инструкции можно изменить при помощи префикса (0x66 для операнда, 0x67 для адреса). Этот прием позволяет в 16-разрядном режиме работать с 32-разрядными регистрами, или наоборот, обращаться к 16-разрядным регистрам в 32-разрядном режиме. Режимы процессора Intel не следует путать с модулями EXE/DLL в мире Windows. Windows EXE/DLL может содержать комбинацию 16- и 32-разрядных модулей. Если вы работаете в Windows 95, загляните в файл dibeng.dll — эта 16-разрядная библиотека содержит 32-разрядные сегменты, чтобы обеспечить 32-разрядное быстродействие. Различия между 16- и 32-разрядным кодом существуют и в способе адресации. В 16-разрядных программах обычно используется сегментированная модель памяти, при которой адресное пространство делится на сегменты. Для 32-разрядных программ характерна сплошная (flat) адресация, при которой все адресное пространство рассматривается как один 4-гигабайтный сегмент. В процессах Win32 сегментные регистры процессора CS (Code Segment — сегмент кода), DS (Data Segment — сегмент данных), SS (Stack Segment — сегмент стека) и ES (Extra Segment — дополнительный сегмент) отображаются на один и тот же виртуальный адрес 0. Одним из преимуществ сплошной адресации является то, что мы можем легко сгенерировать фрагмент машинного кода в массиве данных и вызвать его как функцию. В программе Win 16 для этого пришлось бы отображать сегмент данных на сегмент кода, используя значение последнего и смещение для работы с кодом в сегменте данных. Поскольку все четыре основных сегментных регистра отображаются на одинаковый виртуальный адрес 0, программа Win32 обычно использует в качестве полного адреса только 32-разрядное смещение. Однако на уровне ассемблера сегментный регистр может комбинироваться со смещением для образования 48-разрядного адреса. Например, сегментный регистр FS, который также является регистром сегмента данных в процессорах Intel, не отображается на виртуальный адрес 0. Вместо этого он отображается на начальный адрес структуры данных программного потока (thread), поддерживаемой операционной системой; через эту структуру функции Win32 API работают с важной информацией уровня программного потока —
48 Глава 1. Основные принципы и понятия кодом последней ошибки (функции SetLastError/GetLastError), цепочкой обработчиков исключений, локальными данными потока и т. д. На ассемблерном уровне при вызове функций Win32 API используется стандартная схема передачи параметров, то есть параметры заносятся в стек справа налево. Следовательно, вызов функции окна из цикла обработки сообщений unsigned rslt = WindowProc(hWnd. uMsg. wParam. IParam); преобразуется в следующий фрагмент на ассемблере: mov push mov push mov push mov push call mov eax. eax eax, eax eax, eax eax, eax IParam wParam uMsg hWnd WindowProc rslt , eax Из возможностей процессоров Intel Pentium, недоступных на уровне C/C++, следует упомянуть одну инструкцию, которая представляет особый интерес для программистов, занятых оптимизацией своих программ. Речь идет об инструкции RDTSC (Read Time Stamp Counter). Эта инструкция возвращает количество тактов с момента запуска процессора в виде 64-разрядного целого без знака. Число возвращается в паре регистров общего назначения EDX и ЕАХ. Это означает, что на Pentium с частотой 200 МГц выполнение программы можно замерять с точностью до 5 не в течение 117 лет. На данный момент инструкция RDTSC не поддерживается в Visual C++ даже на уровне встроенного ассемблера, хотя оптимизатор, похоже, понимает, что при ее использовании изменяется содержимое регистров EDX и ЕАХ. Чтобы воспользоваться этой инструкцией, следует вставить в программу ее машинное представление OxOF, 0x31. Ниже приведен исходный текст класса-таймера, использующего инструкцию RDTSC. // Timer.h #pragma once inline unsigned _int64 GetCycleCount(void) { _asm _emit OxOF _asm _emit 0x31 } class KTimer { unsigned _int64 m_startcycle public: unsigned _int64 m_overhead;
Ассемблер 49 KTimer(void) { m_overhead = 0; StartO; m_overhead - StopO; } void Start(void) { m_startcycle - GetCycleCountO; } unsigned _int64 Stop(void) - { return GetCycleCount()-m_startcycle-m_overhead; } }: Класс KTimer хранит данные хронометража в виде 64-разрядного числа, поскольку 32-разрядная версия на компьютере с процессором в 200 мегагерц обеспечивает слишком низкую точность. Функция GetCycl eCount возвращает текущее количество тактов в виде 64-разрядного числа без знака. Результат, сгенерированный инструкцией RDTSC, соответствует формату 64-разрядного возвращаемого значения функций С. Таким образом, функция GetCycleCount представляет собой одну машинную инструкцию. Функция Start читает количество тактов в начале интервала; функция Stop останавливает хронометраж и возвращает разность. Чтобы повысить точность измерений, необходимо учесть время, потраченное на выполнение функций RDTSC. Для этого конструктор класса KTimer запускает и останавливает таймер. Полученная величина вычитается из результатов последующих измерений. В приведенном ниже примере класс KTimer используется для измерения количества тактов и времени, необходимого для создания однородной кисти. // GDISpeed.cpp #define STRICT #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <tchar.h> #include ".Л..\include\timer.h" int WINAPI WinMain(HINSTANCE hlnst. HINSTANCE, LPSTR IpCmd. int nShow) { KTimer timer; TCHAR mess[128]; timer.StartO; Sleep(lOOO); unsigned cpuspeedlO = (unsigned)(timer.Stop()/100000); timer.StartO;
50 Глава 1. Основные принципы и понятия CreateSolidBrush(RGB(OxAA. OxAA. OxAA)); unsigned time - (unsigned) timer.StopO; wsprintf(mess, JTCPU speed *d.*d mhz\n") _T("«Timer overhead *d clock cycles\n") JTCreateSoUdBrush *d clock cycles *d ns"). cpuspeedlO / 10, cpuspeedlO % 10. (unsigned) timer.m_overhead, time, time * 10000~7 cpuspeedlO); MessageBox(NULL. mess, JC'How fast is GDI?"), MB_0K); return 0; } Результаты измерений выводятся в окне сообщения (рис. 1.2). Теперь можно с уверенностью сказать, что создание однородной кисти на компьютере с процессором Pentium 200 МГц занимает около 40 микросекунд. Рис. 1.2. Хронометраж с использованием инструкции RDTSC процессоров Intel Среда программирования Существует немало составляющих, необходимых для эффективного программирования в среде Microsoft Windows, — компьютеры, вспомогательные программы, книги, документация, обучающие курсы, информация в Интернете и опытные друзья. На первый взгляд этот список выглядит устрашающе, но для начала достаточно и малой части перечисленного. Остальное понадобится для программирования более сложных задач или повышения эффективности вашей работы. По сравнению со старыми средами программирования для DOS или 16-разрядных версий Windows, 32-разрядная среда Windows стала большим шагом вперед. Разработка и тестирование Компьютер, используемый для программирования в наши дни, должен отвечать следующим минимальным требованиям: Pentium 200 МГц с 64 Мбайт памяти, устройство для чтения компакт-дисков, 8 Гбайт свободного места на диске и сетевое подключение.
Среда программирования 51 Быстрый процессор ускоряет работу компилятора и компоновщика по превращению исходного текста в двоичный код (впрочем, у этого есть и отрицательная сторона — вы теряете хороший повод для того, чтобы отлучиться от компьютера и выпить кофе). Для использования новых инструкций (таких, как RDTSC) необходим процессор не ниже Intel Pentium или одной из совместимых моделей. Рекомендуется процессор Pentium Pro, Celeron, Pentium III или их аналоги с большим количеством инструкций, аппаратных оптимизаций и увеличенным кэшем. Если вы (или ваш начальник) можете себе это позволить, работайте на компьютере с двумя процессорами. Это позволит убедиться в том, что ваша программа не будет «тормозить» на двухпроцессорных компьютерах — например, из-за того, что разные потоки выделяют память из одной системной кучи (heap). Возможно, объем оперативной памяти является еще более важным фактором, чем скорость процессора. При работе на компьютере с 16 или 32 Мбайт памяти системная память будет все время переполнена, и процессору придется тратить такты на выгрузку неактивных и подкачку (swapping) активных страниц. В результате скорость работы система начинает зависеть от скорости обращения к диску. С возрастанием объема компиляторов, SDK (Software Development Kit) и DDK (Device Driver Kit) важную роль начинает играть свободное место на диске. Средства разработчика поставляются в комплекте с большими справочными файлами, заголовочными файлами и примерами программ. Компилятор расходует много места на построение предварительно откомпилированных заголовочных файлов, файлов с символической информацией для отладки и баз данных для просмотра объектов. Вы можете легко обратиться к какой-нибудь web-странице и загрузить с нее всевозможные утилиты или документацию. Кроме того, операционная система выгружает на жесткий диск содержимое оперативной памяти. Сетевое подключение необходимо для совместного использования и архивации данных. Для работы отладчика WinDbg, работающего на уровне ядра, необходимы два компьютера, соединенных последовательным или сетевым кабелем. Системы контроля версии и отслеживания дефектов обычно работают по сети. Для отладки драйверов уровня ядра в отладчике WinDbg вам понадобятся два компьютера; на одном будет работать отлаживаемая программа, а на другом — программа-отладчик. В главе 3 будет показано, как использовать DLL расширения отладчика WinDbg на одном компьютере для просмотра внутренних структур данных Windows NT/2000 GDI. На рабочем компьютере рекомендуется установить операционную систему Windows NT 4.0 или Windows 2000 (вместо Windows 95 или Windows 98). Платформы Microsoft Windows NT 4.0 и Windows 2000 все увереннее занимают лидирующее место среди операционных систем. По ним публикуется все больше книг, а существующий инструментарий постоянно расширяется. Кроме рабочего компьютера (или компьютеров), вам понадобятся компьютеры для тестирования (или по крайней мере временный доступ к ним). Вы пишете свои программы для пользователей Windows 95/98/NT/2000. Следовательно, вы должны убедиться в том, что они нормально работают в каждой из этих систем. Программы, для которых важно быстродействие, также необходимо протес-
52 Глава 1. Основные принципы и понятия тировать в разных конфигурациях. Бывает, что в результате оптимизации на процессоре Pentium II код начинает работать вдвое быстрее, но на Pentium трехлетней давности его работа замедляется. Компиляторы Рабочий компьютер — это еще не все. Вам также потребуется компилятор, преобразующий программу на языке программирования в машинное представление. Впрочем, современные компиляторы не ограничиваются этой функцией. Они представляют собой интегрированные среды программирования, в которые входит редактор, автоматически выделяющий синтаксические конструкции, заголовочные файлы, исходные тексты библиотек и двоичные файлы, справочную документацию, компилятор, компоновщик, отладчик, работающий на уровне исходных текстов, программы-мастера (wizards), компоненты и другие вспомогательные средства. Если вы программируете исключительно на уровне Win32 API, то в вашем распоряжении оказывается несколько вариантов: Microsoft Visual С-»--»-, Borland С-»--»-, Delphi, Microsoft Visual Basic и т. д. Но если вы хотите писать программы с использованием Windows NT/2000 DDK, особого выбора нет — вам потребуется компилятор Microsoft Visual С-»--»-. В настоящее время существует несколько версий компилятора Microsoft Visual С-»--»-. Обычно на рабочем компьютере устанавливается последняя версия компилятора с последней версией Service Pack — в них реализуются новые возможности и усовершенствования, а также исправляются найденные ошибки (впрочем, обновление иногда откладывается из-за возможных проблем с совместимостью). Примеры программ в этой книге откомпилированы в среде Microsoft Visual C++ версии 6.0. Если вы захотите воспользоваться более ранней версией, возможно, при загрузке файлов рабочей области и проектов будут выдаваться предупреждения. Наряду с операционной системой и компилятором вам также понадобятся некоторые вспомогательные средства, о которых обычно вспоминают лишь тогда, когда в них возникает необходимость. Символическая отладочная информация Windows NT/2000 помогает разобраться в том, как система работает и как она способствует обнаружению ошибок, проявляющихся только в системном коде. Наконец, бывает просто интересно узнать, какие символические имена используются в исходных текстах Microsoft. На компакт-диске VC6.0 в каталоге \vc60\vc98\debug находятся символические файлы для некоторых важных системных библиотек DLL — таких, как gdi32.dll, user32.dll и т. д. Полный набор символических отладочных файлов присутствует на компакт-диске Windows NT/2000 в каталоге \support\debug. В новых версиях Windows 2000 размер файлов с символической информацией увеличился настолько, что Microsoft пришлось разместить их на отдельном компакт-диске со вспомогательными инструментами. При установке символических файлов следует проверить тип процессора (i386 или alpha), тип и номер сборки. Они должны точно соответствовать параметрам той операционной системы, в которой производится отладка. Наличие символической информации для системных модулей является достаточно веской причиной для переноса разработок из
Среда программирования 53 Windows 95/98 в Windows NT/2000. После этого вы сможете чаще использовать в отладчике Visual C++ команду контекстного меню Go To Disassembly и не прогадаете. Например, можно установить точку прерывания при вызове Create- SolidBrush и перейти в режим ассемблера. Вместо неудобочитаемого шестнадца- теричного адреса отладчик Visual C++ покажет символическое имя CreateSolid- Brush@4. Становится видно, что функция получает 4 байта параметров, или просто одну 32-разрядную величину. Несколькими строками ниже находится вызов _CreateBrush@20; при вызове этой функции передаются 5 параметров. Таким образом, GDI объединяет вызовы специализированных функций API в более общие вызовы. Прослеживая цепочку вызовов, мы приходим к функции NtGdi Create- SolidBrush@8, вызывающей программное прерывание 0х2Е. Если вы захотите войти в обработчик прерывания, отладчик Visual C++ не позволит этого сделать. Итак, для создания однородной кисти GDI обращается к коду win32k.sys, работающему в режиме ядра. Чтобы разобраться в происходящем, совсем не нужно быть экспертом в области ассемблера — отладочные символические имена напоминают дорожные знаки, по которым вы ориентируетесь в пути. На рис. 1.3 показан пример использования отладочных символических файлов в отладчике Visual C++. *&ж Ш&ж,;. *ШМ _Crea t eSo1i dBrush@ 4: jj Ф 7 ?F4 2 0 % 9 ко г еа.х. ec<x 77F4205B push eax 7 7 F 4 2 0 5 С ризЬ eax 7 7 F 4 2 0 5 D pu-sh ea.x 77F4205E push dword ptr [esp+lOh] 77F42062 push eax * 77F42063 call CreateBrush»«20 (77f 41f ^b) 77F42068 ret 4 LNtGdiCreateSolidBrush@8: 77F42 0bB &ov «a.x , 1 02 kh 77F42070 lea edK.[esp+4] 77F42074 mt 2Eh 77F42076 ret 8 t JLwwimwwwMMwmwwwmJ ***** Я& Рис. 1.З. Использование символической информации в процессе отладки В компиляторах Microsoft существует два варианта хранения отладочной информации. В старом формате для каждого модуля создается один файл с расширением .dbg. В новом формате используются два файла с расширениями .dbg и .pdb. Ссылка на файл .dbg хранится в двоичном файле модуля. Например, gdi32.dll ссылается на файл dll\gdi32.dll в соответствующем отладочном каталоге. По этой ссылке отладчик загружает файл $SystemRoot$\symbols\dll\gdi32.dbg. Отладчик — не единственный инструмент, умеющий работать с символической информацией. Более того, он ничего не делает сам. Загрузка отладочной информации и обработка запросов осуществляется через специальный интер-
54 Глава 1. Основные принципы и понятия фейс (Image Help API) — простое модульное решение. Все программы, использующие этот интерфейс, смогут получить ту же информацию. К числу таких программ относится утилита dumpbin, но это может быть и ваша собственная программа. Утилита просмотра связей (depends.exe) перечисляет все DLL, импортируемые вашим модулем, в удобной рекурсивной форме. Это помогает получить четкое представление о том, сколько модулей загружается во время работы программы и сколько функций импортируется. Проверьте работу этой утилиты на простой программе MFC; вы будете поражены тем, сколько функций импортируется без вашего ведома. При помощи этой утилиты можно определить, будет ли программа работать в исходной версии Windows 95, которая не имела системных DLL типа urlmon.dll и экспортировала меньше функций в ole32.dll. Microsoft Spy++ (spyxx.exe) — удобная, мощная утилита для получения информации о работе Windows, о сообщениях, процессах и программных потоках. Если во время работы программы вы вдруг захотите узнать, из каких элементов состоит стандартное диалоговое окно (типа File Open) или почему не отправляется какое-нибудь сообщение, которое вы ожидаете, — попробуйте воспользоваться утилитой Microsoft Spy++. Простая и полезная утилита WinDiff (windiff.exe) позволяет сравнить две версии исходного файла или содержимое двух каталогов. Кроме того, она поможет найти различия между оригинальной и локализованной версиями ресурсных файлов. Крошечная текстовая программа pstat.exe выводит сведения о процессах, потоках и модулях, работающих в вашей системе. В ее выходных данных перечисляются все процессы и потоки с указанием времени, проведенным за выполнением кода в режиме пользователя и в режиме ядра, данных о рабочих наборах и счетчика ошибок страниц. В конце списка pstat перечисляет все системные DLL и драйверы устройств, загруженные в адресное пространство режима ядра; для каждого модуля указывается имя, адрес, размер кода и данных, а также строка версии. Обратите внимание, что реализация механизма GDI win32k.sys загружается по адресу ОхаООООООО, драйвер экрана загружается по адресу 0xfbef7000 и т. д. Утилита Process Viewer (pview.exe) выводит информацию о процессах в графическом виде. В частности, она показывает, сколько памяти выделено для каждого модуля в процессе. В инструментарий Visual Studio входят также другие полезные программы: dumpbin.exe для просмотра файлов в формате РЕ, profile.exe для простейшего измерения быстродействия, nmake.exe для компиляции с использованием make- файла, и rebase.exe для изменения базового адреса модуля (чтобы избежать затрат на его перемещение в памяти во время работы программы). Иногда вам придется просматривать заголовочные файлы, которые на первый взгляд кажутся скучными и непривлекательными. Кое-кто полагает, что заголовочные файлы создаются не для людей, а для компиляторов. Что ж, это действительно так. Но дело в том, что компьютер — очень точный и педантичный инструмент. Он беспрекословно подчиняется содержимому заголовочных файлов и ничего не знает о том, что говорится в документации или в книгах для программистов. Бывает, что документация содержит ошибки, и тогда за оконча-
Среда программирования 55 тельным ответом приходится обращаться к заголовочным файлам. Взгляните на определение TBBUTTON, приведенное в электронной документации. Эта структура состоит из 6 полей, не так ли? Но если вы определите структуру с 6 полями, компилятор выдаст сообщение об ошибке. А теперь загляните в заголовочный файл commctrl.h — оказывается, структура TBBUTTON содержит дополнительное двухбайтовое зарезервированное поле, то есть состоит из 7 полей. По заголовочным файлам можно проследить за тем, как макрос STRICT влияет на компиляцию, как версии функций API с поддержкой Unicode и без нее отображаются на экспортированные функции, сколько новых возможностей появилось в Windows 2000 и т. д. Если уж вы справитесь с заголовочными файлами, то читать исходные тексты будет намного интереснее. Чтение исходных текстов runtime-библиотеки С абсолютно необходимо — из них вы узнаете, как начинается и завершается работа вашего модуля и какие операции выполняются с памятью в системной куче при вызове malloc/free и new/delete. Кроме того, вы узнаете, почему в некоторых ситуациях встроенная версия memcpy работает медленнее, чем вызов внешней функции. Исходные тексты MFC довольно интересно читать и выполнять в пошаговом режиме. Особенно важна часть, связанная с обработкой сообщений, поскольку она объединяет C++ с пакетом Win32 SDK, ориентированным на С. Исходные тексты ATL (Active Template Library) сильно отличаются от исходных текстов MFC. Обязательно просмотрите класс CWndProcThunk, в котором переход от С к C++ осуществляется несколькими машинными инструкциями. В Microsoft Visual Studio поддерживается немало других полезных возможностей. Например, из меню File можно открыть HTML-страницу с цветовым выделением синтаксических элементов или открыть исполняемый файл для просмотра его ресурсов. Меню Edit позволяет производить поиск текста в разных режимах, а также устанавливать точки прерывания в определенных позициях программы, при обращениях к данным или получении сообщений. Команды меню Project позволяют сгенерировать листинг программы на ассемблере или подключить отладочную информацию к окончательной версии программы. При помощи команд меню Debug можно потребовать, чтобы программа прерывалась при возникновении определенных исключений, а также просмотреть список загруженных модулей. Microsoft Platform SDK Microsoft Platform SDK (Software Development Kit) представляет собой набор SDK для интеграции процесса разработки с существующими и развивающимися технологиями Microsoft. Этот пакет является наследником Win32 SDK и включает в себя BackOffice SDK, ActiveX/Internet Client SDK и DirectX SDK. Но самое ценное — то, что Microsoft Platform SDK распространяется бесплатно и регулярно обновляется. На момент написания книги Microsoft Platform SDK и другие SDK распространялись по адресу: http://msdn.microsoftxom/downloads/sdks/platform/platform.asp Итак, что же входит в SDK? Platform SDK содержит огромную подборку заголовочных файлов, библиотек, электронных документов, утилит и примеров
56 Глава 1. Основные принципы и понятия программ. Даже если у вас уже есть компилятор Microsoft Visual C++, установка последней версии Platform SDK все равно принесет пользу. Например, если к вашему компилятору прилагаются устаревшие версии заголовочных файлов и библиотек, вы не сможете пользоваться новыми функциями API, появившимися в Windows 2000. Проблема решается загрузкой Platform SDK и подключением новых заголовочных файлов и библиотек к компилятору. Можно сказать, что Microsoft Visual Studio — это интегрированный набор инструментов для разработки программ Win32 на базе компилятора Microsoft Visual C++, a Platform SDK — обширная коллекция инструментов для разработки программ Win32 с использованием внешнего компилятора C/C++. В Microsoft Visual C++ центральное место занимает компилятор C++ с runtime-библиотеками C/C++, ATL и MFC. В Platform SDK не входит ни компилятор, ни заголовочные файлы для функций C/C++, ни runtime-библиотеки. Это позволяет независимым фирмам работать с альтернативными компиляторами C/C++, заголовочными файлами и библиотеками, используя вместо решений Microsoft другую рабочую среду, — и даже программировать на Pascal, если вам удастся перевести заголовочные файлы Windows API в формат Pascal. Чтобы откомпилировать любую программу из Platform SDK, необходимо заранее установить компилятор и минимальный набор runtime-библиотек С. В Platform SDK входят десятки утилит, часть из которых присутствует и в Visual Studio. Программа qgrep.exe предназначена для поиска текста в режиме командной строки (по аналогии с командой Visual Studio Find in Files). Довольно мощная программа-монитор API (apimon.exe) работает как специализированный отладчик. Она загружает программу, перехватывает вызовы функций Windows API, регистрирует их с пометкой времени, а также трассирует параметры и возвращаемые значения. В непредвиденных ситуациях монитор API открывает окно DOS, в котором можно дизассемблировать программу, просмотреть содержимое регистров, установить точки прерывания и выполнить программу в пошаговом режиме. Программа memsnap.exe выдает сведения об использовании памяти работающими процессами, в частности о размере рабочего набора и об использовании памяти ядра. Утилита pwalk.exe выводит подробную информацию о расходовании процессом виртуальной памяти в пользовательском адресном пространстве. Программа показывает, каким образом пользовательское адресное пространство делится на сотни блоков, и сообщает основные параметры каждого блока (состояние, размер, имя секции и модуля). При двойном щелчке в строке списка выводится шестнадцатеричный дамп соответствующего блока. Программа sc (sc.exe) обеспечивает интерфейс командной строки для диспетчера служб (service control manager). Исключительно полезная программа просмотра объектов (winobj.exe) позволяет просматривать все активные объекты системы в виде иерархического дерева. К числу таких объектов относятся события, мыотексы, каналы, файлы, отображаемые на память, драйверы устройств и т. д. Например, в категории устройств присутствует строка PhysicalMemory — драйвер устройства для работы с физической памятью. Следовательно, для создания манипулятора блока физической памяти можно воспользоваться командой вида: HANDLE hRAM = CreateFileC'WW.WPhysicalMemory",...);
Среда программирования 57 Но самое интересное в Platform SDK — это, конечно, коллекция программ- примеров (если вас не пугает чтение старомодных Windows-программ, написанных на С). Вы не встретите в примерах C++, MFC, ATL или интенсивного применения runtime-функций С. Даже примеры СОМ и DirectX написаны на С, и вместо виртуальных функций C++ в них используются таблицы указателей на функции. Также в этом разделе приведены исходные тексты нескольких утилит SDK, в том числе windiff и spy. Читая эти программы, помните, что они были написаны в начале 90-х годов, причем большинство из них создавалось для Winl6 API. В этих примерах часто встречаются места, которые можно покритиковать за плохой стиль программирования — низкий уровень модульности кода, злоупотребление глобальными переменными, недостаточная проверка ошибок и явное влияние на Winl6 API. И все же из этих примеров можно вынести немало полезного. В табл. 1.1 перечислены некоторые программы, связанные с тематикой книги. Таблица 1.1. Примеры программ Platform SDK, относящиеся к графике Путь к программе Краткое описание программы \graphics\directx \graphics\gdi\complexscript \graphics\gdi\fonts \graphics\gdi\metafile \graphics\gdi\printer \graphics\gdi\setdisp \graphics\gdi\showdib \graphics\gdi\textfx \graphics\gdi\wincap32 \graphics\gdi\winnt\plgblt \graphics\gdi\winnt\wxform \graphics\gdi\video\palmap \sdktools\aniedit \sdktools\fontedit \sdktools\Jmage\drwatson \sdktools\imageedit \sdktools\winnt\walker Два мегабайта примеров DirectX Вывод сложных текстов на арабском, тайском и иврите Многосторонняя демонстрация шрифтовых функций API Загрузка, отображение, редактирование и печать расширенных метафайлов Функции печати, линии, перья, кисти Динамическое переключение разрешения экрана Обработка аппаратно-независимых растров Применение эффектов к тексту Сохранение экрана, перехватчики (hooks) Применение функции PlgBlt Демонстрация мировых преобразований Преобразование формата видеоданных (DIB) Редактор анимационных указателей мыши Редактор растровых шрифтов Программа DrWatson. Демонстрирует работу с символической таблицей, дизассемблирование, простую отладку, просмотр списка процессов, просмотр стека, создание аварийных дампов и т. д. Простой редактор растровых изображений Просмотр пространства виртуальной памяти процесса Продолжение &
58 Глава 1. Основные принципы и понятия Таблица 1.1. Продолжение Путь к программе Краткое описание программы \winbase\debug\deb Пример отладчика Win32 \winbase\debug\wdbgexts Пример расширения отладчика Win32 \winbase\winnt\service Функции API для работы со службами Ах, да! До сих пор не упомянут самый полезный инструмент Platform SDK — многооконный отладчик WinDbg, работающий на уровне исходных текстов. В отличие от встроенного отладчика Visual Studio, WinDbg может функционировать в Windows NT/2000 при отладке как пользовательских программ, так и кода, работающего в режиме ядра. Чтобы использовать его в качестве отладчика режима ядра, необходимо связать два компьютера последовательным или сетевым кабелем. Кроме того, WinDbg позволяет просматривать аварийные дампы. WinDbg более подробно рассматривается в главе 3. Если уж речь зашла об утилитах, обратите внимание на профессиональный инструментарий компании Numega. Программа BoundsChecker проверяет вызовы функций API, обнаруживая утечку памяти и ресурсов. Великолепный отладчик SoftICE/W обеспечивает отладку как в пользовательском режиме, так и в режиме ядра, поддерживает 16- и 32-разрядный код — и все это на одном компьютере. Он позволяет в пошаговом режиме перейти из кода пользовательского режима в код режима ядра, а потом вернуться обратно. Профайлер TrueTime предназначен для поиска секций кода, снижающих быстродействие программы. Наконец, vTune и компилятор C++ от компании Intel предназначены для тех, кто хочет добиться от программы максимального быстродействия и воспользоваться расширенными инструкциями Intel MMX и SIMD (Single Instruction Multiple Data). Microsoft Driver Development Kit Пакеты Microsoft Visual C++ и Platform SDK ориентируются на написание обычных программ пользовательского уровня — таких, как WordPad или даже Microsoft Word. Однако для работы операционной системы (особенно при большом количестве устройств — жестких дисков, видеоадаптеров, принтеров и т. д.) необходимы программы другого типа — драйверы устройств. Драйверы устройств загружаются в адресное пространство ядра. Вместе с функциями Win32 API становятся недоступными и структуры данных Win32 API. Они заменяются вызовами системных функций ядра и интерфейсами драйверов устройств. Для написания драйверов устройств в Windows необходим пакет Microsoft Driver Development Kit, бесплатно распространяемый компанией Microsoft (существуют DDK для Windows 95/98/NT4.0/2000): http://www.microsoft.com/ddk/ DDK, как и Platform SDK, представляет собой огромный набор заголовочных и библиотечных файлов, электронной документации, утилит и примеров программ. В DDK входят заголовочные файлы как для функций Win32 API, так и для драйверов устройств. Например, в файле wingdi.h документируются
Среда программирования 59 функции Win32 GDI API, а в файле winddi.h — интерфейс между механизмом GDI и драйверами экрана или принтера. В примерах DirectDraw файл ddraw.h документирует функции DirectDraw API, а файл ddrawint.h определяет интерфейс драйвера DirectDraw в Windows NT. Библиотечные файлы делятся по типу сборки на две категории: свободные (free) и проверяемые (checked). В DDK также входят библиотеки импортируемых функций для системных DLL ядра — например, win32k.lib для win32k.sys. В каталоге help находятся подробные спецификации интерфейсов драйверов устройств и рекомендации по разработке драйверов. Несомненно, каталоги с исходными текстами примеров имеют особую ценность. Например, 'каталог \src\video\displays\s3virge содержит свыше 2 Мбайт исходных текстов драйверов s3 VirGE для поддержки GDI, DirectDraw и трехмерной графики. ПРИМЕЧАНИЕ Разработка драйверов устройств не относится к теме этой книги — на рынке уже есть несколько хороших книг, посвященных разработке драйверов. Но в этих книгах основное внимание обычно уделяется драйверам общего назначения — таким, как драйверы ввода-вывода и драйверы файловой системы. В этой книге подробно рассматриваются вопросы программирования графики в Windows. Мы разберемся с тем, как механизм GDI реализует вызовы функций GDI/DirectDraw и в конечном счете передает их драйверам устройств. Следовательно, к нашей теме относятся драйверы экрана (включая поддержку DirectDraw), шрифтовые драйверы и драйверы принтеров. Кроме того, драйверы режима ядра позволяют обойти API пользовательского режима и сделать что-то такое, что не делается средствами Win32 API. В главе 3 показано, как простой драйвер режима ядра помогает анализировать работу механизма GDI. Исполняемый код в DDK, как и в Platform SDK, строится при помощи внешнего компилятора С. В DDK включена утилита построения проектов (build.exe), упрощающая процесс построения драйверов. Она строит целую иерархию исходных текстов для разных платформ. Вероятно, при наличии исходных текстов build.exe сможет построить целую операционную систему в режиме командной строки. При построении драйверов устройств используются особые параметры компилятора и компоновщика, не поддерживаемые в Microsoft Visual C++. Таким образом, драйверы устройств удобнее всего строить в режиме командной строки. В DDK входят и другие утилиты. Программа break.exe, работающая в режиме командной строки, подключает отладчик к процессу. Мастер настройки отладчика (dbgwiz) помогает настраивать WinDbg. Утилита gflags позволяет изменить значения десятков системных флагов. Например, вы можете включить режим пометки выделяемых блоков памяти данными владельца, чтобы обнаруживать утечку памяти. Программа poolmon.exe следит за выделением/освобождением памяти ядра. Программа regdmp выводит содержимое реестра в текстовый файл. Microsoft Developer Network Microsoft Developer Network (MSDN) — огромный архив справочной информации для программистов Microsoft Windows. MSDN содержит несколько гигабайт документации, технических статей, примеров программ, статей из журналов, книг,
60 Глава 1. Основные принципы и понятия спецификаций и вообще всего, что может понадобиться при программировании для Microsoft Windows, в том числе документацию для Platform SDK, DDK, Visual C++, Visual Studio, Visual Basic, Visual J++ и т. д. * MSDN содержит практически все, что (по мнению Microsoft) необходимо знать при программировании для Windows. Новые версии Microsoft Visual Studio используют MSDN в качестве справочной системы, что сопряжено с немалыми затратами дискового пространства. В табл. 1.2 перечислены компоненты MSDN, относящиеся к программированию графики в Windows. Таблица 1.2. Основные компоненты MSDN, относящиеся к программированию графики Platform SDK\Graphics and Multimedia Services\Microsoft DirectX Platform SDK\Graphics and Multimedia Services\GDI DDK Documentation\Windows 2000 DDK\Graphics Drivers Время от времени вам будут встречаться ссылки на материалы MSDN. Если вы читаете эту книгу без доступа к MSDN, желательно распечатать содержимое перечисленных секций. Помимо трех больших блоков документации SDK/DDK, MSDN содержит немало полезной информации по программированию графики в Windows в виде технических статей, статей Knowledge Base, спецификаций и т. д. При чтении этих материалов необходимо обращать внимание на дату написания и платформу, для которой они были написаны, поскольку полезная информация хранится вперемежку с устаревшим хламом. Частичный список статей приведен в табл. 1.3. Таблица 1.3. Дополнительные компоненты MSDN, относящиеся к программированию графики Specifications\Applications\True Type Font Specification Specifications\Platforms\Microsoft Portable Executable and Common Object Form Specification Specifications\Technologies and Languages\The UniCode Standard, Version 1.1 Technical Articles\Multimedia\Basics of DirectDraw Game Programming Technical Articles\Multimedia\Getting Started with Direct3D:A tour and Resource Guide Technical Articles\Multimedia\Texture Wrapping Simplified Technical Articles\Multimedia\GDI\*.* (десятки полезных статей) Technical Articles\Windows Platform\Memory\Give Me a Handle, and I'll Show You an Object Technical Articles\Windows Platform\Windows Management\Windows Classes in Win32 Backgrounders\Windows Platform\Base\The Foundations of Microsoft Windows NT System Architecture
Формат исполняемых файлов Win32 6i Формат исполняемых файлов Win32 Вероятно, многие вспомнят фразу «Алгоритмы + структуры данных = Программы», приписываемую Н. Вирту (N. Wirtch) — отцу семейства языков Pascal, современным представителем которого является Delphi. Однако откомпилированный двоичный код сам по себе является структурой данных, содержимое которой обрабатывается системой при загрузке программы в память для исполнения. На платформах Win32 эта структура данных называется форматом «Portable Executable», или сокращенно РЕ. Знание файлового формата РЕ заметно упрощает программирование для Windows. Это знание дает возможность понять, каким образом исходный текст превращается в двоичный код, где хранятся глобальные переменные и как они инициализируются, как работают общие переменные и т. д. Все DLL в системе Win32 имеют формат РЕ; следовательно, зная формат РЕ, вы лучше поймете, как работает механизм динамической компоновки, как происходит разрешение ссылок при импортировании и как избежать динамической смены базового адреса DLL. Методика перехвата функций API в существенной степени основывается на знании структуры таблицы импортируемых функций. Наконец, знание формата РЕ позволяет лучше понять структуру пространства виртуальной памяти в среде Win32. В этой книге есть несколько мест, в которых пригодится знание файлового формата РЕ, поэтому мы кратко рассмотрим сам этот формат и его форму после загрузки в память. Программисты пишут исходные тексты программ на С, C++, ассемблере или других языках. Эти исходные тексты затем транслируются компилятором в объектные файлы в формате OBJ. Каждый объектный файл содержит глобальные переменные (инициализированные или неинициализированные), неизменяемые данные, ресурсы, исполняемый код на машинном языке, символические имена для компоновки и отладочную информацию. Объектные файлы модуля связываются компоновщиком с библиотеками, которые сами представляют собой объединение объектных файлов. Наиболее распространенными являются runtime-библиотеки С и C++, библиотеки MFC/ATL, библиотеки импортируемых функций Win32 API или системных функций ядра Windows. Компоновщик разрешает все взаимные ссылки между объектными ссылками и библиотеками. Например, если в вашей программе вызывается библиотечная функция C++ new, то компоновщик находит адрес new в runtime-библиотеке C++ и заносит его в программу. После этого компоновщик объединяет все инициализированные глобальные переменные в одну секцию, все неинициализированные глобальные переменные — в другую секцию, весь исполняемый код — в третью секцию и т. д. Группировка разных частей объектных файлов по разным секциям выполняется по двум причинам: защита и оптимальное использование ресурсов. Неизменяемые данные и исполняемый код обычно объявляются доступными только для чтения. Это помогает программисту находить ошибки в программе, если операционная система обнаруживает попытку записи в соответствующую область памяти. Установка атрибута доступа «только для чтения» осуществляется компоновщиком. Конечно, секции глобальных переменных (инициализированных и неинициализированных) должны быть доступны как для чтения, так и для записи. В коде операционной системы Windows широко используются DLL;
62 Глава 1. Основные принципы и понятия например, для всех программ Win32 с графическим интерфейсом пользователя требуется файл gdi32.dll. С целью оптимального использования памяти секция исполняемого кода gdi32.dll хранится в памяти лишь в одном экземпляре на всю систему. Разные процессы работают с кодом DLL через файл, отображаемый на память. Это возможно благодаря тому, что исполняемый код доступен только для чтения, а значит, для всех процессов он будет одинаковым. Глобальные данные не могут совместно использоваться разными процессами, если только они не были специально помечены как общие. С каждой секцией связывается символическое имя, по которому на нее можно ссылаться в параметрах компоновщика. Код или данные, принадлежащие одной секции, обладают одинаковыми атрибутами. Память для секций выделяется постранично, поэтому на процессорах Intel размер минимального блока памяти, выделяемого для секции, равен 4 Кбайт. Некоторые часто используемые секции перечислены в табл. 1.4. Таблица 1.4. Часто используемые секции РЕ-файлов Имя Содержимое Атрибуты .text Исполняемый код .data Инициализированные глобальные данные .rsrc Ресурсы .bss Неинициализированные глобальные данные .rdata Неизменные данные .idata Каталог импорта .edata Каталог экспорта .reloc Таблица настройки адресов .shared Общие данные Код, исполнение, чтение Инициализированные данные, чтение/запись Инициализированные данные, только для чтения Чтение/запись Инициализированные данные, только для чтения Инициализированные данные, чтение/запись Инициализированные данные, только для чтения Инициализированные данные, удаляемая (discardable) память, только для чтения Инициализированные данные, общая память, чтение/запись Исполняемый код и глобальные данные в РЕ-файлах практически не структурируются — никто не хочет помогать хакерам взламывать свои программы. Но в остальных данных операционной системы время от времени приходится выполнять поиск. Например, при загрузке модуля загрузчик должен провести поиск в таблице импортируемых функций и настроить значения адресов; когда пользователь вызывает GetProcAddress, поиск производится в таблице экспорти-
Формат исполняемых файлов Win32 63 руемых функций. В РЕ-файлах для таких целей резервируется 16 специальных таблиц, называемых каталогами (directories). Чаще всего используются каталоги импорта, связанного импорта (bound import), отложенного импорта (delayed import), экспорта, настройки адресов (relocation), ресурсов и отладочной информации. Объединяем секции и каталоги, добавляем пару заголовков со служебной информацией — и получаем РЕ-файл (рис. 1.4). IMAGE DOS HEADER Заглушка DOS Сигнатура РЕ-файла £о: IMAGE FILE HEADER !Ш ш'§ <Х IMAGE_OPTIONAL_ ^ HEADER R32 Таблица секций IMAGE_SECTION_HEADER Q Секция .text (двоичный код) Секция .data (инициализированные данные) Секция .reloc (таблица настройки адресов) Секция .rsrc (константы) Секция .rdata (ресурсы) Рис. 1.4. Структура файлов формата Portable Executable РЕ-файл начинается с заголовка ЕХЕ-файла DOS (структура IMAGEDOSHEADER), потому что Microsoft хочет, чтобы программы Win32 можно было запускать в сеансе DOS. Непосредственно за IMAGEDOSHEADER следует заглушка (stub) — крошечная DOS-программа, которая генерирует программное прерывание для вывода сообщения об ошибке и завершает работу программы. После заглушки следует настоящий заголовок РЕ-файла (IMAGENTHEADERS). Обратите внимание: длина программы-заглушки не фиксируется, поэтому для определения смещения структуры IMAGENTHEADERS следует использовать значение поля ejfanew структуры IMAGE_DOS_HEADER. Структура IMAGE_NT_HEADERS начинается с 4-байтовой сигнатуры, которая должна быть равна IMAGENTSIGNATURE1. 1 Макрос, определяемый в winnt.h. — Примеч. перев.
64 Глава 1. Основные принципы и понятия В противном случае это может быть файл OS/2 или VxD. Структура IMAGE_FILE_ HEADER содержит идентификатор целевого процессора, количество секций в файле, время сборки, указатель на таблицу символических имен и размер «необязательного» заголовка. Несмотря на свое название, структура IMAGEOPTIONALHEADER не является необязательной (optional). Она встречается в каждом РЕ-файле, поскольку хранящаяся в ней информация слишком важна. В этой структуре хранится рекомендуемый базовый адрес модуля, размеры кода и данных, базовые адреса кода и данных, конфигурация кучи и стека, требования к версии ОС и подсистемы, а также таблица каталогов. РЕ-файл содержит множество адресов для ссылок на функции, переменные, имена, таблицы и т. д. Некоторые из них хранятся в виде виртуальных адресов, которые могут напрямую использоваться после загрузки модуля в память. Если модуль не удается загрузить по рекомендуемому базовому адресу, загрузчик исправляет данные в соответствии с фактическим адресом. Однако большинство адресов задается по отношению к началу заголовка РЕ-файла. Такие адреса называются «относительными виртуальными адресами» (relative virtual addresses, RVA). Обратите внимание: значение RVA не совпадает со смещением в РЕ- файле перед его загрузкой в память. Дело в том, что в РЕ-файлах секции обычно выравниваются по 32-разрядным границам, а операционная система использует выравнивание по страницам. Для процессоров Intel размер страницы равен 4096 байт. Адреса RVA вычисляются в предположении, что секции выравниваются по страницам — это уменьшает затраты ресурсов во время выполнения программы. Ниже приведен простой класс C++ для выполнения несложных операций с модулями Win32, загруженными в память. Конструктор показывает, как получить указатели на структуры IMAGEDOSHEADER и IMAGENTHEADER. В функции GetDi rectory продемонстрировано получение указателя на данные каталога. Мы усовершенствуем этот класс, чтобы он приносил практическую пользу. class KPEFile { const char * pModule; PIMAGE_DOS_HEADER pDOSHeader; PIMAGE_NT_HEADERS pNTHeader; public: const char * RVA2Ptr(unsigned rva) { if ( (pModule!=NULL) && rva) return pModule + rva; else return NULL: } KPEFile(HMODULE hModule): const void * GetDirectory(int id): PIMAGE_IMPORT_DESCRIPTOR GetImportDescriptor(LPCSTR pDHName);
Формат исполняемых файлов Win32 65 const unsigned * GetFunctionPtr(PIMAGE_IMPORT_DESCRIPTOR plmport. LPCSTR pProcName); FARPROC SetlmportAddressCLPCSTR pDHName, LPCSTR pProcName. FARPROC pNewProc); FARPROC SetExportAddressCLPCSTR pProcName. FARTPROC pNewProc); }: KPEFile::KPEFileCHMODULE hModule) { pModule = (const char *) hModule; if ( IsBadReadPtr(pModule, sizeof(IMAGE_DOS_HEADER)) ) { pDOSHeader = NULL; pNTHeader = NULL; } else { pDOSHeader = (PIMAGE_DOS_HEADER) pModule; if ( IsBadReadPtr(RVA2Ptr(pD0SHeader->e_lfanew), sizeof(IMAGE_NT_HEADERS)) ) pNTHeader = NULL: else pNTHeader = (PIMAGE_NT_HEADERS) RVA2Ptr(pD0SHeader-> ejfanew); } } // Функция возвращает адрес каталога РЕ const void * KPEFile::GetDirectory(int id) { return RVA2Ptr(pNTHeader->0ptionalHeader.DataDirectory[id]. Virtual Address); } Получив общее концептуальное представление о файловом формате РЕ, давайте рассмотрим несколько практических примеров. Каталог импорта При использовании в программе функции Win32 API (например, LoadLibraryW) генерируется двоичный код следующего вида: DWORD imp LoadLibrary@4 = 0х77Е971С9: call dword ptr[__imp_LoadLibraryW@4] Обратите внимание на любопытную подробность: компилятор создает внутреннюю глобальную переменную и использует косвенный вызов вместо прямого. Впрочем, для этого у компилятора есть довольно веские причины. Компоновщик не знает точного адреса LoadLibraryW@4 на стадии компоновки, хотя он может сделать предположение на основании одной версии kernel32.dll (указан-
66 Глава 1. Основные принципы и понятия ной в каталоге связанного импорта). Следовательно, в большинстве случаев загрузчик модуля должен найти правильный адрес импортируемой функции и внести исправления в загружаемый образ модуля. Одна и та же функция (такая, как LoadLibraryW) может вызываться в модуле многократно. По соображениям быстродействия загрузчик предпочел бы вносить исправления в минимальном количестве мест, в идеальном случае — в одном месте на каждую импортируемую функцию. Таким местом является переменная, содержащая адрес импортируемой функции. Обычно подобным переменным присваиваются внутренние имена вида imp xxx. Адреса импортируемых функций либо выделяются в отдельную секцию (как правило, ей присваивается имя .idata), либо объединяются с секцией . text для экономии места. Каждый модуль обычно импортирует по несколько функций из разных модулей. В РЕ-файле каталог импорта ссылается на массив структур IMAGE_IMPORT_ DESCRIPTOR, каждая из которых соответствует одному импортируемому модулю. Первое поле IMAGEIMPORTDESCRIPT0R содержит смещение в таблице хинтов/имен, а последнее поле содержит смещение в таблице импортируемых адресов. Две таблицы имеют одинаковую длину, а каждый элемент соответствует одной импортируемой функции. Элемент таблицы импортируемых адресов содержит порядковый номер, если установлен старший бит (импортирование по порядковому номеру), или смещение 16-разрядного хинта, за которым следует имя импортируемой функции (импортирование по имени). Таким образом, таблица хинтов/имен может использоваться для поиска в каталоге экспорта того модуля, из которого мы импортируем. В исходном РЕ-файле таблица импортируемых адресов может содержать ту же информацию, что и таблица хинтов/имен — то есть смещение хинта, за которым следует имя функции. В этом случае загрузчик находит адрес импортируемой функции и модифицирует элемент таблицы импортируемых адресов. Следовательно, после загрузки РЕ-файла таблица импортируемых адресов в действительности превращается в таблицу адресов импортируемых функций. Компоновщик также может связать модуль с некоторой библиотекой DLL, чтобы таблица инициализировалась адресами импортируемых функций для определенной версии DLL. В последнем случае таблица импортируемых адресов содержит адреса связанных импортируемых функций. В обоих случаях таблица импортируемых функций содержит внутренние переменные вида imp LoadLibrary@4. Давайте попробуем реализовать функцию KPEFile: :SetImportAddress. Эта функция изменяет адрес импортируемой функции в модуле и возвращает первоначальное значение адреса. // Функция возвращает значение поля PIMAGE_IMPORT_DESCRIPTOR // для импортируемого модуля PIMAGEJMPORT_DESCRIPTOR KPEFile: :GetImportDescriptor( LPCSTR pDllName) { // Получить IMAGE_IMPORT_DESCRIPTOR PIMAGE_IMPORT_DESCRIPTOR plmport = (PIMAGE_IMPORT_DESCRIPTOR) GetDi rectory (IMAGE JIRECTORYJNTRYJMPORT); if ( pImport==NULL )
Формат исполняемых файлов Win32 67 return NULL; while ( pImport->FirstThunk ) { if ( StricmpCpDllName. RVA2Ptr(pImport->Name))==0 ) return pimport; // Перейти к следующему импортируемому модулю pimport ++; } return NULL; // Функция возвращает адрес переменной imp_xxx // для импортируемой функции const unsigned * KPEFile::GetFunctionPtr( PIMAGE_IMPORT_DESCRIPTOR pimport, LPCSTR pProcName) { PIMAGE_THUNK_DATA pThunk; pThunk = (PIMAGE_THUNK_DATA) RVA2Ptr(pImport-> OriginalFirstThunk); for (int i=0: pThunk->ul.Function; i++) { bool match; // По порядковому номеру if ( pThunk->ul.Ordinal & 0x80000000 ) match = (pThunk->ul.Ordinal & OxFFFF) == ((DWORD) pProcName); else match = stricmp(pProcName, RVA2Ptr((unsigned) pThunk->ul.Address0fData)+2) == 0; if ( match ) return (unsigned *) RVA2Ptr(pImport->FirstThunk)+i; pThunk ++; } return NULL; } FARPROC KPEFile::SetImportAddress(LPCSTR pDllName, LPCSTR pProcName. FARPROC pNewProc) { PIMAGE_IMPORT_DESCRIPTOR pimport = GetlmportDescriptor(pDllName); if ( pimport ) { const unsigned * pfn = GetFunctionPtr(pImport. pProcName);
68 Глава 1. Основные принципы и понятия if ( IsBadReadPtr(pfn, sizeof(DWORD)) ) return NULL; // Получить исходный адрес функции FARPROC oldproc = (FARPROC) * pfn; DWORD dwWritten; // Заменить новым адресом функции HackWriteProcessMemory(GetCurrentProcess(). (void*) pfn, & pNewProc, sizeof(DWORD). & dwWritten); return oldproc; } else return NULL; } В работе SetlmportAddress используются две вспомогательные функции. Функция GetlmportDescriptor просматривает каталог импорта и ищет в нем структуру IMAGEIMPORTDESCRIPTOR для того модуля, из которого импортируется функция. Структура передается функции GetFunctionPtr, которая просматривает таблицу хинтов/имен и возвращает адрес соответствующего элемента в таблице импортируемых адресов. Например, если импортируется функция MessageBoxA из user32.dll, то функция GetFunctionPtr должна вернуть адрес imp MessageBoxA. Наконец, функция SetlmportAddress читает исходный адрес функции и заменяет его новым адресом при помощи функции WriteProcessMemory. После вызова SetlmportAddress все вызовы указанной импортируемой функции из модуля будут передаваться новой функции. Таким образом, функция SetlmportAddress позволяет организовать перехват (hooking) вызовов функций API. Ниже приведен простой пример использования класса KPEFile для перехвата вывода окна сообщения: int WINAPI MyMessageBoxA(HWND hWnd. LPCSTR pText. LPCSTR pCaption, UI NT uType) { WCHAR wText[MAX_PATH]; WCHAR wCaption[MAX_PATH]; MultiByteToWideChar(CP_ACP, MB_PREC0MP0SED. pText. -1. wText. MAX_PATH); wcscat(wText. L" - intercepted"): MultiByteToWideChar(CP_ACP. MB_PREC0MP0SED, pCaption. -1. wCaption. MAX_PATH); wcscat(wCaption, L" - intercepted"); return MessageBoxW(hWnd, wText. wCaption, uType); } int WINAPI WinMain(HINSTANCE hlnstance. HINSTANCE. LPSTR, int) { KPEFile pe(hlnstance):
Формат исполняемых файлов Win32 69 ре.SetImportAddress("user32.dl1". "MessageBoxA". (FARPROC) MyMessageBoxA); MessageBoxA(NULL. "Test". "SetlmportAddress". MB_0K); } Программа заменяет импортируемый адрес MessageBoxA в текущем модуле адресом функции MyMessageBoxA, реализованной нашим приложением, после чего все вызовы MessageBoxA поступают в MyMessageBoxA. В нашем примере эта функция добавляет в текст и заголовок дополнительное слово «intercepted» («перехвачено») и отображает окно сообщения функцией MessageBoxW. Каталог экспорта Чтобы ваша программа могла импортировать функцию/переменную из системной библиотеке DLL, эта функция/переменная должна быть соответствующим образом экспортирована. Для экспортирования функции/переменной из DLL РЕ-файл должен содержать три объекта данных — порядковый номер, адрес и необязательное имя. Вся информация, относящаяся к экспортируемым функциям, объединяется в структуру I MAGE_EXPORT_D I RECTORY, к которой можно обратиться через каталог экспорта в заголовке РЕ-файла. Хотя экспортироваться могут как функции, так и переменные, обычно экспортируются только функции. По этой причине даже в названиях полей в структурах РЕ-файлов упоминаются только функции. Структура IMAGEEXPORTDI RECTORY содержит информацию о количестве экспортируемых функций и количестве имен, которое может быть меньше общего количества функций. Большинство DLL экспортирует функции по имени. В некоторых DLL (например, comctl32.dll) одни функции экспортируются по имени, а другие — по порядковому номеру. Некоторые DLL (например, MFC DLL) экспортируют тысячи функций, поэтому для экономии места, занимаемого именами, все функции экспортируются по порядковому номеру. Библиотеки COM DLL экспортируют фиксированное количество хорошо известных функций (например, DIlRegisterServer) с одновременным предоставлением служебных интерфейсов или таблиц виртуальных функций. Некоторые DLL вообще ничего не экспортируют — в них используется только точка входа в DLL. Более интересная информация в I MAGEEXPORTD I RECTORY включает RVA таблицы адресов функций, таблицы имен функций и таблицы порядковых номеров функций. Таблица адресов содержит RVA всех экспортируемых функций. Таблица имен содержит RVA строк с именами функций, а таблица порядковых номеров содержит разности между реальным и базовым порядковыми номерами. Зная структуру таблицы экспорта, можно легко реализовать функцию Get- ProcAddress. Однако такая реализация уже существует в Win32 API (к сожалению, она не имеет Unicode-версии). Вместо этого давайте попробуем реализовать функцию KPEFile::SetExportAddress. Как было показано выше, функция SetlmportAddress модифицирует таблицу импорта модуля и изменяет адрес одной импортируемой функции в одном модуле. На другие модули процесса (в том числе и модули, загруженные процессом позднее) эти изменения не распространяются. Функция SetExportAddress
70 Глава 1. Основные принципы и понятия работает иначе. Она модифицирует таблицу экспорта модуля и поэтому влияет на все экземпляры экспортируемой функции в будущем. Ниже приведен код функции SetExportAddress. FARPROC KPEFiIe::SetExportAddress(LPCSTR pProcName. FARPROC pNewProc) { PIMAGE_EXP0RT_DIRECTORY pExport = (PIMAGE_EXPORT_DIRECTORY) GetDi rectory (IMAGEJHRECTORYJNTRYJXPORT); if ( pExport==NULL ) return NULL; unsigned ord = 0; if ( (unsigned) pProcName < OxFFFF ) // По порядковому номеру? ord = (unsigned) pProcName; else { const DWORD * pNames - (const DWORD *) RVA2Ptr(pExport->Address0fNames); const WORD * pOrds - (const WORD *) RVA2Ptr(pExport->Address0fName0rdinals); // Найти элемент с именем функции for (unsigned i=0; i<pExport->AddressOfNames; i++) if ( stricmp(pProcName. RVA2Ptr(pNames[i]))==0 ) { // Получить соответствующий порядковый номер ord = pExport->Base + pOrds[i]; break; if ( (ord<pExport->Base) || (ord>pExport->NumberOfFunctions) ) return NULL; // Использовать порядковый номер для получения адреса. // по которому хранится RVA экспортируемой функции DWORD * pRVA - (DWORD *) RVA2Ptr(pExport->Address0fFunctions) + ord - pExport->Base; // Прочитать исходный адрес функции DWORD rslt - * pRVA; DWORD dwWritten = 0; DWORD newRVA = (DWORD) pNewProc - (DWORD) pModule; WriteProcessMemory(GetCurrentProcess(). pRVA. & newRVA. sizeof(DWORD), & dwWritten); return (FARPROC) RVA2Ptr(rslt); } Функция SetExportAddress сначала пытается найти порядковый номер заданной функции. Если порядковый номер не указан, имя функции ищется в табли-
Архитектура операционной системы Microsoft Windows 71 це имен функций. Индексирование таблицы адресов функций по порядковому номеру дает адрес, по которому хранится RVA экспортируемой функции. Затем SetExportAddress читает исходный RVA и заменяет его новым, вычисленным по новому адресу функции. В результате модификации таблицы экспорта после вызова SetExportAddress функция GetProcAddress будет возвращать адрес новой функции. При будущих загрузках DLL процессом компоновка будет осуществляться с новой функцией. Ни SetlmportAddress, ни SetExportAddress по отдельности не обеспечивают полного перехвата вызовов API процессом, однако совместное использование обеих функций в значительной степени решает эту задачу. Идея проста: мы перебираем все модули, загруженные процессом в настоящий момент, и вызываем SetlmportAddress для каждого из них. Затем вызывается функция SetExportAddress, модифицирующая таблицу экспорта. В этом случае модификация распространяется как на модули, загруженные в настоящий момент, так и на модули, которые будут загружены в будущем. На этом наше краткое знакомство с файловым форматом РЕ подходит к концу. Материал этого раздела будет использоваться при изучении виртуального пользовательского пространства в главе 3 и перехвате/отслеживании вызовов API в главе 4. Если вас действительно интересуют РЕ-файлы и отслеживание API, подумайте, не осталось ли вызовов API, на которые не распространяются последствия вызовов SetlmportAddress и SetExportAddress. Архитектура операционной системы Microsoft Windows Возьмите корпус с источником питания, материнскую плату, процессор, память, жесткий диск, устройство чтения компакт-дисков, видеоадаптер, клавиатуру и монитор, соберите в одно целое — получается компьютер. Но для того чтобы компьютер делал что-то полезное, нужны программы. Компьютерные программы условно делятся на системные и прикладные. Системные программы управляют работой компьютера и периферийных устройств, тем самым обеспечивая работу прикладных программ, которые решают реальные задачи пользователей. Наиболее фундаментальной системной программой является операционная система, которая управляет всеми ресурсами компьютера и обеспечивает удобный интерфейс для работы с прикладными программами. Оборудование, на котором мы работаем (хотя и обладает значительно большими возможностями, чем его предшественники), программируется на очень примитивном и неудобном уровне. Одной из главных задач операционной системы является упрощение программирования оборудования за счет использования четко определенных системных функций. Системные функции реализуются операционной системой в привилегированном режиме процессора; они определяют интерфейс между операционной системой и пользовательскими программами, работающими в непривилегированном режиме процессора. Microsoft Windows NT/2000 несколько отличается от традиционных операционных систем. Windows NT/2000 состоит из двух основных частей: привиле-
72 Глава 1. Основные принципы и понятия тированной части режима ядра (privileged kernel mode part) и непривилегированной части пользовательского режима (nonprivileged user mode part). Часть режима ядра ОС Windows NT/200 работает в привилегированном режиме процессора, в котором доступны все инструкции процессора и все адресное пространство. На процессорах Intel это означает работу на уровне привилегий 0 с доступом к 4 Гбайтам адресного пространства, адресному пространству ввода-вывода и т. д. Часть пользовательского режима ОС Windows NT/2000 работает в непривилегированном режиме процессора, в котором доступен лишь ограниченный набор инструкций и часть адресного пространства. На процессорах Intel код пользовательского режима работает на уровне привилегий 3 и обладает доступом только к младшим 2 Гбайтам адресного пространства процесса. Порты ввода- вывода для него недоступны. Часть режима ядра обеспечивает использование системных функций и внутренних процессов частью пользовательского режима. Microsoft называет эту часть «исполнительной» (executive). Это единственная точка входа к ядру операционной системы; по соображениям безопасности Microsoft отказалась от создания «черных ходов». Код режима ядра состоит из следующих основных компонентов: О HAL (Hardware Abstraction Layer) — программная прослойка, абстрагирующая часть режима ядра от аппаратных различий, зависимых от платформы; О микроядро (MicroKernel) — низкоуровневые функции операционной системы: планирование потоков, переключение задач, обработка прерываний и исключений, многопроцессорная синхронизация; О драйверы устройств (Device Drivers) — драйверы оборудования, файловой системы и сетевой поддержки, реализующие пользовательские функции ввода-вывода; О управление окнами и графическая система — реализация функций графического интерфейса (окна, элементы, графический вывод и печать); О исполнительная часть — базовые функции операционной системы: управление памятью, управление процессами и программными потоками, безопасность, ввод-вывод и межпроцессные взаимодействия. Часть пользовательского режима Windows NT/2000 обычно состоит из трех компонентов: О системные процессы — специальные системные процессы (например, процесс регистрации пользователя в системе и диспетчер сеансов); О службы (services) — в частности, службы ведения журнала событий и планирования; О платформенные подсистемы — предоставление функций операционной системы пользовательским программам через четко определенные интерфейсы API. В Windows NT/2000 поддерживается возможность запуска программ Win32, POSIX (Portable Operating System Interface — международный стандарт API операционной системы уровня языка С), OS/2 1.2 (операционная система компании IBM), DOS и Winl6.
Архитектура операционной системы Microsoft Windows 73 HAL Уровень HAL (Hardware Abstraction Layer) отвечает за платформенно-зависи- мую поддержку работы ядра NT, диспетчера ввода-вывода, отладчиков режима ядра и низкоуровневых драйверов устройств. Присутствие HAL снижает зависимость операционной системы Windows NT/2000 от конкретной аппаратной платформы или архитектуры. HAL обеспечивает абстрактное представление для адресации устройств, архитектуры ввода-вывода, управления прерываниями, операций DMA (Direct Memory Access), системных часов и таймеров, встроенных программ (firmware), интерфейсных средств BIOS и управления конфигурацией. При установке Windows NT/2000 поддержка HAL осуществляется модулем system32\hal.dll. Но на самом деле для разных архитектур существуют разные модули HAL; лишь один из них копируется в системный каталог и переименовывается в hal.dll. Просмотрите установочный компакт-диск Windows NT/2000, и вы найдете на нем несколько вариантов HAL — например, halacpi.dl_, halsp.dL и halmps.dl_. Сокращение ACPI означает «Advanced Configuration and Power Interface», то есть «интерфейс автоматического управления конфигурацией и питанием». Чтобы узнать, какие же возможности обеспечивает HAL в вашей системе, введите команду dumpbin hal. сП 1 /export. В полученном списке присутствуют такие экспортируемые функции, как HalDisableSystemlnterrupt, HalMakeBeep, HalSet- RealTimeClock, READ_P0RT_UCHAR, WRITE_P0RT_UCHAR и т. д. Функции, экспортируемые HAL, документируются в Windows 2000 DDK, в разделе «Kernel Mode Drivers, References, Part 1, Chapter 3.0: Hardware Abstraction Layer Routines». Микроядро Микроядро (MicroKernel) Windows NT/2000 управляет главным ресурсом компьютера — процессором. Оно обеспечивает поддержку обработки прерываний и исключений, планирования и синхронизации программных потоков, многопроцессорной синхронизации и отсчета времени. Микроядро предоставляет свои функции клиентам через объектно-базированные (object based) интерфейсы, по аналогии с объектами и манипуляторами, используемыми в Win32 API. Главными объектами, поддерживаемыми микроядром, являются диспетчерские и управляющие объекты. Диспетчерские объекты (dispatcher objects) предназначены для диспетчеризации и синхронизации. К их числу относятся события, мьютексы, очереди, семафоры, программные потоки и таймеры. Каждый диспетчерский объект находится в определенном состоянии — установленном (signaled) или сброшенном (not signaled). Микроядро содержит функции, которым состояние диспетчерских объектов передается в качестве параметров (KeWaitxxx). Программные потоки режима ядра синхронизируются ожиданием диспетчерских объектов или объектов пользовательского режима, содержащих внедренные диспетчерские объекты режима ядра. Например, у объектов событий пользовательского уровня в Win32 имеются соответствующие объекты событий уровня микроядра.
74 Глава 1. Основные принципы и понятия Управляющие объекты используются для управления операциями режима ядра (кроме операций диспетчеризации и синхронизации, управляемых диспетчерскими объектами). К числу управляющих объектов относятся асинхронные вызовы процедур (АРС, Asynchronous Procedure Call), отложенные вызовы процедур (DPC, Deferred Procedure Call), прерывания и процессы. Блокировка с ожиданием (spin lock) представляет собой низкоуровневый механизм синхронизации, определяемый на уровне ядра NT. Этот механизм используется для синхронизации доступа к общим ресурсам, особенно в многопроцессорных системах. Когда функция пытается получить ресурс в свое распоряжение, она переходит в режим ожидания до предоставления блокировки, не выполняя никакой полезной работы. В вашей системе микроядро находится в файле ntoskrnl.exe. Кроме микроядра в этом файле находится исполнительная часть. На установочном компакт-диске имеется две версии микроядра: ntkrnlmp.ex_ для многопроцессорных систем и ntkrnlsp.ex_ для однопроцессорных систем. Хотя модуль имеет расширение .ехе, в действительности он представляет собой DLL. Среди нескольких сотен функций, экспортируемых ntoskrnl.exe, примерно 60 принадлежат к микроядру. Имена всех функций, поддерживаемых микроядром, начинаются с префикса «Ке». Например, функция KeAcquireSpinLock предназначена для получения блокировки, обеспечивающей безопасную работу с общими данными в многопроцессорной системе. Функция KelnitializeEvent инициализирует структуру события уровня ядра, которая затем может использоваться функциями KeClearEvent, KeResetEvent и KeWaitForSingleObject. Объекты ядра описаны в Windows DDK, в разделе «Kernel Mode Drivers, Design Guide, Part 1, Chapter 3.0: NT Objects and Support for Drivers». Функции ядра документируются в разделе «Kernel Mode Drivers, References, Part 1, Chapter 5.0: Kernel Routines». Драйверы устройств Итак, микроядро управляет процессором; HAL управляет шиной, DMA, таймером, встроенными программами и BIOS. Но чтобы компьютер мог приносить реальную пользу, операционная система должна взаимодействовать с множеством разнообразных устройств, в том числе с видеоадаптером, мышью, клавиатурой, жестким диском, устройством чтения компакт-дисков, сетевым адаптером, параллельными и последовательными портами и т. д. Для взаимодействия с этими устройствами операционная система использует драйверы устройств. Большинство драйверов устройств в Windows NT/2000 является драйверами режима ядра; исключение составляют драйверы виртуальных устройств (VDD, Virtual Device Drivers) для приложений MS-DOS и драйверы принтеров пользовательского режима Windows 2000. Драйверы устройств режима ядра представляют собой DLL, загруженные в адресное пространство ядра в соответствии с конфигурацией оборудования и пользовательскими настройками. Интерфейс операционной системы Windows NT/2000 с драйверами устройств имеет многоуровневую структуру. Пользовательское приложение вызывает функции API — такие, как функции Win32 CreateFile, ReadFile, WriteFile и т. д. Вызовы преобразуются в вызовы функций системы ввода-вывода, поддерживаемой исполнительной частью Windows NT/2000. Диспетчер ввода-вывода вместе с
Архитектура операционной системы Microsoft Windows 75 исполнительной частью создает пакеты запросов ввода-вывода (IRP, I/O Request Packets) и передает их физическому устройству через драйвер (или через несколько драйверов, находящихся на разных уровнях). В Windows NT/2000 определены четыре типа драйверов режима ядра, имеющих разную структуру и функциональные возможности. О Драйвер верхнего уровня (Highest-Level Driver). К этой категории относятся в первую очередь драйверы файловых систем — в частности, драйверы файловой системы FAT (File Allocation Table), унаследованной от DOS, файловой системы NT (NTFS), файловой системы CD-ROM (CDFS), а также драйверы сетевого сервера и редиректор NT. Драйвер файловой системы может реализовывать физическую файловую систему на локальном жестком диске, но он может также реализовать и распределенную или сетевую виртуальную файловую систему. Например, некоторые системы контроля версий исходных программ реализуются в виде виртуальных файловых систем. Работа драйверов верхнего уровня основана на использовании драйверов более низких уровней. О Промежуточные драйверы (Intermediate Drivers) — драйверы виртуальных дисков, драйверы зеркального копирования (mirror drivers) или драйверы, относящиеся к определенной категории устройств, драйверы уровней сетевого транспорта, фильтрующие драйверы (filter drivers). Промежуточные драйверы либо обеспечивают дополнительные возможности, либо выполняют специфические операции для определенного класса устройств. Например, существует драйвер класса для обмена данными через параллельный порт. Работа промежуточных драйверов тоже основана на поддержке со стороны драйверов более низких уровней. В иерархию может входить несколько промежуточных драйверов. О Драйверы нижнего уровня (Lowest-Level Drivers), иногда называемые драйверами устройств. Примерами являются драйвер шины РпР, унаследованные драйверы устройств NT и драйвер NIC (Network Interface Controller). О Мини-драйверы (Mini-Drivers) — модули специализированной настройки более общих драйверов. Мини-драйвер не является полноценным драйвером. Он находится внутри общего «драйвера-оболочки» и используется для его настройки под конкретное оборудование. Например, Microsoft определяет универсальный драйвер принтера UniDriver. Производители принтеров могут разрабатывать для своих принтеров мини-драйверы, которые будут загружаться драйвером UniDriver для печати на конкретном принтере. Драйвер устройства не всегда соответствует физическому устройству. Драйвер устройства является удобным средством, которое позволяет программисту написать модуль, загружаемый в адресное пространство ядра. Загрузка модуля в адресное пространство ядра открывает полезные возможности, недоступные в обычных условиях. Наличие в Win32 API четко определенных файловых операций позволяет вашему приложению пользовательского режима легко взаимодействовать с драйвером режима ядра. Например, на сайте www.sysinternals.com имеется несколько очень полезных утилит для NT, которые позволяют использовать драйверы устройств режима ядра для контроля за реестром, файловой
76 Глава 1. Основные принципы и понятия системой и портами ввода-вывода. В главе 3 этой книги приведен простой драйвер режима ядра, который читает данные из адресного пространства ядра. Мы будем интенсивно использовать его для анализа структур данных графической подсистемы Windows. Хотя большинство драйверов устройств входит в стек ввода-вывода, управляемый диспетчером ввода-вывода исполнительной части, и имеет сходную структуру, некоторые драйверы устройств являются исключениями. Драйверы устройств для графического механизма Windows NT/2000 — например, драйвер экрана, драйвер принтера и драйвер видеопорта — используют другую структуру и вызываются напрямую. Windows 2000 даже позволяет драйверам принтеров работать в пользовательском режиме. Драйверы экрана и драйверы принтеров более подробно рассматриваются в главе 2. Большинство модулей, загруженных в адресное пространство ядра, представляет собой драйверы устройств. Утилита drivers из Windows NT/2000 DDK выводит список драйверов в окне сеанса DOS. В этом списке вы найдете драйвер tcpip.sys для сетевого обмена данными, драйвер мыши mouclass.sys, драйвер клавиатуры kbdclass.sys, драйвер CD-ROM cdrom.sys и т. д. Полная информация о драйверах устройств в Windows 2000 приводится в Windows 2000 DDK, раздел «Kernel-Mode Drivers, Design Guide and References». Управление окнами и графическая система При разработке ранних версий Microsoft Windows NT одним из ключевых факторов считалась безопасность, поэтому управление окнами и графическая система работали в пользовательском адресном пространстве. Это вызывало столько проблем с быстродействием, что начиная с Windows NT 4.0 компания Microsoft внесла принципиальное изменение в архитектуру системы и переместила управление окнами и графическую систему из пользовательского режима в режим ядра. Система управления окнами обеспечивает работу основных составляющих графического интерфейса Windows — оконных классов, окон, механизма обработки сообщений окнами, перехвата (hooking), свойств окон, меню, заголовков окон, полос прокрутки, указателей мыши, виртуальных клавиш, буфера обмена (clipboard) и т. д. В сущности, это аналог user32.dll уровня ядра, который реализует определения Win32 API из файла winuser.h. Графическая система реализует вывод в GDI/DirectDraw/Direct3D на физическое устройство или в память. Ее работа основана на драйверах графических устройств — таких, как драйверы экрана или драйверы принтеров. Графическая система является основным содержимым библиотеки gdi32.dll, реализующей определения Win32 API из файла wingdi.h. Кроме того, графическая система поддерживает работу драйверов экрана и принтеров — она обеспечивает полноценный механизм визуализации для растровых поверхностей нескольких стандартных форматов. Графическая система подробно рассматривается в главе 2. Система управления окнами и графическая система упакованы в одну большую DLL win32k.sys объемом около 1,6 Мбайт. Если просмотреть список функций, экспортируемых из win32k.sys, вы встретите в нем точки входа графической системы (например, EngBitBIt или PATHOBJbMoveTo), но не найдете ни одной точ-
Архитектура операционной системы Microsoft Windows 77 ки входа системы управления окнами. Дело" в том, что функции управления окнами никогда не вызываются другими компонентами ядра ОС, а функции графической системы должны вызываться драйверами графических устройств. Библиотеки gdi32.dll и user32.dll обращаются к win32k.sys через системные функции. Исполнительная часть Microsoft определяет исполнительную часть (Executive) Windows NT/2000 как совокупность компонентов режима ядра, образующих базовую операционную систему Windows NT/Windows 2000. Помимо HAL, микроядра и драйверов устройств, в исполнительную часть также входят компоненты исполнительной поддержки, диспетчера памяти, диспетчера кэша, структуры процессов, межпроцессных взаимодействий (LPC и RPC), диспетчера объектов, диспетчера ввода- вывода, диспетчера конфигурации и монитора безопасности. Каждый компонент исполнительной части поддерживает набор системных функций, которые могут вызываться из пользовательского режима (кроме диспетчера кэша и HAL) при помощи прерываний. Кроме того, каждый компонент предоставляет точку входа, доступную только для модулей, работающих в адресном пространстве ядра. Компонент исполнительной поддержки (Executive Support) реализует набор функций, вызываемых из режима ядра. Имена этих функций обычно начинаются с префикса «Ех». Главной функциональностью этого компонента является выделение памяти на уровне ядра. В Windows NT/2000 для управления динамическим выделением памяти из адресного пространства режима ядра используются два динамически расширяемых блока памяти, называемых пулами (pools). Первый из них — невыгружаемый (nonpaged) пул — гарантированно остается в физической памяти в течение всего времени. Критические фрагменты (например, обработчики прерываний) могут использовать невыгружаемый пул, не беспокоясь о возникновении прерываний, обусловленных отсутствием страниц в памяти. Второй, выгружаемый (paged) пул, имеет существенно больший размер, однако при нехватке физической памяти его содержимое может выгружаться на диск. Например, память для аппаратно-зависимых растров Win32 выделяется из выгружаемого пула при помощи функций семейства ExAllocatePoolxxx. Компонент исполнительной поддержки также обеспечивает эффективную схему выделения памяти блоками фиксированного размера — так называемые «обзорные списки» (look-aside lists), для работы с которыми используются такие функции, как ExAllocatePagedLookasideList. При загрузке системы из пулов выделяется несколько обзорных списков. Компонент исполнительной поддержки обеспечивает богатый ассортимент атомарных операций — ExInterlockedAddLargelnteger, ExInterlockedRemoveHeadList, InterlockedCompareExchange и т. д. К числу других функциональных возможностей относятся быстрые мьютексы, косвенные вызовы (callback), инициирование исключений, преобразование времени, создание уникальных идентификаторов UUID (Universally Unique Identifier) и т. д. Диспетчер памяти (Memory Manager) обеспечивает управление виртуальной памятью, управление балансовым набором (balance set), отображение виртуальной памяти на физическую и т. д. Диспетчер памяти поддерживает такие функции, как MmFreeContiguousMemory, MmGetPhysicalAddress, MmLockPageableCodeSection и т. д.
78 Глава 1. Основные принципы и понятия Диспетчер кэша (Cache Manager) обеспечивает кэширование данных для драйверов файловой системы Windows NT/2000. Функции диспетчера кэша имеют префикс «Сс». Диспетчер кэша экспортирует такие функции, как CcIsThereDirty- Data и CcCopyWrite. Функции компонента структуры процессов (Process Structure) предназначены для создания и завершения системных потоков режима ядра, а также для оповещения процессов/потоков и обработки запросов к ним. Например, диспетчер памяти может воспользоваться функцией PsCreateSystemThread для создания потока ядра, обеспечивающего запись «грязных» (dirty) страниц. Диспетчер объектов (Object Manager) управляет общим поведением объектов, поддерживаемых исполнительной частью. Исполнительная часть обеспечивает создание объектов для каталогов, событий, файлов, символических ссылок, таймеров и др. такими функциями, как ZwCreateDirectoryObject и ZwCreateFile. После того как объект создан, функции ObReferenceObject и ObDereferenceObject диспетчера объектов обновляют счетчик ссылок, функция ObReferenceObjectBy- Handle проверяет манипулятор объекта и возвращает указатель на сам объект. Диспетчер ввода-вывода (I/O Manager) транслирует запросы ввода-вывода от программ пользовательского режима или других компонентов режима ядра в правильную последовательность обращений к различным драйверам. Количество функций, поддерживаемых этим компонентом, очень велико. Например, функция IoCreateDevice инициализирует объект устройства для его использования драйвером, функция IoCallDriver передает пакеты запросов ввода-вывода следующему драйверу более низкого уровня, а функция IoGetStackLimits проверяет границу стека текущего программного потока. Исполнительная часть Windows NT/2000 также поддерживает небольшую runtime-библиотеку, аналогичную runtime-библиотеке С, но имеющую гораздо меньшие размеры. Runtime-библиотека ядра обеспечивает преобразования Unicode, поразрядные операции, операции с памятью и большими числами, обращения к реестру, преобразование времени, строковые операции и т. д. В Windows NT/2000 исполнительная часть и микроядро упакованы в один модуль ntoskrnl.exe, экспортирующий свыше 1000 точек входа. Функции, экспортируемые ntoskrnl.exe, обычно начинаются с двухбуквенного префикса — признака компонента, к которому относится данная функция. Например, префикс «Сс» означает диспетчер кэша, «1о» — диспетчер ввода-вывода, «Ке» — микроядро, «Ob» — диспетчер объектов, «Rtl» — runtime-библиотеку, «Dbg» — поддержку отладки и т. д. Системные функции Богатая функциональность, поддерживаемая ядром операционной системы Windows NT/2000, предоставляется модулям пользовательского режима через узкий «шлюз». На процессорах Intel это прерывание 0х2Е. Прерывание обслуживается функцией KiSystemService, которая находится в файле ntoskrnl.exe, но не экспортируется. Поскольку обработчик прерывания работает в режиме ядра, процессор автоматически переключается в привилегированный режим, что делает возможными обращения к адресному пространству ядра.
Архитектура операционной системы Microsoft Windows 79 Хотя при вызове используется всего один номер прерывания, нужный номер из более чем 900 системных функций Windows NT/2000 задается в регистре ЕАХ (для процессоров Intel). Программа ntoskrnl.exe поддерживает таблицу системных функций с именем KiServiceTable; в win32k.sys присутствует своя таблица W32pServiceTable. Таблицы системных функций регистрируются вызовом KeAdd- SystemServiceTable. Когда KiSystemService получает вызов системной функции, она проверяет, допустим ли индекс системной функции и доступны ли ожидаемые параметры, после чего передает вызов обработчику данной системной функции. Рассмотрим примеры системных функций в отладчике Microsoft Visual C++ с использованием отладочных символических файлов Windows 2000. Если проследить за вызовом CreateHalftonePalette в Win32GDI, вы увидите следующий фрагмент: _NtGdiCreateHalftonePalette@4: mov eax, 1021h lea edx, [esp+4] int 2Eh ret 4 Пользовательская функция Win32 GetDC реализуется следующим образом: _NtUserGetDC@4: mov eax, 118bh lea edx, [esp+4] int 2Eh ret 4 Функция ядра Win32 CreateEvent устроена посложнее. CreateEventA вызывает функцию CreateEventW, которая, в свою очередь, вызывает NtCreateEvent из ntdll.dll. Реализация NtCreateEvent выглядит так: _NtCreateEvent@20: mov eax, lEh lea edx. [esp+4] int 2Eh ret 14h Вызовы системных функций Windows NT/2000 практически полностью скрыты от программистов. В отладчике SoftICE/W компании Numega имеется команда ntcall, которая позволяет получить информацию о некоторых системных функциях ядра. За дополнительной информацией о системных функциях обращайтесь к статье Марка Руссиновича (Mark Russinovich) «Inside the Native API» на сайте www.sysinternals.com. Системные функции CGI будут более подробно описаны в главе 2. Системные процессы В операционной системе Windows NT/2000 работает несколько системных процессов, управляющих регистрацией пользователя в системе, службами и пользовательскими процессами. Список системных процессов можно просмотреть в диспетчере задач; также можно воспользоваться утилитой tlist, входящей в поставку Platform SDK.
80 Глава 1. Основные принципы и понятия Во время работы Windows NT/2000 существует три иерархии процессов. Первая иерархия состоит из единственного системного процесса, идентификатор которого всегда равен 0. Ко второй иерархии относятся все остальные системные процессы. Она начинается с процесса с именем system, который является родительским по отношению к процессу диспетчера сеанса (smss.exe). Процесс диспетчера сеанса является родителем процесса подсистемы Win32 (csrss.exe) и процесса регистрации пользователя в системе (winlogon.exe). Третья иерархия начинается с процесса диспетчера программ (explorer.exe), являющегося родителем всех пользовательских процессов. Дерево процессов Windows 2000, отображаемое командой tlist -t, выглядит следующим образом: System Process (0) System Idle Process System (8) smss.exe (124) Session Manager csrss.exe (148) Win32 Subsystem server winlogon.exe (168) logon process services.exe (200) service controller svchost.exe (360) spoolsv.exe (400) svchost.exe (436) mstask.exe (480) SYSTEM AGENT COM WINDOW lsass.exe (212) local security authentication server explorer.exe (668) Program Manager 0SA.EXE (744) Reminder IMGIC0N.EXE (760) Утилита Process Walker (pwalker.exe) выводит дополнительную информацию о каждом процессе. Process Walker показывает, что процесс System Idle Process состоит из одного программного потока с начальным адресом 0. Вполне возможно, что это не реальный процесс, а некий механизм, при помощи которого организуется период пассивного ожидания в системе. Процесс System обладает действительным адресом в адресном пространстве ядра и состоит из десятков потоков с начальными адресами, принадлежащими адресному пространству ядра. Следовательно, процесс System также является родительским для системных потоков режима ядра. Если преобразовать начальные адреса потоков этого процесса в символические имена, вы найдете немало интересных имен типа Phasel- Initialization, ExpWorkerThread, ExpWorkerThreadBalanceManager, MiDereferenceSegment- Thread, MiModifiedPageWriter, KeBalancedSetManager, FsRtlWorkerThread и т. д. Хотя все перечисленные потоки создаются исполнительной частью, потоки ядра могут создаваться и другими компонентами ядра. Но системные процессы Idle и System являются «чистыми» компонентами режима ядра, не имеющими модулей в адресном пространстве пользовательского режима. Другие системные процессы (диспетчер сеансов, процесс регистрации пользователей в системе и т. д.) являются процессами пользовательского режима, запущенными из файлов в формате РЕ. Например, файлы smss.exe, csrss.exe и winlogon.exe находятся в системном каталоге Windows.
Архитектура операционной системы Microsoft Windows 81 Службы В Microsoft Windows NT/2000 существует особая категория приложений — так называемые службы (services). Обычно это консольные программы, находящиеся под управлением SCM (Service Control Manager) и предоставляющие определенные услуги. Службы, в отличие от обычных пользовательских программ, могут запускаться автоматически во время загрузки системы, до регистрации в ней пользователя. Чтобы получить список служб, в настоящий момент работающих в вашей системе, запустите утилиту Task List (tlist.exe) с ключом - s. Ниже приведен примерный список служб и служебных программ. 200 services.exe Svcs: AppMgmt, Browser, dmserver, Dnscache. EventLog, LanmanServer, LanmanWorkstation, LmHosts, Messenger. PlugPlay. ProtectedStorage. seclogon. TrkWks 212 lsass.exe 360 svchost.exe 400 spoolsv.exe 436 svchost.exe 480 mstask.exe Svcs Svcs Svcs Svcs Svcs Poli cyAgent. RpcSs Spooler EventSystem. RasMan.SENS. Schedule SamSs Netman. NtmsSvc. TapiSrv Из этих служб для нас особый интерес представляет спулер (spooler), который обрабатывает задания печати на локальных компьютерах и передает их на принтер по сети. Служба спулера более подробно рассматривается в главе 2. Платформенные подсистемы На ранних стадиях эволюции Windows NT существовало не так уж много программ Win32, написанных специально для этой системы. По этой причине в Microsoft решили, что платформа Windows NT должна поддерживать возможность запуска программ DOS, Winl6, OS/2, POSIX (с интерфейсом в стиле UNIX) и Win32. Для запуска столь разных программ в Windows NT/2000 существует несколько разных платформенных подсистем. Платформенная подсистема (environment subsystem) представляет собой набор процессов и DLL, обеспечивающих некое подмножество функций операционной системы для прикладных программ, написанных для конкретной подсистемы. В каждой подсистеме имеется один процесс, управляющий ее взаимодействием с операционной системой (сервер). Отображение DLL на процессы приложения позволяет взаимодействовать с процессом подсистемы или напрямую с ядром через системные функции ОС. Постепенно подсистема Win32 занимает главное место среди подсистем, поддерживаемых семейством Windows NT/2000. Все операции управления окнами и графического вывода в пользовательском адресном пространстве выполняются через сервер подсистемы Win32 (csrss.exe). Прикладным программам для выполнения этих операций приходится обращаться к процессу подсистемы через механизм LPC, что отрицательно влияет на быстродействие. Начиная с Win-
82 Глава 1. Основные принципы и понятия dows NT 4.0 разработчики Microsoft переместили в DLL режима ядра, win.32k.sys, основную часть платформенной подсистемы Win32 вместе со всеми драйверами графических устройств. Библиотеки DLL подсистемы Win32 очень хорошо знакомы всем программистам Windows. Библиотека kernel32.dll управляет виртуальной памятью, вводом-выводом, кучей, процессами, программными потоками и синхронизацией; user32.dll обеспечивает управление окнами и передачу сообщений; gdi32.dll реализует графический вывод и печать; advapi32.dll отвечает за операции с реестром и т. д. Библиотеки DLL подсистемы Win32 обеспечивают прямой доступ к системным функциям ядра ОС и предоставляют полезные дополнительные возможности, не поддерживаемые системными функциями ОС. Примером возможностей Win32 API, не поддерживаемых напрямую в win.32k.sys, являются расширенные метафайлы (EMF). Работа двух других платформенных подсистем — OS/2 и POSIX — основана на использовании подсистемы Win32, хотя при первоначальном проектировании Windows NT они рассматривались наравне с Win32. Теперь платформенная подсистема Win32 превратилась в неотъемлемую, постоянно работающую часть операционной системы. Подсистемы OS/2 и POSIX запускаются лишь в том случае, если это необходимо для работы конкретных программ. Итоги В этой главе кратко описаны основы Windows-программирования на языке C++. Мы рассмотрели примеры простейших программ на C++, а также познакомились с языком ассемблера и средой программирования, форматом исполняемых файлов Win32 и архитектурой операционных систем Microsoft Windows NT/2000. Начиная с главы 2, основное внимание будет сосредоточено на программировании графики в Windows NT/2000. Впрочем, при необходимости мы будем создавать мелкие вспомогательные инструменты, упрощающие наши исследования. Полезную информацию о рассматриваемых здесь темах можно найти в Интернете — например, на web-страницах www.codeguru.com, www.codeproject.com и www.msdn.microsoft.com. На web-странице www.systeminternals.com имеется немало содержательных статей, утилит и примеров программ, которые помогут вам в исследованиях системы. Компания Intel открыла web-страницу для разработчиков, на которой можно больше узнать о процессорах Intel, оптимизации программ, шине AGP, компиляторе C++ от Intel и т. д. web-страница компании Adobe предназначена для всех, кто обладает необходимыми талантами для создания подключаемых модулей (plug-ins) и фильтров к приложениям Adobe. Свои web-страницы для разработчиков есть и у многих производителей видеоадаптеров. Примеры программ Полные тексты программ, приведенных в этой главе, находятся на прилагаемом компакт-диске (табл. 1.5).
Итоги 83 Таблица 1.5. Примеры программ из главы 1 Каталог проекта Описание Sample\ChartJ)l\Hellol Sample\Chart_01\Hello2 Sample\Chart_01\Hello3 Samp!e\Chart_01\Hello4 Sample\Chart_01\GDISpeed Sample\Chart__01\SetProc Программа «Hello, World» — запуск браузера Программа «Hello, World» — вывод текста на рабочем столе Программа «Hello, World» — простой класс окна Программа «Hello, World» — размывание текста средствами DirectDraw Использование ассемблера для хронометража Простой перехват функций API посредством модификации каталогов импорта/экспорта в РЕ-файле
Глава 2 Архитектура графической системы Windows Графическая система является неотъемлемой частью всех современных операционных систем, которые все шире используют интуитивно понятный графический интерфейс для того, чтобы стать доступнее для среднего пользователя. К их числу принадлежит и Windows NT/2000. Глава 1 завершилась кратким описанием архитектуры операционной системы Windows NT/2000. Эта глава посвящена графической системе как отдельному компоненту операционной системы. В ней рассматриваются компоненты графической системы и связи между ними — GDI API, DirectDraw API, OpenGL API, графический механизм, драйверы экрана и печати, система печати и спулинга. Мы также проанализируем вертикальную структуру графической системы Windows, а именно системные DLL пользовательского режима, обеспечивающие вызов системных функций, механизм режима ядра и драйверы графических устройств, создаваемые независимыми фирмами. Глава завершается примером простого драйвера принтера, который генерирует выходные данные в виде HTML-страницы. Компоненты графической системы Windows Интерфейс прикладных программ Windows — а проще говоря, Windows API — представляет собой громадный набор взаимосвязанных функций, предоставляющих различные услуги прикладным программам. С точки зрения программиста, Win32 API делится на несколько групп в соответствии с типом предоставляемых услуг. О Базовые функции Windows, обычно называемые сервисом ядра, — отладка, обработка ошибок, библиотеки динамической компоновки (DLL), процессы,
Компоненты графической системы Windows 85 потоки, файлы, ввод-вывод, межпроцессные взаимодействия, безопасность и т. д. О Функции пользовательского интерфейса, обычно называемые пользовательским сервисом, — управление окнами, очереди сообщений, диалоговые окна, элементы управления, стандартные элементы управления, стандартные диалоговые окна, ресурсы, пользовательский ввод, командный интерпретатор и т. д. О Графические и мультимедийные функции — управления цветом, DirectX, GDI, Video for Windows, Still Image, OpenGL, Windows Media и т. д. О Функции COM, OLE и ActiveX — COM (Component Object Model), автоматизация, Microsoft Transaction Server, OLE (Object Linking and Embedding) и т. д. О Функции баз данных и обмена сообщениями — DAO (Data Access Objects), SQL Server, MAPI (Messaging API) и т. д. О Сетевые и распределенные функции — Active Directory, очередь сообщений, сетевые средства, RPC, маршрутизация и удаленный доступ, сервер SNA (Systems Network Architecture), TAPI (Telephony API) и т. д. О Функции Интернета, интра- и экстрасетей — Internet Explorer, Microsoft Agent, NteShow, сценарии, Site Server и т. д. О Функции настройки и управления системой — конфигурация, настройка, управление системой и т. д. Каждая группа функций поддерживается определенным набором компонентов операционной системы. К их числу относятся DLL платформенной подсистемы Win32, драйверы пользовательского режима, системные функции и драйверы режима ядра. По каждой группе можно было бы написать объемистую книгу с информацией, необходимой для ее эффективного использования. Группа графических и мультимедийных функций Win32 API настолько велика, что для ее описания на должном уровне потребовалось бы несколько толстых книг. Книга, которую вы сейчас читаете, посвящена очень важному подмножеству этой группы — а именно, GDI и DirectDraw. Давайте поближе познакомимся с компонентами, обеспечивающими работу графических и мультимедийных функций. Графический прикладной интерфейс Win32 реализован на нескольких платформах — это Windows 95/98, WinCE, Windows NT и новая система Windows 2000. Раньше системы семейства NT отличались лучшей поддержкой GDI, поскольку в них использовались полноценные 32-разрядные реализации, а системы семейства Windows 95 обеспечивали лучшую поддержку игрового программирования. Однако новая операционная система Windows 2000 взяла все лучшее из обоих семейств. В Windows 2000 были внесены существенные изменения по поддержке аппаратного ускорения DirectX/OpenGL, появился новый интерфейс STI (Still Image), драйверы принтеров пользовательского режима и т. д. В этой книге наше внимание будет сосредоточено на архитектуре графической и мультимедийной системы Windows 2000, причем время от времени будут подчеркиваться ее отличия от Windows 95/98 и Windows NT 3.5/4.0.
86 Глава 2. Архитектура графической системы Windows При взгляде на рис. 2.1 становится видно, что графическая и мультимедийная система Windows NT/2000, как и операционная система в целом, состоит из нескольких уровней. Верхний блок изображает прикладные программы, взаимодействующие с набором 32-разрядных системных DLL пользовательского режима через Win32 API. Уровень системных DLL содержит уже знакомые библиотеки: gdi32.dll (графический интерфейс), user32.dll (пользовательский интерфейс и управление окнами), kernel32.dll (услуги базовых служб Windows) и т. д. Большинство модулей этого уровня поддерживается операционной системой, но некоторые компоненты имеют поддержку со стороны драйверов пользовательского режима, реализованных производителями оборудования. Ниже расположен шлюз для вызова системных функций, через который вызываются обработчики, находящиеся в части режима ядра. Исполнительная часть Windows NT/2000, работающая в адресном пространстве ядра, предоставляет общую поддержку графической и мультимедийной системы в виде графического механизма, диспетчера ввода-вывода, драйвера видеопорта и т. д. Она нуждается в поддержке со стороны драйверов устройств, предоставленных разработчиками оборудования, которые взаимодействуют с различными аппаратными компонентами (шиной, видеоадаптером, принтером и т. д.) через уровень HAL. Пользовательские приложения Win32 о О Драйвер принтера Спулер Процессор, монитор, провайдер b 9 5 Q. (D CQ >S га Q- о О) га Е со с; 3 га а. Вызов системной функции (О о "О г Win о о о ■о > _| О с о Q- О MCD о. 8 >S Дра Пользовательский режим Системные функции Режим ядра Диспетчер ввода-вывода Видеопорт (AGP) N Драйвер 11 шины Видеоминипорт (VPE, DxApi, TV) Драйвер Still Image Сервер MCD Графический механизм (DirectDraw, DDML) Драйвер экрана (DirectDraw, Direct3D, MCb) Шрифтовой драйвер Шрифты Драйвер принтера Драйвер порта принтера HAL Шина, монитор, камера, сканер, принтер и сетевое оборудование Рис. 2.1. Архитектура графической и мультимедийной системы в Windows 2000 Теперь «пройдемся» по части пользовательского режима по горизонтали. GDI (Graphics Device Interface, интерфейс графических устройств) и ICM (Image Color Management, система управления цветом) обеспечивают аппаратно-неза-
Компоненты графической системы Windows 87 висимый интерфейс графического программирования для приложений. При выводе на принтер GDI общается с драйвером принтера, который в Windows 2000 может работать в пользовательском режиме. Работа драйверов принтеров пользовательского режима в значительной степени зависит от функций, поддерживаемых графическим механизмом. Заданиями печати управляет специальный системный процесс — спулер. В его работе используются специализированные компоненты, которые могут модифицироваться производителем оборудования, в том числе процессор печати (print processor), монитор печати (print monitor) и провайдер печати (print provider). DirectX добавляет в эту схему относительно новый набор системных DLL Win32, реализующих СОМ-интерфейсы DirectX. Фактическое взаимодействие с реализацией DirectX в адресном пространстве ядра происходит через GDI. В DirectX входят следующие компоненты: DirectDraw, DirectSound, Direct- Music, Directlnput, DirectPlay, DirectSetup, AutoPlay и Direct3D. В этой книге из всех компонентов DirectX рассматривается только DirectDraw. Ниже GDI и DirectDraw будут описаны существенно более подробно. А пока давайте кратко познакомимся с другими компонентами, которые не войдут в книгу. Мультимедиа Мультимедийная часть Win32 API является развитием мультимедиа-средств, впервые появившихся в Windows 3.1. К их числу принадлежит MCI (Media Control Interface), аудиовывод, операции ввода-вывода в мультимедийных файлах, управление джойстиком и мультимедийные таймеры. Интерфейс MCI управляет всеми носителями информации с линейным воспроизведением; в нем предусмотрены функции загрузки, паузы, воспроизведения, записи, остановки, продолжения и т. д. Поддерживаются три типа аудиовывода: CD-аудио, MIDI (Musical Instrument Digital Interface) и оцифрованный (waveform) сигнал. Мультимедийные функции Win32 определяются в файле mmsystem.h; библиотека импортируемых функций содержится в winmm.lib и winmm.dll. Работа winmm.dll основана на устанавливаемых драйверах устройств пользовательского режима для каждого мультимедийного устройства. Главной экспортируемой функцией драйвера мультимедиа-устройства, который представляет собой 32-разрядную DLL, является функция DriverProc, обрабатывающая сообщения от системы мультимедиа - DRV_0PEN, DRVJNABLE, DRV_C0NFIGURE, DRV_CL0SE и т. д. ПРИМЕЧАНИЕ Чтобы узнать, какие мультимедийные драйверы доступны, откройте файл mmdriver.inf в каталоге %SystemRoot%\system32. В нем перечислено около десятка драйверов. Например, драйвер mmdrv.dll обеспечивает низкоуровневые операции с оцифрованным сигналом, поддержку MIDI и AUX (Auxiliary Output Device, дополнительного устройства вывода). Диспетчер сжатия аудиоданных (Microsoft Audio Compression Manager) находится в файле msacm32.drv, а файл ir32_32.dll содержит кодек Indeo — компрессор/декомпрессор видеоданных, разработанный компанией Intel и использующий алгоритм сжатия оцифрованного сигнала с поддержкой ММХ.
88 Глава 2. Архитектура графической системы Windows Возможно, вас интересует, как драйверы пользовательского режима могут управлять устройствами? Сами по себе не могут. В работе мультимедийных драйверов пользовательского режима используется специальный класс драйверов режима ядра, называемых потоковыми драйверами ядра (kernel streaming drivers), способных управлять оборудованием напрямую. Мультимедийная часть Win32 постепенно замещается соответствующими компонентами DirectX, обладающими расширенными возможностями и более высоким быстродействием. Например, DirectSound обеспечивает запись и воспроизведение звука в формате оцифрованного сигнала; DirectMusic позволяет сохранять и воспроизводить цифровые сэмплы, в том числе и в формате MIDI; Directlnput поддерживает широкий круг устройств ввода, включая мышь, клавиатуру, джойстик и другие игровые манипуляторы, а также устройства с активной обратной связью (force-feedback). Одна из мультимедийных функций, часто используемых общими приложениями Windows, предназначена для создания таймеров с высоким разрешением — это функция timeGetTimeO. Она обеспечивает точность до 1 миллисекунды, что обычно превышает точность функции GetTickCount (1 миллисекунда в Windows 95, 15 миллисекунд в Windows NT/2000). В программах Win32 функция QueryPerformanceCounter обеспечивает точность, на порядки превышающую точность функций timeGetTime и GetTickCount (если процессор поддерживает счетчики высокого разрешения). На компьютерах с процессором Intel Pentium счетчиком высокого разрешения является счетчик тактов процессора, упоминавшийся в главе 1. Следовательно, на 200-мегагерцовом процессоре измерения производятся с точностью до 5 наносекунд. Впрочем, вызов QueryPerformanceCounter такой точности pie обеспечивает; для чтения счетчика используется обращение к ядру ОС через системную функцию. Video for Windows Как и все мультимедийные средства Win32, Video for Windows имеет долгую историю, начинающуюся в эпоху Windows 3.1. Video for Windows (VFW) обеспечивает поддержку Win32 API для обработки видеоданных. Точнее говоря, поддерживается AVI (Audio-Video Interleaved), операции чтения, записи, позиционирования и редактирования файлов, диспетчер сжатия видеоданных, видеозахват и DrawDib API. Многие возможности VFW были заменены DirectShow — одним из компонентов DirectX. DrawDib API содержит такие функции, как DrawDibDraw, DrawDibGetBuffer, Draw- DibUpdate и т. д. По своим возможностям этот интерфейс API напоминает функцию Win32 StretchDIBits, но он поддерживает такие дополнительные возможности, как выбор нужного декодера, потоковую обработку данных и (предположительно) более высокое быстродействие. Первые две возможности обеспечиваются устанавливаемыми драйверами мультимедиа-устройств, обслуживающими разные потоки данных; третья возможность, конечно, не идет в сравнение с возможностями DirectDraw. В Win32 поддержка VFW обеспечивается заголовочным файлом vfw.h, библиотечным файлом vfw32.lib и DLL msvfw32.dll. Реализация VFW основана на использовании мультимедийной части Win32.
Компоненты графической системы Windows 89 ПРИМЕЧАНИЕ Функции DrawDib все еще рекламируются как средство быстрого вывода графических изображений, не использующее GDI и записывающее данные прямо в видеопамять. Звучит неплохо, но сейчас это уже перестает быть правдой, особенно в Windows NT/2000. В Windows NT/2000, где прямой доступ к видеопамяти возможен только через драйвер DirectX режима ядра, DrawDibDraw выводит DIB при помощи функции GDI и потому работает медленнее, чем функция вывода DIB из GDI. Still Image Still Image (STI) — новый интерфейс Microsoft для получения цифровых статических изображений с таких устройств, как сканеры и цифровые камеры. Он доступен только в Windows 98 и Windows 2000. Разумеется, STI заменяет более старый стандарт TWAIN. (Кстати, интересно, почему его не назвали Direct Image? Наверное, скоро назовут.) Относительная новизна этого стандарта позволила Microsoft такую роскошь, как реализация STI с использованием СОМ-интерфей- сов вместо традиционных функций Win32 API. Microsoft STI состоит из монитора событий, поставляемых производителем оборудования мини-драйверов пользовательского режима, и панели управления сканером или камерой. Монитор событий на системном уровне следит за устройствами ввода статических изображений и их событиями. Кроме того, он ведет список зарегистрированных приложений по обработке статических изображений, которые могут автоматически запускаться при обнаружении события. Мини-драйвер обнаруживает события от конкретного устройства и оповещает о происходящем монитор событий. Кроме того, он передает данные изображения из драйвера режима ядра в пользовательский режим. При помощи панели управления сканером/камерой пользователь ассоциирует устройства ввода статических изображений с приложениями, в которых предусмотрена их поддержка. Приложение панели управления сканером/камерой (sticpl.dll), монитор (stimon.dll, stisvc.exe) и приложения обработки статических изображений — все они используют СОМ-объект STI (CLSIDSti), реализующий интерфейс IStill Image, экземпляр которого создается функцией StiCreatelnstance. СОМ-объект STI реализуется в библиотеке sti.dll, использующей СОМ-интерфейсы IStiDevice и IStiDeviceControl для управления мини-драйверами. В Windows 98/2000 STI API поддерживается заголовочным файлом sti.h, библиотечным файлом sti.lib, упомянутыми выше DLL и ЕХЕ, а также драйверами соответствующих устройств пользовательского режима и режима ядра. OpenGL Последним компонентом пользовательского режима, изображенным на рис. 2.1, является OpenGL — стандарт программирования двумерной/трехмерной графики, разработанный в Silicon Graphics, Inc. Его главной целью является визуализация двумерных/трехмерных объектов в кадровом буфере (frame buffer). OpenGL позволяет программисту описывать объекты в виде совокупности вершин, каждая из которых определяется координатами, цветом, нормалью, координатами текстуры и флагом края (edge flag). Таким образом, при помощи функ-
90 Глава 2. Архитектура графической системы Windows ций OpenGL можно описывать отдельные точки, отрезки линий и трехмерные поверхности. Графические средства OpenGL позволяют задавать трансформации, коэффициенты уравнений освещенности, способы сглаживания (antialiasing) и операторы обновления пикселов. Перед конечным воспроизведением данных в буфере кадра процесс визуализации OpenGL проходит несколько стадий. На стадии вычислений кривые и поверхности аппроксимируются при помощи полиномиальных команд. На второй стадии (операции с вершинами и примитивная сборка) выполняются преобразования, вычисляется освещенность и происходит отсечение вершин. На третьей стадии (растеризации) генерируется последовательность адресов буфера кадра и связанных с ними значений. На последней стадии (фрагментарных операций) в окончательном буфере кадра производится буферизация глубины, выполняется альфа-наложение, применение масок и другие операции уровня пикселов. Как видно на примере Windows NT/2000, компания Microsoft добавила в свою реализацию OpenGL некоторые дополнительные возможности. Реализуется полный набор команд OpenGL, библиотеки OpenGL Utility (GLU) и OpenGL Programming Guide Auxiliary Library, расширение для окна (Window extension, WGL), формат пикселов уровня окна и двойная буферизация. OpenGL использует три заголовочных файла в подкаталоге gl каталога заголовочных файлов вашего компилятора: gl.h, glaux.h и glu.h. WGL определяется в заголовочном файле GDI wingdi.h. OpenGL использует библиотечные файлы opengl.lib и gdJ32.lib, а также runtime-DLL opengl32.dll и gdJ32.dll. Для повышения быстродействия OpenGL реализация позволяет драйверам, предоставленным производителями оборудования, выполнять специализированную оптимизацию и производить прямой доступ к оборудованию. Для удобства работы драйверов OpenGL Microsoft поддерживает архитектуру мини-клиента (MCD). OpenGL.dll загружает mcd32.dll — клиентскую DLL, предоставляемую операционной системой, и необязательный драйвер OpenGL пользовательского режима, предоставляемый производителем оборудования. Чтобы найти свой драйвер OpenGL, проведите в реестре поиск строки OpenGLDrivers. Клиент MCD и драйвер OpenGL пользовательского режима используют функцию GDI Ext- Escape для отправки команд графическому механизму и драйверу в режиме ядра. Для поддержки MCD-части необходим драйвер экрана, обеспечивающий оптимизацию OpenGL, с поддержкой сервера MCD уровня ядра в mcdsrv32.dll. В наши дни производители видеоадаптеров довольно часто поддерживают аппаратное ускорение DirectDraw, Direct3D и OpenGL в одном пакете. Всегда интересно видеть, как разные архитектуры (в данном случае GDI и OpenGL) используются для похожих целей. Первоначально GDI проектировался как простой интерфейс графического программирования, ориентированный на стандартное оборудование РС-инду- стрии того времени — а именно, 16- и 256-цветные видеоадаптеры EGA и VGA, а также черно-белые принтеры. Постепенно в GDI добавилась поддержка аппа- ратно-независимых растров, цветных принтеров, векторных шрифтов, шрифтов TrueType и ОрепТуре, 32-разрядного пространства логических координат, градиентных заливок, альфа-каналов, поддержка работы на нескольких мониторах или терминалах и т. д. Эволюция GDI продолжается и сейчас. GDI работает как на миниатюрных устройствах типа блокнотных компьютеров (palmtop), так
Компоненты графической системы Windows 91 и на мощных рабочих станциях. Основными целями при проектировании GDI (и Windows API в целом) были быстродействие, обратная совместимость и независимость от оборудования. С другой стороны, OpenGL проектировался как высокопроизводительный пакет двумерной/трехмерной графики для построения реалистических изображений. Из-за интенсивного использования вычислений с плавающей точкой для OpenGL необходим производительный компьютер с большим объемом памяти и мощным процессором. Такие эффекты, как освещение, размывание, сглаживание и туман на мониторе VGA с 256 цветами будут неэффективны. Хотя интерфейс OpenGL проектировался как аппаратно- независимый, он в первую очередь ориентирован на воспроизведение изображения в кадровом буфере, поэтому печать на принтерах высокого разрешения связана с некоторыми сложностями. Кстати, в Windows NT/20000 GDI предлагает решение проблем с печатью в OpenGL — команды OpenGL записываются в специальном формате EMF, а затем воспроизводятся на принтере высокого разрешения. Из-за сложности построения двумерных/трехмерных изображений OpenGL является графическим интерфейсом более высокого уровня, чем GDI. Программы OpenGL обычно описывают сцену в трехмерном пространстве при помощи вершин, отрезков линий и многоугольных поверхностей, определяют атрибуты, источники света и углы просмотра, после чего поручают дальнейшую техническую работу механизму OpenGL. В GDI приложение конструирует изображение, вызывая нужную последовательность команд с правильными параметрами. Если вы захотите создать трехмерное изображение, GDI не поможет в вычислении глубины изображения и удалении скрытых поверхностей. Даже непосредственный режим (Immediate Mode) Direct3D по сравнению с OpenGL относится к низкоуровневым интерфейсам. Windows Media Windows Media является новым дополнением графической/мультимедийной системы Win32, состоящим из Windows Media Services, Windows Media Encoder, Windows Media Player Control и Windows Media Format SDK. Компонент Windows Media Services содержит элементы ActiveX и СОМ-ин- терфейсы, позволяющие авторам Web-страниц использовать потоковую аудио- и видеоинформацию, а также управлять ее широковещательной рассылкой. Windows Media Encoder прежде всего отвечает за преобразование разных типов мультимедийного содержимого в потоки или файлы формата Windows Media, которые затем доставляются средствами Windows Media Services. Файлы-контейнеры ASF (Advanced Streaming Format) могут содержать данные, соответствующие разным форматам исходного носителя. Windows Media Player Control — элемент ActiveX для воспроизведения мультимедиа в приложениях и Web-страницах. Средства пакета Windows Media Format SDK обеспечивают возможность чтения, записи и редактирования файлов Windows Media (аудио и видеоданных, а также сценариев).
92 Глава 2. Архитектура графической системы Windows Компоненты режима ядра Графические и мультимедийные компоненты пользовательского режима могут взаимодействовать с ядром операционной системы двумя способами. В GDI, DirectDraw, Direct3D и OpenGL вызовы пользовательского режима проходят через библиотеку gdi32.dll, предоставляющую интерфейс к сотням системных функций. Для взаимодействия с драйверами видеопорта и мультимедийными драйверами вызовы пользовательского режима используют обычный интерфейс API файлового ввода-вывода, входящий в базовый сервис Windows. Вызовы системных функций файлового ввода-вывода обрабатываются диспетчером ввода-вывода исполнительной части режима ядра, который обращается к соответствующим драйверам. Вызовы GDI, DirectDraw, Direct3D и OpenGL проходят через графический механизм, который передает их драйверам конкретных устройств. К числу модулей операционной системы относятся ntoskrnl.exe (передача системных функций, диспетчер ввода-вывода), win32k.sys (графический механизм), mcdsvr32.dll (сервер MCD) и hal.dll (HAL). Исполнительная часть ядра Windows NT/2000, ntoskrnl.exe, является самой важной составляющей ядра ОС. В графической системе она в основном отвечает за передачу вызовов функций графической системы графическому механизму, поскольку в последнем используется тот же механизм вызова системных функций, что и другие системные функции. HAL предоставляет в распоряжение драйвера графического устройства средства для таких операций, как чтение и запись аппаратных регистров. Благодаря этому другие компоненты ядра в меньшей степени зависят от платформы. За дополнительными сведениями об исполнительной части и HAL обращайтесь к главе 1. Драйверы режима ядра Графическая и мультимедийная система Windows NT/2000 работает с конечными устройствами через несколько уровней драйверов, предоставленных производителем оборудования. Самую важную роль играет драйвер экрана, который должен обеспечивать поддержку GDI, DirectDraw, Direct3D и MCD для OpenGL. Драйвер экрана всегда работает в сочетании с мини-драйвером видеопорта, который, в частности, управляет аппаратными портами. Мини-драйвер видеопорта также необходим для поддержки VPE (расширение видеопорта для DirectX) и мини-порта DxApi. Другой, менее известной разновидностью драйверов является шрифтовой драйвер, поставляющий глифы шрифтов графическому механизму. Например, программа ATM (Adobe Type Manager) использует в качестве шрифтового драйвера библиотеку atmfd.dll. Файлы шрифтов загружаются в адресное пространство ядра графическим механизмом и шрифтовыми драйверами. Драйвер принтера напоминает драйвер экрана с несколькими дополнительными функциями. В отличие от других драйверов драйверы принтеров не взаимодействуют со своим устройством (то есть принтером) напрямую. Вместо этого они передают поток данных, готовых к печати, спулеру в пользовательском
Архитектура GDI 93 режиме. Спулер передает данные процессору печати, а затем монитору печати, который использует средства файлового ввода-вывода для обращения к драйверу ввода-вывода режима ядра. Windows 2000 позволяет реализовать драйвер принтера как в виде DLL пользовательского режима, так и в виде DLL режима ядра. К числу других драйверов режима ядра, используемых графической и мультимедийной системами, принадлежат драйверы мультимедиа-устройств (например, драйвер звуковой карты) и устройств ввода статических изображений (драйвер сканера или цифровой камеры). Потоковые драйверы ядра (аудио- и видеоданные, видеозахват) и драйверы устройств ввода статических изображений подробно описаны в Windows 2000 DDK. Качество драйверов устройств режима ядра имеет принципиальное значение для стабильности всей операционной системы. Драйвер режима ядра обладает доступом для чтения и записи ко всему адресному пространству ядра и всеми привилегированным инструкциям процессора. Ошибки в драйвере режима ядра могут легко привести к порче важных структур данных, поддерживаемых операционной системой, и сбою всей системы. Следовательно, любые приложения, содержащие драйверы режима ядра (например, антивирусные программы), должны тщательно тестироваться для уменьшения риска. Компания Microsoft включила в поставку Windows 2000 утилиту проверки драйверов (verifier.exe в каталоге system), которая упрощает процесс проверки драйверов разработчиками. В этом разделе была описана архитектура графической и мультимедийной систем Windows NT/2000 — сложная, но имеющая четкую структуру иерархия DLL, драйверов пользовательского режима, DLL режима ядра и драйверов режима ядра. Значительно сложнее разобраться в логике ее работы — например, во время печати управление несколько раз передается между кодом пользовательского режима и кодом режима ядра. За подробностями следует обращаться к MSDN, DDK и другой справочной документации, а наше внимание будет сосредоточено на нескольких компонентах, которые используются в большинстве обычных приложений Windows. В оставшихся разделах этой главы мы посмотрим, как устроены GDI, DirectDraw, драйвер экрана и система печати, включая драйвер принтера. Архитектура GDI Прикладной интерфейс GDI (Graphics Device Interface) был разработан компанией Microsoft для того, чтобы предоставить прикладным программам аппарат- но-независимый интерфейс к графическим устройствам — экрану монитора, принтеру, плоттеру или факсу. Реализация GDI для Win32 API, поддерживаемая в Windows 95, 98, NT и 2000, ушла далеко вперед от реализации в Windows 3.1. В операционных системах Windows NT/2000 имеет место полноценный 32- разрядный графический механизм, поэтому GDI API в этих системах обладает большими возможностями, чем в Windows 95/98, которые используют 16-разрядный графический механизм, унаследованный от Windows 3.1. Впрочем, есть
94 Глава 2. Архитектура графической системы Windows и исключения: Windows 95 поддерживает ICM, a Windows NT 4.0 — нет. Новая система Windows 2000 поддерживает ICM версии 2.0. В Windows 98 в GDI даже были добавлены такие новые возможности, как альфа-наложение. Microsoft планирует выпустить новое расширение Win32 GDI с кодовым названием GDI+, которое обеспечивает улучшенный объектно-ориентированный интерфейс к графической системе и обладает гораздо большими возможностями. Функции, экспортируемые из GDI32.DLL GDI поддерживает сотни графических функций, вызываемых Windows-программами. Большинство этих функций экспортируется библиотекой gdi32.dll подсистемы Win32. Модуль управления окнами, user32.dll, интенсивно использует функции GDI для вывода меню, значков, полос прокрутки и рамок окон. Некоторые графические функции экспортируются из user32.dll, что делает их доступными для прикладных программ. В Windows 2000 gdi32.dll экспортирует 543 точки входа. Для просмотра функций, экспортируемых модулем, проще всего воспользоваться утилитой dumpbin, входящей в поставку DevStudio. Ниже приведен фрагмент выходных данных команды dumpbin gdi32.dll/export. 543 number of functions 543 number of names ordinal hint RVA name 1 О 00027В89 AbortDoc 2 1 00027У19 AbortPath 3 2 0001FE0B AddFontMemResourceEx 4 3 0001CE3D AddFontResourceA 5 4 0001FCCC AddFontResourceExA 6 5 00020095 AddFontResourceExw 7 6 0001FE4F AddFontResourceTracking 8 7 00020085 AddFontResourceW 9 8 000264DE AngleArc 533 214 00028106 WidenPath 534 215 00031B4C XFORMOBJ_bApplyXForm 535 216 0000F9FE XFORMOBJJGetXform 536 217 00031A98 XLATE0BJ_cGetPalette 537 218 00031AB4 XLATEOBJ_hGetColorTransform 538 219 00031AA6 XLATEOBJJXlate 539 21A 0002BD2A XLATE0BJ_piVector 540 21B 000014F9 blnitSystemAndFontDirectoriesW 541 21C 0000143B bMakePathNameW 542 21D 000015AA cGetTFFromFOT 543 21E 00026A1F gdiPIaySpoolStream Группы функций GDI При таком количестве функций необходимо как-то классифицировать Win32 GDI API, чтобы понять структуру GDI. В MSDN функции GDI API разбиваются на 17 групп, дающих неплохое представление о функциональных возможностях GDI.
Архитектура GDI 95 О Растры. Функции создания и отображения аппаратно-зависимых растров (DDB, Device-Dependent Bitmaps), аппаратно-независимых растров (DIB, Device-Independent Bitmaps), DIB-секций, пикселов и заливок. О Кисти. Функции создания и модификации объектов кистей в GDI. О Отсечепие. Функции, определяющие границы области вывода в контексте устройства. О Цвет. Управление палитрой. О Координаты и преобразования. Функции работы с режимами отображения, функции отображения логических координат в физические, а также функции мировых преобразований (world transformation). О Контексты устройств. Функции создания контекстов устройств (Device Context, DC), чтения/записи атрибутов и выбора объектов GDI. О Заполненные фигуры. Функции вывода замкнутых областей и их периметров. О Шрифты и текст. Функции установки и перечисления шрифтов в системе, а также вывода текстовых строк. О Линии и кривые. Функции вывода прямых линий, эллиптических дуг и кривых Безье. О Метафайлы. Функции построения и воспроизведения метафайлов формата Windows или расширенных метафайлов. О Вывод на несколько мониторов. Функции, позволяющие использовать несколько мониторов на одном компьютере. Эти функции экспортируются из user32.dll. О Графический вывод. Функции, управляющие обработкой сообщения о перерисовке и измененной областью окна. Некоторые из этих функций экспортируются из user32.dll. Э Траектории. Функции для объединения последовательности линий и кривых в объект GDI, называемый траекторией (path), и использования этого объекта при выводе. О Перья. Функции для работы с атрибутами вывода линий. О Печать и спулер. Функции передачи команд графического вывода на такие устройства, как принтеры и плоттеры, и управления этим классом задач. Функции спулера обеспечиваются спулером Win32, содержащим несколько системных DLL и модулей, модифицируемых производителями оборудования. О Прямоугольники. Функции для работы со структурой RECT. Экспортируются из user32.dll. Э Регионы. Функции для создания из серии точек объекта GDI, называемого регионом (region), и выполнения операций с этим объектом. Кроме хорошо документированных функций, входящих в классификацию, в GDI входит немало других, малоизвестных функций. Одни документируются в DDK; другие не документируются, но используются системными DLL; третьи не документируются и не используются. Ниже приведена примерная классификация таких функций. О Драйвер принтера пользовательского режима. Функции поддержки новой возможности Windows 2000 — драйверов принтеров пользовательского режима.
96 Глава 2. Архитектура графической системы Windows В сущности, эти вспомогательные функции для обращения к точкам входа механизма GDI режима ядра, документированным в DDK. Например, драйвер принтера пользовательского режима в Windows 2000 может вызвать функцию GDI EngTextOut, которая реализуется одноименной функцией win32k.sys. О OpenGL. Функции поддержки WGL — например, SwapBuffers, SetPixel Format и GetPixel Format, описанные в документации OpenGL для Windows. О EUDC. Функции поддержки символов, определяемых пользователем (end- user-defined characters); при помощи этих функций пользователи могут добавлять в шрифты новые символы. Функции EUDC документируются в разделе International Features Platform SDK, в категории Window Base Services. GDI экспортирует такие функции, как EnableEUDC, EudcLoadLinkW и т. д. О Поддержка других системных DLL. Функции, используемые только другими системными DLL. Например, user32.dll вызывает функции GDI GdiDllInitia- lize, GdiPrinterThunk, GdiProcessSetup и т. д.; ddraw.dll вызывает GdiEntryl, GdiEntry2 и т. д.; служба спулера spoolsrv.exe вызывает GdiGetSpool Message и GdilnitSpool; wow32.dll вызывает GdiQueryTable и GdiCleanCacheDC. О Прочие недокументированные функции. Недокументированные функции, об использовании которых ничего не известно, — например, GdiConvertDC, GdiCon- svertBitmap, SetRelAbs и т. д. Рисунок 2.2 иллюстрирует наше представление об архитектуре клиентской стороны GDI. Верхний уровень соответствует категориям функций (документированные или недокументированные); под ним находятся сотни функций, разделенные на основные группы. На нижнем уровне расположены вызовы системных функций. Документированные функции Win32 GDI API Недокументированные или частично документированные функции 2L Вызовы системных функций GDI Рис. 2.2. Группы функций GDI
Архитектура GDI 97 Вызовы системных функций GDI По сравнению с DLL разных подсистем Win32 модуль gdi32.dll относительно невелик. В Windows 2000 размер gdi32.dll составляет всего 223 килобайта — меньше, чем comdig.32.dll, wow32.dll, icm32.dll, advapi32.dll, user32.dll и kernel32.dll. Это объясняется тем, что большинство возможностей GDI реализуется обращениями к механизму GDI через системные функции Windows NT/2000. Microsoft не предоставляет открытой документации по системным функциям Windows NT/2000. Хотя существуют утилиты, отображающие часть системных вызовов (Numega SoftICE/W), а также независимая документация (статья Марка Руссиновича по адресу www.sysinternals.com/ntdll.htm), не существует никаких официальных документов по системным функциям графической системы или управления окнами, или по системным функциям, поддерживаемым графическим механизмом. При помощи отладочных символических файлов и Image Help API нетрудно написать программу для перечисления всех символических имен в DLL — например, в gdi32.dll. К числу этих символических имен будут принадлежать имена экспортируемых функций, имена импортируемых функций и даже имена глобальных переменных. В Image Help API входит функция SymEnumerateSymbols, которая позволяет вызвать заданную пользователем функцию косвенного вызова (callback function) для каждого символического имени в модуле. Зная символическое имя, можно определить его адрес в образе модуля и прочитать двоичный код, начинающийся с этого адреса. Сравнивая этот код с шаблоном вызова системной функции, можно найти все функции GDI, из которых вызываются системные функции. Программа SysCall делает все, о чем говорится выше, и выводит список всех функций, использующих системные функции DLL подсистемы Win32. Вы можете вывести информацию о вызовах системных функций из user32.dll, ntdll.dll или gdi32.dll. Ниже приведен фрагмент списка из 351 (для Windows 2000) вызова системной функции из gdi32.dll, отсортированного по индексам системных функций. syscal1(0x1000. 1) gdi32.dllINtGdiAbortDoc syscall(0x1001. 1) gdi32.dllINtGdiAbortPath syscal1(0x1002. 6) gdi32.dl1!NtGdiAddFontResourceW syscal1(0x1003. 4) gdi32.dl1!NtGdiAddRemoteFontToDC syscall(0x1004. 5) gdi32.dllINtGdiAddFontMemResourceEx syscal1(0x1005. 2) gdi32.dl1!NtGdiRemoveMergeFont syscall(0x1006. 3) gdi32.dll .'NtGdiAddRemoteMMInstanceToDC syscal1(0x1007. 12) gdi32.dllINtGdiAlphaBlend syscall(0x1008. 6) gdi32.dllINtGdiAngleArc syscall syscall syscall syscall syscall syscall syscall syscall syscall (0x1125. (0x1126. (0x1128. (0x1129. (0x112a. (0xlle5. (0x1244. (0x1245. (0x1246. 11) gdi32.dll 2) gdi32.dll 1) gdi32.dll 1) gdi32.dll 1) gdi32.dll 3) gdi32.dll 3) gdi32.dll 6) gdi32.dll 4) gdi32.dll NtGdiTransparentBlt NtGdi UnloadPrinterDri ver NtGdiUnrealizeObject NtGdiUpdateColors NtGdiWidenPath NtUserSelectPalette NtGdi EngAssoci ateSurface NtGdi EngCreateBi tmap NtGdi EngCreateDevi ceSurface
98 Глава 2. Архитектура графической системы Windows syscal1(0x1247. 4) gdi32.dll!NtGdiEngCreateDeviceBitmap syscal1(0x1248, 6) gdi32.dl1!NtGdiEngCreatePalette syscal1(0x1280. 1) gdi32.dll!NtGdiEngCheckAbort syscal1(0x1281. 4) gdi32.dll!NtGdiHT_Get8BPPFormatPalette syscal1(0x1282. 6) gdi32.dl1!NtGdiHT_Get8BPPMaskPalette syscal1(0x1283. 1) gdi32.dl1!NtGdiUpdateTransform 356 total syscalIs found В списке приводится индекс вызываемой системной функции, количество передаваемых параметров, а также имя модуля и функции, из которой производится вызов. Программа SysCall также отображает адреса функции, которые здесь не приводятся для экономии места. Центральной частью программы SysCall является класс KlmageModule. Работа этого класса основана на использовании Win32 Image Help API — интерфейса, предназначенного для обработки загружаемых образов исполняемых файлов Win32. Класс загружает и выгружает модули с отладочными символическими файлами, выполняет преобразование между именами и адресами, а также перечисляет символические имена. Список вызовов системных функций реализуется перечислением всех символических имен внутри модуля и проверкой по стандартному шаблону вызова системной функции. От Win32 GDI API к системным функциям механизма GDI Сравнивая два списка (функций, экспортируемых GDI32, и системных функций, вызываемых из GDI32), нетрудно догадаться или по крайней мере сделать обоснованное предположение относительно того, как функции Win32 GDI отображаются на системные функции win32k.sys. Например, функция печати AbortDoc наверняка вызывает NtGdi AbortDoc, системную функцию с индексом 0x1000; функция поддержки драйверов принтера пользовательского режима, EngBitBIt — это простой псевдоним для NtGdi EngBitBIt, поскольку обе функции имеют одинаковые адреса. Некоторые функции Win32 API существуют в простой версии, которой проще пользоваться, и в расширенной версии с поддержкой дополнительных возможностей. Например, такую пару составляют функции AddFontResource и AddFont- ResourceEx. Логично предположить, что для этих функций Microsoft не создает двух разных системных вызовов — просто AddFontResource вызывает AddFontRe- sourceEx. Функции, получающие строковые параметры, обычно существуют в Win32 API в двух версиях: имя ANSI-версии заканчивается символом «А», а имя Unicode-версии заканчивается символом «W». Системная функция NT/2000 существует только в Unicode-версии, поскольку базовой кодировкой ОС является именно Unicode. Возможно, вы обратили внимание на то, что трем вызовам Add- FontResourceXXX соответствует единственная системная функция, NtGdiAddFontRe- sourceW. Сравнение списка экспортируемых функций GDI со списком системных функций GDI показывает, что некоторые области функциональности GDI реализуются чисто на пользовательском уровне клиента GDI, без промежуточных обращений к механизму GDI. Хорошим примером являются операции с мета-
Архитектура DirectX 99 файлами Windows и расширенными метафайлами, для которых в списке системных вызовов не обнаруживается ни малейшего следа. То же относится и к функциональным возможностям, основанным на использовании EMF — например, функций печати EMF в обход спулера GdiStartDocEMF, GdiStartPageEMF, Gdi- PlayPageEMF и т. д. В списке также отсутствуют различные функции Win32 API, предназначенные для чтения и записи системных атрибутов — например, GetBkMode, SetText- Color и т. д. Вероятно, ближайшими системными вызовами являются более общие NtGdiGetDCDword и NtGdiGetAndSetDCDword. Как выяснится позднее, некоторые атрибуты контекстов устройств для упрощения доступа хранятся в памяти пользовательского режима, а другие хранятся в структуре данных режима ядра. Подведем итог: DLL подсистемы Win32 gdi32.dll реализует Win32 GDI в основном за счет простого отображения вызовов функций Win32 API в вызовы системных функций, реализуемые графическим механизмом GDI в файле win32k.sys. Некоторые области (работа с метафайлами и расширенными метафайлами, печать EMF в обход спулера) относятся к числу действительно новых возможностей, обеспечиваемых gdi32.dll без прямой поддержки со стороны механизма GDI. Клиентские библиотеки GDI также обеспечивают реализацию других системных компонентов — DirectDraw, Direct3D, OpenGL, печати и спулинга. Архитектура DirectX Хотя для большинства прикладных программистов вполне хватало быстродействия и возможностей GDI API, компания Microsoft довольно долго боролась за то, чтобы привлечь на свою сторону и программистов игр. В играх прежде всего нужна быстрая графика, для которой аппаратно-независимые API типа Windows GDI совершенно не приспособлены. Microsoft пыталась внедрить DrawDIB API (часть Video for Windows), WinG (небольшая библиотека, ускоряющая вывод растровых изображений), WinToon (механизм работы с анимированными спрай- тами), Game SDK и, наконец, остановилась на DirectX1. Интерфейс DirectX был разработан Microsoft для программирования нового поколения компьютерных игр с быстрой графикой и мультимедиа-приложений. В DirectX также входит интерфейс DDI (Device Driver Interface), определяющий возможности, которые должны быть реализованы в драйверах экрана, предоставляемых производителем оборудования. Таким образом, DirectX ориентируется на две важные цели. На интерфейсном уровне DirectX предоставляет разработчикам игр/приложений мощный аппаратно-независимый интерфейс API без снижения быстродействия. Прикладные программисты могут использовать новые возможности устройств, не беспокоясь о непосредственной работе с оборудованием. На уровне драйверов устройств DirectX позволяет фирмам-производителям оборудования сконцентрировать внимание на аппаратных нововведениях и легко вывести их на рынок через тонкую прослойку драйверов 1 Пакет Game SDK является первой версией DirectX, смена названия объяснялась маркетинговыми соображениями. — Примеч. перев.
100 Глава 2. Архитектура графической системы Windows с поддержкой DirectX. Интерфейс DirectX DDI обеспечивает производителей оборудования необходимыми рекомендациями, которые легко интегрируются в DirectX. Компоненты DirectX DirectX состоит из нескольких основных компонентов, связанных с различными областями игрового и мультимедийного программирования. В настоящее время в Direct входят следующие компоненты. О DirectDraw — быстрый интерфейс двумерной графики, поддерживающий прямой доступ к видеопамяти, быстрый блиттинг (пересылку битовых блоков), работу вторичным буфером и переключение буферов, управление палитрой, отсечение, оверлеи и цветовые ключи. DirectDraw можно рассматривать как подмножество GDI, разработанное специально для быстрого вывода графики. О DirectSound — ускорение записи и воспроизведения оцифрованного звука (цифровые сэмплы) с низколатентным микшированием и прямым доступом к звуковым устройствам. О DirectMusic — преобразование музыкальных данных, генерируемых в пакетном виде, в оцифрованные сэмплы при помощи аппаратного или программного синтезатора. Оцифрованные сэмплы затем передаются DirectSound в виде потоковых аудиоданных. О DirectPlay — упрощение взаимодействия по модему или сети между игроками в многопользовательских играх. DirectPlay обеспечивает универсальный способ взаимодействия между приложениями DirectX, не зависящий от используемого протокола, транспорта или вида сетевых услуг. О Direct3D обеспечивает два уровня API для работы с трехмерной графикой в играх — непосредственный режим (Immediate Mode) и абстрактный режим (Retained Mode). Непосредственный режим Direct3D представляет собой низкоуровневый API трехмерной графики, который идеально подходит для опытных программистов, занимающихся переносом существующих игр и мультимедийных приложений в DirectX. Абстрактный режим Direct3D представляет собой высокоуровневый API, позволяющий легко реализовать приложения с трехмерной графикой; он основан на использовании непосредственного режима Direct3D. Direct3D поддерживает переключаемый буфер глубины, равномерную закраску и закраску Гуро, освещение сцены несколькими разнотипными источниками света, а также работу с материалами и текстурами, трансформациями и отсечением. В настоящее время разработка абстрактного режима Direct3D прекращена, и в будущем ему на смену придет новая технология. О Directlnput обеспечивает поддержку интерактивных устройств ввода — мыши, клавиатуры, джойстика, устройств с активной обратной связью и других игровых манипуляторов. О DirectSetup — простой API для установки компонентов DirectX. Игровые и мультимедийные приложения часто используют режим Автозапуска (Autoplay),
Архитектура DirectX 101 в котором установочная программа или игра автоматически запускается при вставке компакт-диска. О DirectShow — воспроизведение сжатых аудио- и видеоданных в различных форматах, в том числе MPEG, QuickTime, AVI и WAV. Существует возможность добавления новых форматов за счет подключения новых модулей, называемых фильтрами; они находятся под управлением диспетчера фильтров DirectShow. О DirectAnimation обеспечивает создание анимационных эффектов в различных средах, в том числе HTML, VBScript, JScript, Java и Visual C++. Векторная и растровая графика, спрайты, трехмерные геометрические фигуры, видео и звук объединяются в анимационный интерфейс API. DirectAnimation также содержит несколько клиентских элементов Media Player, свойства и методы которых предназначены для управления воспроизведением мультимедиа на web-странице или в приложении. На рис. 2.3 изображена архитектура DirectX, из которой для экономии места были исключены некоторые мелкие компоненты. На нижнем уровне DirectX обращается к GDI для вызова системных функций. На базе этих системных функций построены DirectDraw, DirectSound, DirectMusic, непосредственный и абстрактный режим Direct3D. Функциональность всех перечисленных компонентов предоставляется через набор СОМ-интерфейсов. DirectShow и DirectAnimation строятся поверх этих базовых компонентов DirectX, их работа также зависит от различных фильтров. На верхнем уровне находятся игры, мультимедийные приложения, апплеты Java, web-страницы и т. д. Каждый компонент DirectX представлен одной или несколькими DLL подсистемы Win32 с легко узнаваемыми именами. Например, ddraw.dll и ddrawex.dll реализуют DirectDraw API; d3dim.dll реализует API непосредственного режима Direct3D; d3drm.dll реализует API абстрактного режима Direct3D. В отличие от традиционного интерфейса Win32 API, состоящего из сотен функций, доступ к DirectX API осуществляется через интерфейсы модели СОМ (Component Object Model). СОМ-интерфейс представляет собой группу семантически связанных функций с заранее определенными типами параметров и возвращаемых значений. В парадигме программирования языка С СОМ-интерфейс может рассматриваться как таблица функций; в мире C++ СОМ-интерфейс является аналогом абстрактного базового класса. СОМ-интерфейсы реализуются СОМ-классами. Но поскольку в идеологии СОМ реализация должна быть четко отделена от интерфейса, клиентские программы могут создавать только экземпляры СОМ-классов (также называемые СОМ-объектами) и выполнять операции с ними через интерфейсы СОМ. После публикации СОМ-интерфейс «замораживается». Это означает, что определение интерфейса изменять нельзя, хотя можно свободно изменять его реализацию. Чтобы предоставить приложению новые возможности, существует только один путь — спроектировать и опубликовать новые интерфейсы. Из-за этого встречаются интерфейсы с именами IDirectDraw, IDirectDraw2 и IDirectDraw7. На рис. 2.3 изображена лишь часть СОМ-интерфейсов, поддерживаемые некоторыми компонентами DirectX. Большинство компонентов DirectX определяет слишком много интерфейсов, которые не поместятся на рисунке.
102 Глава 2. Архитектура графической системы Windows Игры DirectX, мультимедийные приложения, апплеты Java, HTML-страницы и т. д. Подключаемые модули браузера Элементы Media Player Клиентские элементы DirectAnimation DirectAnimation (danim.dll) DirectDraw (ddraw.dll, ddrawex.dll) Диспетчер фильтров DirectShow Фильтр источника Фильтр преобразования Фильтр воспроизведения! DirectSound (dsound.dll) IDirectMusic | IDirectMusicLoader | IDirectMusicColiection | IDirectMusicComposer 1 (more) 1 DirectMusic (dmusic.dil) IDirect3D3 IDirect3DDevice IDirect3DExecuteBuffer IDirect3DLight (more) Непосредственный режим Direct3D (d3dim.dll) IDirect3DRM3 IDirect3DRMDevice3 IDirect3DRMLight | IDirect3DRMMaterial2 (more) 1 Абстрактный режим Direct3D (d3dim.dll) GDI и прочий сервис ОС Рис. 2.3. Основная архитектура DirectX Архитектура DirectDraw Главной темой этой книги является программирование двумерной графики в Windows — другими словами, GDI и DirectDraw. Информацию об остальных компонентах DirectX можно почерпнуть из документации MSDN, других книг и ресурсов Интернета, а мы перейдем к рассмотрению архитектуры DirectDraw. DirectDraw можно рассматривать как специализированную версию GDI. Первая стадия специализации заключается в том, что вывод направляется только на видеоадаптер, а не на принтер, плоттер или любое другое из существующих графических устройств. Второй стадией является сокращение функциональных возможностей, поддерживаемых GDI. В DirectDraw нет прямой поддержки режимов отображения, мировых преобразований, шрифтов и текста, линий и кривых; работа осуществляется только с растровыми изображениями. Последней стадией является реализация ограниченного подмножества с учетом аппаратного ускорения и добавлением возможностей, имеющих важное значение для игр и мультимедийного программирования. DirectDraw реализует семь основных интерфейсов, два из которых существуют в нескольких версиях.
Архитектура DirectX 103 О IDirectDraw — базовый интерфейс DirectDraw, на основе которого могут создаваться другие объекты DirectDraw. Последней версией является IDirectDraw7. Интерфейсы IDirectDraw обеспечивают создание других объектов DirectDraw, управление поверхностями, выбор разрешения и глубины цвета, получение информации о состоянии экрана, выделение памяти и т. д. При вызове Direct- DrawCreate создается объект DirectDraw, который поддерживает различные интерфейсы IDirectDraw. О Интерфейс IDirectDrawSurface обеспечивает все операции вывода в DirectDraw. Последней версией является IDirectDrawSurface7. В этот интерфейс входят операции с поверхностями — получение информации о возможностях, блокировка и ее снятие, выбор палитры, отсечение и т. д. При блокировке поверхности память видеоадаптера отображается в виртуальное адресное пространство приложения, что позволяет организовать прямой доступ к ней, связать контекст устройства GDI с поверхностью DirectDraw и осуществлять вывод на поверхности средствами GDI. Еще важнее то, что IDirectDrawSurface поддерживает блиттинг между поверхностями и переключение поверхностей с аппаратным ускорением. Чтобы выполнить более сложные операции, вам придется либо реализовать их самостоятельно, либо обратиться к GDI. О Интерфейс IDirectDrawPalette поддерживает создание и непосредственные операции с цветовой палитрой на 256-цветном экране. О Интерфейс IDirectDrawClipper управляет отсечением поверхностей DirectDraw с использованием списков отсечения (clip lists), представленных структурами RGNDATA GDI API. Поскольку DirectDraw не поддерживает создание списков отсечения, в вашем распоряжении остается богатый ассортимент операций с регионами, существующих в GDI. О Интерфейс IDirectDrawColorControl управляет цветом поверхностей и оверлеев за счет регулировки яркости, контраста, оттенка, насыщенности и гамма- коррекции. О Интерфейс IDirectDrawGammaControl управляет процессом гамма-коррекции, в ходе которого значения цветов в кадровом буфере преобразуются в цвета, передаваемые аппаратному цифро-аналоговому преобразователю (DAC, digital- to-analog converter). О Интерфейс IDirectDrawVideoPort обеспечивает передачу видеоданных с аппаратного видеопорта на поверхность DirectDraw. С его помощью программист может управлять оборудованием через видеопорт. На рис. 2.4 представлена архитектура DirectDraw с компонентами как пользовательского режима, так и режима ядра. Компонентом DirectDraw пользовательского режима является библиотека ddraw.dll, связанная с gdi32.dll и mcd32.dll (OpenGL). Вызовы функций DirectDraw проходят через gdi32.dll и приводят к вызову системных функций, предварительная обработка которых производится диспетчером системных функций в адресном пространстве режима ядра. Диспетчер передает вызов графическому механизму (win32k.sys), после чего вызов передается либо драйверу экрана, предоставленному производителем оборудования, либо драйверу видеопорта. DirectDraw не является однозначной заменой GDI, поскольку его ориентация на экранный вывод и ограниченность функций
104 Глава 2. Архитектура графической системы Windows могут заставить приложения DirectDraw использовать поддержку GDI, особенно при выводе кривых, операциях с регионами, шрифтами и текстом. Глубокое понимание реализации GDI также поможет имитировать работу GDI средствами DirectDraw. DirectDraw HEL (ddraw.dll) GDI32 (gdi32.dll) MCD (mcd32.dll) Вызов системных функций (gdi32.dll) Диспетчер системных функций (ntoskrnl.exe) Graphics Engine (win32k.sys) Драйвер видеопорта Драйвер экрана (DirectDraw HAL) Рис. 2.4. Архитектура DirectDraw В документации Microsoft и в других документах DirectDraw нередко изображается рядом с GDI, причем оба интерфейса напрямую работают с оборудованием через аппаратно-зависимый абстрагирующий уровень. В некоторых книгах даже утверждается, что при работе с DirectDraw вам GDI уже не понадобится. В действительности API DirectDraw реализуется библиотекой ddraw.dll, взаимодействие которой с графическим механизмом и затем с драйверами устройств обеспечивает gdi32.dll. Библиотека ddraw.dll импортирует ряд важных недокументированных функций, экспортируемых GDI, — почти все функции от GdiEntryl до GdiEntryl5. В разделе «Компоненты графической системы Windows» упоминалась программа SysCall, предназначенная для вывода списка системных функций, вызываемых в системной DLL (например, gdi32.dll). Если взглянуть на такой список для GDI32, вы обнаружите в нем десятки вызовов системных функций DirectDraw и Direct3D — например, NtGdiDdCreateSurface, NtGdiD3dTexture- Swap и NtGdoD3dDrawPrimitives2. Разумеется, в самом интерфейсе GDI эти функции не используются. Возможно единственное объяснение: GDI экспортирует эти функции в интерфейсы DirectDraw/Direct3D для ddraw.dll и других DLL DirectX через недокументированные точки входа. Реализация DirectDraw состоит из нескольких уровней. Верхний уровень поддерживает СОМ-интерфейсы DirectDraw, стандартные экспортируемые функции
Архитектура системы печати 105 СОМ-объектов (DUGetCI assObject и т. д.) и специальные функции создания объектов DirectDraw (DirectDrawCreate и т. д.). Средний уровень, HEL (Hardware Emulation Layer), эмулирует все или некоторые возможности DirectDraw, не поддерживаемые на аппаратном уровне. Нижний уровень, называемый HAL (Hardware Abstraction Layer), взаимодействует непосредственно с видеоадаптером. Но какие DLL реализуют DirectDraw HEL и DirectDraw HAL? Оказывается, DirectDraw HEL является важной частью ddraw.dll, 32-разрядной DLL пользовательского режима. В этом можно убедиться несколькими способами. Для начала взгляните на размер ddraw.dll — 248 Кбайт, чуть больше, чем gdi32.dll. Из этого можно сделать вывод, что ddraw.dll — нечто большее, чем тонкая прослойка API. Затем посмотрите на список импортируемых функций ddraw; вы найдете в нем такие функции GDI, как CreateDIBSection, StretchDIBits, PatBIt, BitBlt и т. д. Следовательно, ddraw использует функции GDI в процессе вывода. Наконец, воспользуйтесь какой-нибудь программой, выводящей списки символических имен в файлах с отладочной информацией, — например, отладчиком Visual C++. Вы найдете в ddraw.dll такие имена, как HELBU, HELInitializeSpecialCases и general- AlphaBlt. В списке также встречается немало имен с префиксом «mmx», относящихся к расширенному набору мультимедийных инструкций процессоров Intel. Следовательно, ddraw.dll обеспечивает специальную оптимизацию DirectDraw HEL для MMX. Реализация DirectDraw HEL в пользовательском режиме заметно упрощает использование программного кода как в Windows NT/2000, так и в Windows 95/98. Кроме того, применение инструкций вещественных вычислений и инструкций ММХ, которые недостаточно хорошо поддерживаются режимом ядра ОС, сопряжено с определенными трудностями. Не стоит и говорить, что с увеличением доли кода пользовательского режима DirectDraw реже «подвешивает» систему. DirectDraw HAL представляет собой обычный драйвер устройства, который предоставляется разработчиком видеоадаптера, поддерживающего интерфейс DDI DirectDraw. Помните, что уровень DirectDraw API и HEL в пользовательском режиме не имеют прямого доступа к уровню DirectDraw HAL, который в Windows NT/2000 работает в режиме ядра. Чтобы добраться до DirectDraw HAL, приходится пройти через системные функции GDI, обрабатываемые механизмом GDI (win32k.sys). В этой книге будет приведена более подробная информация о DirectDraw. В разделе «Обращение к адресному пространству режима ядра» главы 3 исследуются внутренние структуры данных DirectDraw. В разделе «Отслеживание СОМ-интерфейсов DirectDraw» главы 4 освещается процесс мониторинга интерфейсов DirectDraw. Наконец, описанию DirectDraw посвящена вся глава 18. Архитектура системы печати Интерфейс Win32 GDI API задумывался как аппаратно-независимый API, способный выводить прямые, кривые, растровые изображения и текст на любом графическом устройстве, для которого имеется соответствующий драйвер. Однако принтеры составляют особый класс графических устройств и заслуживают
106 Глава 2. Архитектура графической системы Windows особого внимания. Ниже перечислены важнейшие отличия принтеров от других графических устройств. О Пользователи обычно печатают не одну страницу, а целый документ, задавая при этом специальные параметры — качество печати, размер бумаги, режим двусторонней печати, количество копий и т. д. GDI содержит специальный принтерный API для постраничной печати, а также структуру DEVM0DE для определения всех параметров печати. Такие аспекты, как разбиение документа на страницы и выбор размеров полей, находятся под контролем приложения. О Принтер обычно обладает гораздо большим разрешением (от 300 до 2400 dpi), чем экран монитора (от 75 до 120 dpi). Это приводит к увеличению объема обрабатываемых данных и возможной нехватке памяти для одновременного воспроизведения всей страницы. Механизм GDI позволяет драйверу принтера принимать данные небольшими частями (полосами) посредством спулин- га EMF (расширенных метафайлов). О Принтер обычно работает медленно, совместно используется несколькими участниками рабочей группы и не всегда подключается к локальному компьютеру. Спулер системы Windows следит за тем, чтобы приложения как можно раньше завершали свою часть вывода, чтобы принтер мог обслуживать несколько заданий печати и чтобы группы пользователей совместно работали с принтером в локальном окружении, по сети и даже по адресу URL. О Принтеры «говорят» на разных языках — PCL (принтеры HP), ESC/P (принтеры Epson), PostScript (принтеры с поддержкой PostScript) и HPGL (плоттеры). В этом отношении они принципиально отличаются от видеоадаптеров, работающих с растровыми изображениями. Microsoft предоставляет несколько «универсальных» драйверов, которые могут настраиваться производителями оборудования в соответствии со специфическими требованиями их устройств. В архитектуре печати Windows NT/2000 центральное место занимает спулер печати (print spooler), поддерживаемый GDI и драйвером принтера. Чтобы создать новое задание печати, пользовательское приложение обращается к точкам входа API, экспортируемым GDI и DLL клиента спулера. GDI и спулер (с помощью драйвера принтера) обрабатывают задание печати и посылают данные на устройство создания жестких копий, будь то лазерный или струйный принтер, плоттер или факс. Графические команды передаются GDI в виде вызовов GDI API, которые обычно сохраняются в расширенном метафайле (EMF). EMF и другой файл с текущими параметрами печати передаются системному процессу службы спулера (spools.exe). На этой стадии печать документа на уровне приложения завершается. Пользователь может продолжить работу с приложением, а дальнейшая печать документа будет осуществляться спулером. Сначала спулер направляет задание провайдеру печати, который обслуживает конкретный принтер. Локальные принтеры обслуживаются локальным провайдером печати (localspl.dll), а сетевые принтеры обслуживаются провайдером печати сетей Windows (win32spl.dll). Если принтер подключен к удаленному компьютеру, то файлы спулера пересылаются на удаленный компьютер сетевыми службами ОС, где они поступают к спулеру в виде задания для локального компьютера. Архитектуру системы печати в Windows NT/2000 иллюстрирует рис. 2.5.
Архитектура системы печати 107 Локальная система WinNT/2000 System Приложение -о см СО "О О) о о го &? 5 "О >> — с о о о 1- О- I </> а> .Е с * 5- Интерфейсная DLL драйвера печати и RPC Служба спулера (spoolsv.dll) Маршрутизатор спулера (spoolsv.dll) Провайдер печати для сетей Windows (win32spl.dll) Интерфейсная DLL драйвера печати Пользовательский режим Kernel Mode Сервер WinNT/2000 Служба спулера (spoolsv.dll) Маршрутизатор спулера (spoolsv.dll) Локальный провайдер печати (localspl.dll) Процессор печати (localspl.dll) GDI (gdi32.dll) Драйвер принтера пользовательского режима Языковой монитор Монитор порта Файловый ввод-вывод" Системные функции Графический механизм Шрифтовой драйвер Шрифты Драйвер принтера режима ядра Диспетчер ввода/вывода Сетевые драйверы Драйверы порта принтера Рис. 2.5. Архитектура системы печати в Windows NT/2000 Когда локальный провайдер печати наконец получает задание, оно передается процессору печати. Процессор печати проверяет формат файла спулера. Для файлов EMF каждая страница воспроизводится в GDI. В результате команды GDI разбиваются на графические примитивы, определяемые в интерфейсе DDI, которые затем передаются драйверу принтера. Драйвер принтера преобразует графические примитивы в низкоуровневые данные языка принтера — например, PCL, ESC/P или PostScript. Низкоуровневые данные возвращаются процессору печати. Когда процессор печати получает низкоуровневые данные, готовые к отправке на принтер, он передает их языковому монитору (language monitor). Языковой монитор пересылает данные монитору порта (port monitor), который использует API файловой системы для записи данных в аппаратный порт. Работа встроенного кода (firmware) на стороне принтера нас не интересует; мы считаем, что в результате длинной цепочки программных компонентов, описанной выше, ваш документ будет успешно напечатан. Перейдем к более подробному рассмотрению компонентов системы печати Windows NT/2000.
108 Глава 2. Архитектура графической системы Windows Клиент спулера Win32 Клиентская библиотека DLL спулера Win32 (winspool.drv) предоставляет пользовательским приложениям доступ к API спулера. Пользовательское приложение использует API спулера для обращения с запросами к принтерам и заданиям печати, получения и определения настроек принтера, загрузки интерфейсной DLL драйвера принтера для вывода диалогового окна настройки параметров печати и т. д. Например, функции OpenPrinter, WritePrinter и ClosePrinter, входящие в API спулера, могут использоваться для отправки данных непосредственно на принтер в обход стандартной процедуры вывода через GDI и драйвер принтера. API спулера определяется в заголовочном файле winspool.h, а его библиотечным файлом является winspool.lib. Таким образом, winspool.drv загружается в процесс приложения, когда возникает необходимость в выводе на печать. Клиентская DLL спулера помогает GDI определить, как должна происходить обработка задания. Для обычных заданий GDI генерирует файл EMF и передает его клиенту спулера, который использует механизм RPC для передачи задания системному процессу службы спулера. Служба спулера Спулер Windows NT/2000 реализуется в виде службы (service) — процесса, обладающего особыми привилегиями и особой ответственностью в системе. Служба спулера запускается при загрузке операционной системы. Именно по этой причине принтер иногда начинает автоматически печатать при перезагрузке системы, если при завершении работы в системе оставались необработанные задания печати. Команда net stop spooler останавливает процесс спулера, а команда net start spooler перезапускает его. После остановки спулера перестает работать мини- приложение Принтеры в панели управления. Служба спулера экспортирует интерфейс на базе RPC (Remote Procedure Call) для клиентской DLL спулера, которая используется приложением для управления принтерами, драйверами принтеров и заданиями печати. Сама служба спулера представляет собой маленький ЕХЕ-файл (spoolsv.exe). Большая часть вызовов ее функций передается провайдеру печати через маршрутизатор спулера. Служба спулера является системным компонентом, который невозможно заменить. Маршрутизатор спулера Принтер, на котором вы печатаете, не всегда подключается к вашему компьютеру — он может находиться где-то в сети Microsoft, на сервере Novell или вообще в другой точке земного шара (в этом случае печать осуществляется по адресу URL). При помощи DLL маршрутизатора (spoolss.dll) служба спулера передает задания печати провайдеру, который знает, куда следует отправить задание. По составу экспортируемых функций библиотека spoolss.dll напоминает winspool.drv. Например, функции AddPrinter, OpenPrinter, EnumJobW и т. д. встреча-
Архитектура системы печати 109 ются в обеих библиотеках. В процессе спулинга вызовы часто передаются от одного модуля к другому, затем к третьему и т. д., до тех пор, пока они не достигнут места назначения. Главная функция маршрутизатора проста — поиск ргужного провайдера печати и дальнейшая пересылка информации. Поиск осуществляется по имени или манипулятору (handle) принтера с использованием настроек принтера в системном реестре. Когда пользовательское приложение обращается с вызовом OpenPrinter к клиентской DLL спулера (winspool.drv), этот вызов передается системной службе спулера (spoolsv.exe). Последняя вызывает маршрутизатор спулера, который вызывает функцию OpenPrinter каждого провайдера печати до тех пор, пока один из них не вернет манипулятор, означающий, что провайдер печати опознал имя принтера. Этот манипулятор возвращается приложению, чтобы последующие вызовы сразу направлялись нужному провайдеру печати. Маршрутизатор спулера является системным компонентом, который невозможно заменить. Провайдер печати Провайдер печати отвечает за передачу заданий печати на локальный или удаленный компьютер. Кроме того, он управляет операциями с очередью заданий печати — такими, как запуск, остановка и перечисление заданий. В отличие от маршрутизатора и службы спулера, в системе может присутствовать несколько провайдеров печати. Производители принтеров даже могут создавать собственные провайдеры печати при помощи Windows NT/2000 DDK. В поставку операционной системы входит несколько провайдеров печати. О Локальный провайдер печати (localspl.dll) управляет локальными заданиями печати или заданиями, отправленными с удаленных клиентов на локальный компьютер. В конечном счете каждое задание обрабатывается локальным провайдером печати, который передает задание процессору печати. В Windows 2000 процессор печати, используемый по умолчанию, реализуется в DLL локального провайдера печати. О Провайдер печати сетей Windows (win32spl.dll) передает задания печати удаленному серверу Win32. О Провайдер печати Novell Netware (nwprovau.dll) передает задания печати на серверы печати Novell Netware. Поскольку файлы в формате EMF не обрабатываются серверами Novell, перед отправкой на сервер Novell задания печати должны быть преобразованы в низкоуровневые (RAW) данные. О Провайдер печати HTTP (inetpp.dll) передает задания печати по адресам URL. Все провайдеры печати должны реализовывать некоторый набор обязательных функций, перечисленных в DDK, чтобы маршрутизатор спулера мог работать с ними по одним правилам. Другие функции являются необязательными. В каталоге src\print\pp Windows 2000 DDK приведен исходный текст примерного провайдера печати. Главная точка входа провайдера называется Initialize- PrintProvider. Доступ к другим точкам входа осуществляется через таблицу функций, возвращаемую Initial izePrintProvider.
110 Глава 2. Архитектура графической системы Windows Локальный провайдер печати должен реализовать полный набор функций провайдера печати, включая отмену спулинга заданий печати, обращения к интерфейсной DLL драйвера принтера и вызов процессоров печати для обработки задания. Процессор печати Процессор печати отвечает за преобразование спулерных файлов задания печати в данные низкоуровневого формата, которые могут передаваться на принтер. Кроме того, они вызываются для выполнения управляющих операций с заданиями печати — для приостановки, возобновления и отмены запросов. Процессор печати вызывается локальным провайдером печати. Спулерные файлы заданий печати в Windows NT/2000 обычно хранятся в формате EMF. GDI помогает преобразовать заявку приложения на выполнения графических операций в формат EMF pi быстро записать этот файл на диск, чтобы приложение могло возобновить свою нормальную работу. Спулерные файлы обычно хранятся в каталоге $SystemRoot$\spool\printers. Для заданий печати в формате EMF спулер генерирует два файла. Файл с расширением .shd содержит параметры задания — имя принтера, имя документа, имя порта, а также копию структуры DEVM0DE. Файл с расширением .spl содержит недокументированный заголовок, внедренные шрифты и одну страницу в формате EMF для каждой печатаемой страницы документа. В поставку Windows 2000 входят два стандартных процессора печати: О процессор печати Windows (в localspl.dll) поддерживает различные форматы спулера, включая NT EMF, RAW и TEXT; О процессор печати Macintosh (в sfmpsprt.dll) поддерживает формат PSCRIPT1. Формат EMF является обычным файловым форматом спулинга для всех приложений Windows. Файл в формате EMF обычно занимает существенно меньше места, чем низкоуровневые данные, готовые к передаче на принтер. EMF- файлы обычно генерируются GDI с минимальным участием драйвера принтера. Если вы печатаете по сети, пересылка заданий печати в формате EMF приводит к уменьшению сетевого трафика. Кроме того, клиентский компьютер получает возможность продолжить нормальную работу, пока сервер занимается преобразованием EMF в низкоуровневые данные принтера. В процессе построения EMF-файла GDI обращается к удаленному компьютеру с запросом о доступности шрифтов. Если некоторые шрифты отсутствуют на удаленном компьютере, они внедряются в файл .shd, пересылаются на удаленный компьютер и устанавливаются на нем. Если выбрать тип данных RAW, то принтерные данные будут сгенерированы на клиентском компьютере вместо сервера; это приведет к увеличению сетевого трафика, но также и к снижению затрат памяти и вычислительных мощностей сервера. Спулерный файл в формате PostScript для принтеров с поддержкой PostScript считается относящимся к типу RAW, поскольку он не требует дополнительных преобразований перед отправкой на принтер. Спулерные файлы в формате TEXT состоят исключительно из текста в кодировке ANSI. За воспроизведение текстовых строк в формате, который поддер-
Архитектура системы печати 111 живается принтером, отвечает процессор печати. Для этого он обращается с запросами к GDI и драйверу принтера. Вероятно, печать в формате TEXT может пригодиться в DOS-приложениях. Формат PSCRIPT1 и процессор печати sfmpsprt не предназначены для принтеров PostScript. Вернее, файл в формате PSCRIPT1 имеет формат PostScript, но процессор печати sfmpsprt преобразует его в формат RAW для вывода на принтер. Следовательно, sfmpsprt в действительности является интерпретатором PostScript. Процессор печати не имеет прямого доступа к спулерным файлам, а их форматы не документированы. Для преобразования файлов в низкоуровневые данные принтера процессор печати пользуется услугами GDI и API клиента спулера (winspool.drv). Ваш выбор не ограничивается двумя процессорами печати, предоставляемыми Microsoft. В Windows NT/2000 DDK входит полная документация и работающий пример процессора печати. В каталоге src\print\genprint Windows 2000 DDK находится пример процессора печати для формата EMF. Вы можете откомпилировать его, скопировать двоичный файл в каталог $SystemRoot$\system32\ spoo!\prtprocs\w32x86, написать маленькую программу с вызовом AddPrintProcessor для его установки, а затем повозиться с собственным процессором печати в отладчике. Windows NT 4.0 DDK содержит более полный пример процессора печати с поддержкой форматов EMF, RAW и TEXT. Главными точками входа процессора печати являются функции OpenPrint- Processor, PrintDocumentOnPrinterProcessor и ClosePrintProcessor. Функция OpenPrint- Processor инициализирует процессор печати для приема задания; PrintDocumentOn- PrinterProcessor обрабатывает задание печати, a ClosePrintProcessor освобождает память, выделенную в OpenPrintProcessor. Для спулерных файлов в формате EMF в Windows NT 4.0 GDI имеется единственная функция GdiPlayEMF, которая воспроизводит весь документ. Windows 2000 поддерживает более обширный, но все же несколько ограниченный API, позволяющий процессору печати обращаться с запросами к отдельным страницам EMF-файла, изменять порядок воспроизведения страниц, объединять несколько логических страниц в одну физическую страницу и задействовать мировые преобразования координат при воспроизведении EMF-файлов. Например, в реализации PrintDocumentOnPrintProcessor можно использовать следующие функции: О GdiGetPageCount — получить количество страниц в документе; при вызове эта функция ожидает завершения спулинга всего документа в формате EMF; О GdiStartPageEMF — начать воспроизведение физической страницы; О GdiGetSpoolPageHandle — найти последнюю EMF-страницу; О GdiPlayPageEMF — воспроизвести четыре логических страницы так, чтобы каждая из них занимала четверть физической страницы; О GdiEndPageEMF — завершить воспроизведение физической страницы с обращением к драйверу принтера. Вызов описанной последовательности функций приводит к результату, который называется «кратной печатью в обратном порядке» — другими словами, документ печатается от конца к началу, и на одной физической странице печатает-
112 Глава 2. Архитектура графической системы Windows ся несколько (в данном случае 4) логических страницы. При такой архитектуре процессора Windows 2000 вам не придется реализовывать эти средства форматирования документов в каждом драйвере принтера. Достаточно иметь один процессор печати, который выполнит необходимые предварительные действия для всех совместимых драйверов. Процессор печати для формата EMF в Windows NT 4.0 реализован в виде отдельной DLL, winprint.dll. В Windows 2000 его функциональность интегрирована в localspl.dll — PrintDocumentOnPrintProcessor входит в список экспортируемых функций localspl.dll. Чтобы сменить процессор печати для драйвера принтера, перейдите на страницу свойств драйвера и выберите вкладку Advanced; вы найдете на ней кнопку Print Processor... От процессора печати данные могут идти в нескольких направлениях. Для данных в формате RAW процессор печати вызывает функцию WritePrinter (см. пример winprint в Windows NT 4.0, файл raw.c). В этом случае данные передаются непосредственно языковому монитору. Для данных в формате TEXT процессор печати вызывает StartDoc и отправляет графические команды GDI драйверу принтера. В этом случае за вызов WritePrinter отвечает драйвер. Для данных в формате EMF процессор печати вызывает функцию GdiEndPageEMF, которая использует механизм воспроизведения EMF для передачи записанных графических команд драйверу принтера. В этом случае функция WritePrinter также вызывается драйвером принтера. Языковой монитор и монитор порта Мониторы печати (print monitors) отвечают за передачу низкоуровневых данных печати от спулера к правильному драйверу порта. Мониторы печати делятся на два типа — языковые мониторы (language monitors) и мониторы портов (port monitors). Термин «язык» в данном случае не относится ни к английскому языку, ни к языку программирования C++. Он означает особую категорию языков заданий печати (например, PJL), понятных для встроенных программ принтера. Главной целью языкового монитора является обеспечение двустороннего взаимодействия между спулером печати и принтером, подключенным к компьютеру кабелем, обеспечивающим возможность двусторонней связи. Прямой канал (от компьютера к принтеру) в основном предназначен для отправки на принтер данных печати. Обратный канал (от принтера к компьютеру) обеспечивает обратную связь. Спулер, драйвер принтера и даже пользовательское приложение могут обратиться с запросом о точных возможностях и состоянии принтера (например, объеме установленной и доступной памяти, установленных дополнительных модулях, количестве чернил в картридже и т. д.). Языковой монитор может предоставить необходимую информацию посредством стандартного вызова Devi се- IoControl. Второй важной функцией языкового монитора является вставка команд управления принтером в поток данных печати. Монитор порта работает на более низком уровне, чем языковой монитор; он обеспечивает канал взаимодействия между спулером и драйверами порта режима ядра, которые фактически обращаются к аппаратным портам ввода-вывода, к которым подключаются принтеры. Монитор порта как DLL пользовательского
Архитектура системы печати 113 режима не имеет прямого доступа к оборудованию. Для взаимодействия с драйверами в ядре ОС он использует обычные функции API файловой системы — CreateFile, WriteFile, ReadFile и DeviceloControl. Монитор порта также отвечает за управление логическими портами принтеров на вашем компьютере; например, localmon.dll обеспечивает поддержку всех СОМ- и LPT-портов на вашем локальном компьютере. Таким образом, когда ваше приложение записывает данные в порт LPT1, оно не взаимодействует с драйвером физического порта напрямую. В действительности приложение общается с каналом (pipe), созданным спулером и находящимся под управлением монитора порта. Если воспользоваться утилитой Winobj, входящей в SDK, вы увидите, что «\DosDevices\LPTl» представляет собой символическую ссылку для «\Device\NamedPipe\Spooler\LPTl». В Windows 2000 входит несколько мониторов печати: pjlmon.dll для разнообразных принтеров HP с поддержкой языка управления заданиями PJL; tcpmon.dll для управления сетевым портом; faxmon.dll для драйвера факса и sfmmon.dll. В DDK также включены примеры исходных текстов языкового монитора и монитора порта, чтобы производители оборудования могли создавать собственные мониторы печати. Процесс спулера изнутри В этом разделе кратко описана архитектура системы печати Windows NT/2000, причем основное внимание уделяется спулеру. Дополнительная информация об API печати приведена в главе 17, а драйверы принтеров более подробно рассматриваются ниже, в разделе «Драйверы принтеров». 1. Если вам захочется поближе познакомиться с системным процессом спулера, в котором происходят столь захватывающие события, это нетрудно сделать при помощи Visual Studio. Выполните следующие простые действия. 2. Нажмите клавиши Ctrl+Alt+Del; на экране появляется диалоговое окно Windows Security. Выберите вариант Task Manager. 3. В списке процессов выберите службу спулера (spoolsv.exe), щелкните на ней правой кнопкой мыши и выберите команду Debug; вы переходите в режим отладки системного процесса службы спулера. 4. Просмотрите список модулей VC 6.0. Вы найдете в нем клиентскую библиотеку DLL спулера, маршрутизатор, провайдеров печати, процессоры печати, языковые мониторы, мониторы портов и другие модули, не упоминавшиеся выше. 5. Запустите задание печати из панели управления, проследите за тем, как загружаются интерфейсные DLL драйвера принтера и драйвер принтера пользовательского режима и как создаются и завершаются программные потоки. Например, в Windows 2000 в качестве драйвера принтера пользовательского режима широко используется Microsoft UniDriver (unidrv.dll); его интерфейсная DLL называется unidrvui.dll. 6. Если вы закроете Visual Studio, завершая тем самым процесс службы спулера, не забудьте перезапустить его командой net start spooler.
114 Глава 2. Архитектура графической системы Windows На рис. 2.6 показана часть модулей, загруженных процессом службы спулера после создания задания печати. Этот процесс загружает 55 модулей. Компоненты драйверов принтеров, предоставленные производителем оборудования, обычно загружаются во время печати и выгружаются после ее завершения. шшшшшшш ;р?1 ■^■1!.й.;^ imiitfmiiMimfift -lnniififiiiuihiMimi Ш^< *Г 1 .4 f^ffi^^ffiff^.frft^S'': ^Л^^кГ^^^^ ^'.'/.'$Н'&. М tcpmon.dll usbmon.dll msfaxmon.dll sfmpsprt.dll rnr20.dll winrnr.dll nwprovau.dll mpr.dll win32spl.dll clbcatq.dll oleaut32.dll inetpp.dll icmp.dll UNIDRVUI.DLL UNIDRV.DLL mscms.dll DAWINNT50\system32Stcpmon.dll 40 DAWINNT50Ssystem32\usbmon.dll 41 DAWINNT50\system32Vnsfaxmon.dll 42 DAWINNT50\system32\spool\prtprocs\w32x86\sfmpspr... 43 DAWINNT50\system32\rnr20.dll 44 DAWINNT50\system32Winmr.dll 45 \WINNT50\system32\nwprovau.dll 4G \WINNT50\system32\mpr.dll 47 \WINNT50\system32\win32spl.dll 48 \WINNT50\syslem32\clbcatq.dll 49 \WINNT50\system32\oleaut32.dll 50 \WINNT50\system32\inetpp.dll 51 DAWINNT50\system32\icmp.dll 52 DAWINNT50\sy$tem32\spool\drivers\w32x86\3\UNID... 53 DAWINNT50\system32\spool\drivers\w32x86\3\UNID... 54 DAWINNT50\system32\mscms.dll 55' Л- f\CK*? »>■ ■n *•-! -jf^ Рис. 2.6. Модули, загруженные процессом службы спулера Графический механизм В разделе «Компоненты графической системы Windows» была приведена диаграмма с архитектурой графической системы Windows NT/2000. На этой диаграмме имеется большой блок с надписью «Графический механизм». В предыдущих обсуждениях GDI, DirectDraw и Direct3D говорилось о том, что все они вызывают системные функции gdi32.dll, обрабатываемые графическим механизмом. Давайте поближе познакомимся с графическим механизмом Windows NT/2000 — опорой GDI, шлюзом к драйверам графических устройств и вспомогательной поддержкой для работы этих драйверов. Графический механизм Windows NT/2000 «скрыт» в DLL режима ядра, в которой также реализована функциональность управления окнами — то есть в wln32k.sys. В первоначальной реализации Windows NT главным фактором при выборе архитектуры операционной системы была безопасность, из-за чего пред-
Графический механизм 115 почтение отдавалось компактным, простым и стабильным решениям. До появления Windows NT 4.0 графический механизм и система управления окнами были реализованы в виде DLL пользовательского режима, являвшейся частью процесса подсистемы Win32 (csrss.exe). Когда приложение вызывало функцию управления окнами или графического вывода, на самом деле оно через механизм LPC обращалось к процессу подсистемы Win32. Последний обращался к графическому механизму или системе управления окнами из своего программного потока и возвращал результат приложению. Переключение процессов и потоков в этой архитектуре приводило к значительным затратам памяти и ресурсов процессора. В Windows NT 4. и новой Windows 2000 графический механизм и система управления окнами были перемещены в режим ядра. Теперь user32.dll и gdi32.dll вызывают системные функции, которые ntoskrnl передает win32k.sys без переключения процессов и потоков. Таким образом, win32k.sys можно рассматривать как опорную реализацию на уровне ядра двух важных модулей системы Windows: user32.dll и gdi32.dll. Библиотека wln32k.sys велика (1640 Кбайт в Windows 2000) — она даже больше ntoskrnl.exe (1465 Кбайт в Windows 2000). Внутренняя архитектура win32k.sys внешнему миру практически неизвестна. Microsoft документирует только одно: интерфейс DDI, используемый драйвером графического устройства. win32k.sys экспортирует около 200 функций — не так уж много по сравнению с 1200 функциями ntoskrnl.exe. По адресу www.sysinternal.com приведен полный листинг исходных текстов ядра Windows 2000 beta 1, реконструированный на основе отладочной сборки ОС. Однако это относится только к ntoskrnl.exe; для win32k.sys ничего похожего не существует. К счастью, документация по интерфейсу DDI (то есть интерфейсу между графическим механизмом и драйверами графических устройств) в Microsoft NT/2000 DDK написана очень хорошо. На рис. 2.7 показано, как графический механизм может выглядеть с архитектурной точки зрения (основанной на документации DDK и собственных исследованиях автора). Графический механизм имеет многоуровневую архитектуру. На верхнем уровне находится таблица системных функций, которая образует единственную точку входа из приложений пользовательского режима. Расположенные под ней интерфейсы DirectDraw, Direct3D и GDI общаются с драйвером экрана по более короткому пути. Для обычных вызовов GDI имеется уровень GDI API, который преобразует конструкции GDI в примитивы, понятные для механизма отображения DIB и драйверов графических устройств. Уровень GDI API использует диспетчер манипуляторов (handle manager) GDI для управления внутренними структурами данных, механизм визуализации для воспроизведения примитивов GDI на растровых поверхностях, поддерживаемых GDI, модуль масштабирования, драйверы для трех типов шрифтов GDI и другие компоненты. Графический механизм Windows NT/2000, в отличие от механизма Windows 95/98, обладает достаточной мощностью для воспроизведения всех примитивов DII на поверхностях стандартного формата DIB без помощи драйверов графических устройств. Для нестандартных растровых поверхностей графический механизм обращается к драйверам устройств и поручает им воспроизведение примитивов DDL Драйверы могут обратиться к графическому механизму с встречным запросом — например, затребовать дополнительную информацию, дать указание,
116 Глава 2. Архитектура графической системы Windows чтобы графический механизм разбил команды на более мелкие и даже попросить у механизма визуализации помочь с выводом. Рис. 2.7. Архитектура графического механизма Windows 2000 Ниже описаны отдельные компоненты графического механизма Windows 2000. Системные функции графического механизма Как упоминалось в разделе «Архитектура GDI», gdi32.dll содержит сотни графических функций, используемых библиотеками компонентов подсистемы Win32 (а именно, GDI, DirectDraw, Direct3D и OpenGL) для обращений к графическому механизму, находящемуся в ядре ОС. В тексте даже была приведена программа для вывода списка вызовов системных функций из этих DLL. Реальная обработка вызовов системных функций осуществляется модулем win32k.sys. В нем находится таблица системных функций, в которую входят системные функции графического механизма вместе с системными функциями системы управления окнами. В процессе инициализации win32k.sys таблица регистрируется диспетчером системных функций ОС, что обеспечивает быструю передачу вызовов системных функций графическому механизму. Если на вашем компьютере установлены отладочные символические файлы Windows NT/2000, то для просмотра символических имен win32k.sys можно воспользоваться программой dumpbin. Это довольно мощная утилита, которая может вызываться для РЕ-файлов Win32, объектных файлов и отладочных символических файлов. Ниже приведены две команды, позволяющие получить список всех символических имен в файле win32k.sys и провести в нем поиск слова Service (системная функция). dumpbin symbols\sys\win32k.dbg /all > tmpfile grep Service tmpfile
Графический механизм 117 Обнаруживается довольно интересное имя, _W32pServiceTable — это начальный адрес таблицы указателей на все обработчики системных функций win32k.sys. Программа SysCall (см. раздел «Архитектура GDI») позволяет перечислить элементы таблицы, преобразовать их в символические имена и вывести в окне. Запустите программу SysCall и выберите команду View ► System Call Tables ► Win32k.sys system call table — появляется список из 639 (в Windows 2000) обработчиков системных функций графического механизма и системы управления окнами (рис. 2.8). \~iai к( £&? %Ш ,i ' ' Ь:\UINNT50\System32\win32k.sys loaded p:\WINNT50\symbols\sys\win32k.dbg loaded. syscall(1000; syscall(100i; syscall(1002; syscall(1003; syscall(1004; syscall(1005; syscall(1006; syscall(1007; syscallClOOe1 syscall(1009 syscall(100a syscall(100b; syscall(100c syscall(100d syscall(100e syscall(100f syscall(1010; syscall(1011 |syscall(1012 ) NtGdiAbortDoc ) NtGdiAbortPath i NtGdiAddFontResource¥ i NtGdiAddRemoteFontToDC t NtGdiAddFontMemResourceEx i NtGdiRemoveMergeFont ) NtGdiAddRemoteMMInstanceToDC i NtGdiAlphaBlend i NtGdiAngleArc i NtGdiAnyLinkedFonts i NtGdiFontlsLinked ) NtGdiArcInternal ) NtGdiBeginPath ) NtGdiBitBlt ) NtGdiCancelDC i NtGdiCheckBitmapBits i NtGdiCloseFigure ) NtGdiColorCorrectPalette i NtGdiCombineRgn \ - --', - iinuii J£| Рис. 2.8. Список системных функций графического механизма ПРИМЕЧАНИЕ ■ Другим крупным поставщиком системных функций в Windows NT/2000 является исполнительная часть, находящаяся в файле ntoskrnl.exe. Ее функции вызываются через DLL подсистемы Win32 ntdll.dll. Они обеспечивают поддержку базового сервиса Win32, обычно называемого сервисом ядра, функции которого экспортируются главным образом из kernel32.dll. Исполнительная часть использует системные функции с идентификаторами, меньшими 0x1000, а остальные идентификаторы используются графическим механизмом и системой управления окнами. Программа SysCall позволяет получить список системных функций в ntdll.dll и содержимое таблицы системных функций в ntoskrnl.exe. В отличие от поиска всех мест, из которых вызываются системные функции, вывод содержимого таблицы системных функций для программы SysCall является элементарной задачей. Все, что для этого требуется, — непрерывно читать из загруженного образа win32k.sys содержимое адресов, начиная с W32pServiceTable,
118 Глава 2. Архитектура графической системы Windows и преобразовывать их в символические имена при помощи отладочного символического файла. После описания системных функций GDI (инициирующих прерывание 0х2Е) список обработчиков системных функций графического механизма (то есть фрагментов, обслуживающих прерывание 0х2Е для разных индексов функции) выглядит знакомо — разве что для win.32k.sys этот список упорядочен по индексу системной функции и заполнен. Для парных функций из gdi32.dll и win.32k.sys Microsoft использует одинаковые имена. Например, функция NtGdiAbortDoc с индексом 0x1000 присутствует в обеих таблицах. Имена функций графического механизма за редкими исключениями начинаются с NtGdi, а имена функций системы управления окнами — с NtUser. Как правило, для каждой системной функции графического механизма удается легко найти прототип среди функций GDI, DirectDraw, Direct3D, OpenGL или функций поддержки драйвера принтера. В остальных случаях системные функции могут предназначаться только для внутреннего использования. Примеры: О системная функция NtGdiAbortDoc, конечно, реализует функцию GDI AbortDoc; О системная функция NtGdiDdBIt имеет отношение к интерфейсу DirectDraw IDirectDrawSurface; О системные функции NtGdiDoBanding и NtGdiGetPerBandlnfo используются при печати страниц по полосам; О системные функции NtGdi Created ientObj и NtGdi Del eteClientObj на первый взгляд выглядят загадочно, но после прочтения главы 3 вы поймете, для чего они нужны; О системные функции NtGdiGetServerMetafileBits и NtGdiGetSpoolMessage явно используются в работе спулера. Механизм графической визуализации Перейдем к фундаменту всего графического механизма Windows NT/2000 — механизму графической визуализации (graphics render engine, GRE). После знакомства с ним вам будет гораздо проще понять, как работает графический механизм в целом. В Windows NT/2000 компания Microsoft включила полноценные средства визуализации для всех стандартных DIB-форматов, к числу которых относятся DIB с цветовой глубиной 1, 4, 8, 16, 24 и 32 бит/пиксел. Если устройство вывода использует один из этих форматов DIB, графический механизм не нуждается в помощи драйверов устройств для рисования линий, заливок, растров или текста. Напротив, драйвер графического устройства может прибегнуть к услугам графического механизма для реализации графических вызовов GDI. При желании драйвер устройства может построить изображение самостоятельно — например, для достижения быстродействия, сравнимого с DirectDraw/Direct3D, или при использовании особых аппаратных конфигураций. В результате уменьшается сложность обычных драйверов графических устройств, повышается стабильность операционной системы и ускоряется разработка продуктов как производителями оборудования, так и самой компанией Microsoft.
Графический механизм 119 GRE используется как графическим механизмом, так и драйверами графических устройств; в нем сосредоточена большая часть функций, экспортируемых графическим механизмом. Эти функции подробно документированы в разделе «GDI Functions for Graphics Drivers» Windows NT/2000 DDK. GRE API сильно отличается от Win32 GDI API. Ниже перечислены некоторые общие концепции, используемые GRE и графическим механизмом в целом. О Операции с растрами на уровне GDI. Поддерживаются все стандартные форматы DIB, в том числе несжатые DIB с цветовой глубиной 1, 4, 8, 16, 24 и 32 бит/пиксел, а также сжатые DIB с цветовой глубиной 4 и 8 бит/пиксел в кодировке RLE (Run Length Encoding). DIB может храниться в памяти как в прямом (bottom-down), так и в перевернутом (top-down) виде. Память для графических данных DIB может выделяться из адресного пространства ядра или из адресного пространства пользовательского процесса. Функция Епд- CreateBitmap, экспортируемая из win32k.sys, создает растр, находящийся под управлением GDI, и возвращает его манипулятор. О Координатное пространство. Для повышения точности вывода без применения вещественных вычислений GRE может работать с дробными координатами в формате с фиксированной точкой 28.4 (другими словами, старшие 28 бит определяют знаковую целую часть, а младшие 4 бита — дробную часть). Это так называемые «FIX-координаты», используемые при рисовании линий и кривых. В других компонентах API координаты представляются 28-разрядными целыми числами со знаком. Все вызовы графических функций проходят предварительную трансформацию координат, поэтому в GRE отсутствуют понятия оконных координат и области просмотра (viewport), расширенных и мировых преобразований. Максимальный размер DIB- поверхности равен 227 х 227 пикселам, то есть 1,42 км х 1,42 км при разрешении 2400 dpi. О Поверхности. GRE обеспечивает полный контроль лишь для одного типа поверхностей — растров, управляемых GDI (GDI-managed bitmaps). Драйверы устройств могут создавать поверхности, управляемые устройствами (device- managed), в формате DIB или других форматах при помощи функции Епд- CreateDeviceSurface. Затем драйвер управляет графическим выводом на такие поверхности. Примером поверхности Win32, управляемой устройством и не относящейся к формату DIB, являются аппаратно-зависимые растры (device- dependent bitmap). О Перехват и возврат вызовов. По умолчанию GRE производит весь вывод на поверхностях DIB, управляемых GDI. Однако драйвер устройства может перехватывать вызовы некоторых графических функций, чтобы реализовать их по-своему. Флаг fl Hook функции EngAssociateSurface определяет функции, перехватываемые драйвером. Например, драйвер может предоставить собственную функцию DrvBitBlt, для чего при вызове EngAssociateSurface передается флаг H00K_BITBLT. В результате запросы на выполнение блиттинга будут передаваться DrvBitBlt. Однако при вызове DrvBitBlt может определить, что операция слишком сложна. В этом случае драйвер возвращает запрос GDI, вызывая EngBitBlt.
120 Глава 2. Архитектура графической системы Windows О Графические примитивы. Графический механизм сводит многочисленные графические функции Win32 к небольшому количеству примитивов, которые и поддерживаются GRE. Ниже приведена краткая сводка примитивов: □ EngLineTo и EngStrokePath — все операции вывода линий и кривых; □ EngFillPath и EngPaint — заливка замкнутой области кистью; □ EngStroke и Fill Path — заливка замкнутой области кистью и обводка контура; □ EngBitBlt, EngPlgBlt, EngStretchBlt, EngStretchBltROP, EngCopyBits, EngAlphaBlend и EngTransparentBlt — вывод растров; □ EndGradientFill — градиентная заливка областей; □ EngTextOut — весь вывод текста. Кроме упрощенных графических примитивов GRE использует совершенно новый набор структур данных. Речь идет вовсе не о манипуляторах GDI; в действительности GRE существует ниже (или, если хотите, позади) прослойки манипуляторов GDI. Ниже перечислены некоторые С++-подобные классы объектов, используемых GRE: О CLIP0BJ — область отсечения; О PATH0BJ — траектория GDI (а также все кривые, преобразованные в траектории); О PAL0BJ и XLATE0BJ — преобразование цветов; О BRUSH0BJ - кисти и перья GDI; О F0NT0BJ — реализованный шрифт; О STR0BJ — позиции глифов в выводимом тексте; О XF0RM0BJ — используется для преобразования координат при работе с F0NT0BJ; О SURF0BJ — графическая поверхность. Хотя по сравнению с Win32 API GRE обладает гораздо более простым интерфейсом, основные проблемы связаны с реализацией всех мельчайших деталей. Только представьте себе, сколько разновидностей функций блиттинга вам понадобится — по меньшей мере 36. Обратитесь к отладочной информации win32k.sys — вы найдете в ней такие символические имена, как bSrcCopySRLE4D32, vSrcS24D32, vSrcCopyS24D8, vSrcCopyS32D16, vSrcCopyS4D4Identify, BltLnkSrcCopyMsk32 и т. д. Похоже, первое имя, bSrcCopySRLE4D32, принадлежит функции для копирования 4-битных растров-источников, сжатых в кодировке RLE, в 32-разрядный растр-приемник. Третье имя, vSrcCopyS24D8, наводит на мысль о функции для копирования 24-битного источника в 8-битный приемник. Не забывайте о существовании 16 бинарных и 256 тернарных растровых операций, не говоря уже о кватернар- ных операциях, объединяющих две тернарные операции. Структуры данных графического механизма GDI, как и многие другие компоненты Win32 API, скрывает свою реализацию от программистов при помощи манипуляторов (handles) объектов GDI. Этот уровень абстракции чрезвычайно полезен для определения более или менее
Графический механизм 121 общего интерфейса Win32 API вместо разных реализаций для Win32s, Windows 95/98 и Windows NT/2000. Как и в любой абстрактной прослойке, кто-то в конечном счете должен управлять манипуляторами GDI, обеспечивая возможность их использования как в системных DLL пользовательского режима, так и в режиме ядра. Модуль, управляющий манипуляторами GDI, называется диспетчером манипуляторов GDI (GDI handle manager). Следующий вопрос посложнее — как организовано управление структурами данных в DLL пользовательского режима и в механизме режима ядра и как информация Win32 GDI о контекстах устройств, логических перьях, логических кистях, шрифтах, регионах, траекториях и т. д. преобразуется в структуры данных графического механизма? Знание структур данных, используемых в работе GDI, поможет программисту лучше понять реализацию GDI API и оптимизировать свои программы. Мы исследуем эту тему в главе 3 и попытаемся найти ответы на поставленные вопросы. Преобразование в примитивы Между Win32 GDI API и графическими примитивами, поддерживаемыми GRE (которые также образуют интерфейс DDI с драйверами устройств), существует заметный разрыв. За преобразование вызовов Win32 GDI API в примитивы GRE отвечает уровень GDI API. Ниже перечислены некоторые отличия, требующие преобразований. О Система координат. Win32 API поддерживает гибкую систему координат с преобразованиями между областями просмотра и окнами, режимами отображения и мировыми преобразованиями, тогда как GRE/DDI работает в физических координатах, масштаб которых определяется размером поверхности вывода. Координаты в вызовах функций Win32 API должны преобразовываться в физические координаты графической поверхности. О Эллиптические кривые. В интерфейсе GRE/DDI не поддерживаются эллиптические кривые вроде кругов или эллипсов — эти кривые должны преобразовываться в кривые Безье. В главе 3 приведен пример представления эллипса четырьмя кривыми Безье. В процессе преобразования графический механизм нуждается в эмуляции вычислений с плавающей точкой. Координаты с фиксированной точкой, используемые интерфейсом DDI, повышают точность конечного результата. О Преобразование кривых в траектории. Интерфейс DDI работает только с прямыми линиями и траекториями, поэтому все кривые нуждаются во внутреннем преобразовании в объекты траекторий. Графический механизм имеет богатый набор внутренних функций для операций с объектами траекторий. Если поверхность управляется устройством, от драйвера устройства требуется обязательная поддержка минимального набора функций — DrvPaint, DrvCopyBits, DrvTextOut и DrvStrokePath. Остальные функции разбиваются графическим механизмом на совокупность этих операций. Ниже перечислены некоторые из действий, выполняемых GDI.
122 Глава 2. Архитектура графической системы Windows О При выводе косметических линий и кривых функция DrvStrokePath должна поддерживать сплошные и стилевые косметические линии с закраской однородной кистью и отсечением. В реализации DrvStrokePath драйвер может вызывать служебные функции объектов PATH0BJ и CLIP0BJ для разбиения параметров до линий толщиной в 1 пиксел и прямоугольников отсечения. Если траектория или область отсечения окажется слишком сложной, драйвер может переадресовать вызов графическому механизму, который разбивает вызов до линий толщиной в 1 пиксел с заранее вычисленным отсечением. Для разбиения стилевых линий и кривых Безье GDI аппроксимирует их отрезками прямых линий. О Геометрические линии обладают атрибутами толщины, стилем соединения (join-style) и завершением (end-cap). Если драйвер устройства не справляется с выводом такой линии, он преобразует вызов функции в более простые вызовы DrvFillPath или DrvPaint. В этом случае операция вывода линии преобразуется в заливку области. О Для заливки областей драйвер должен поддерживать DrvPaint. Реализация DrvPaint может воспользоваться служебными функциями CLIP0BJ для разбиения сложной области отсечения на совокупность прямоугольников отсечения. О Для функций блиттинга драйвер должен поддерживать функцию DrvCopyBits, которая бы выполняла блочную пересылку графических данных на стандартный DIB или из него, а также на растр в формате устройства, с произвольным отсечением. DrvCopyBits выполняет простое копирование без растяжения, зеркального отражения или применения растровых операций. Если драйвер устройства ограничивается поддержкой DrvCopyBits, графический механизм должен самостоятельно эмулировать нужную операцию в памяти и применить DrvCopyBits к результату. Связь между графическим механизмом и драйверами устройств чем-то напоминает связь «родитель — потомок». Графический механизм обеспечивает всю поддержку, необходимую для драйверов устройств. Драйверы могут делать все, что угодно, чтобы превзойти быстродействие графического механизма, но когда возникают затруднения, они обращаются к графическому механизму за помощью. Шрифтовые драйверы В Windows NT 4.0/2000 существует особая разновидность драйверов графических устройств, поставляющих системе контуры или растровые изображения глифов шрифтов. Такие драйверы называются шрифтовыми драйверами (font drivers). На системном уровне в ОС Windows поддерживаются шрифты трех типов, основанные на применении разных технологий. Растровые шрифты представляют собой растровые изображения символов, символы векторных шрифтов строятся из отрезков прямых, а шрифты TrueType основаны на кривых Безье и хитроумном механизме разметки (hinting). Соответственно, в своей внутренней работе графический механизм использует три шрифтовых драйвера — для растровых шрифтов, для векторных шрифтов и для шрифтов TrueType.
Драйверы экрана 123 В системе также могут использоваться внешние шрифтовые драйверы. Например, в драйвер принтера может входить шрифтовой драйвер, снабжающий графическую систему информацией о шрифтах принтера. Другой пример — шрифтовой драйвер ATM (Adobe Type Manager) atmfd.dll, входящий в поставку Windows 2000. Шрифтовой драйвер ATM обеспечивает поддержку шрифтов ATM, основанных на технологии Adobe для работы со шрифтами PostScript. Драйверы экрана Драйвер экрана в Windows NT/2000 относится к категории драйверов графических устройств. Как правило, драйверы графических устройств представляют собой DLL режима ядра, загружаемые в адресное пространство ядра. Они отвечают за итоговую реализацию графических вызовов, передаваемых пользовательским приложением устройству. В Windows NT/2000 драйверы устройств всегда являются DLL режима ядра. Только драйверы принтеров в Windows 2000 могут быть реализованы как DLL пользовательского режима. Интерфейс между графическим механизмом GDI и драйвером графического устройства называется DDI (Device Driver Interface), то есть «интерфейс драйвера устройства». Почему в данном случае используется обобщенный термин «драйвер устройства», хотя речь идет только о драйверах графических устройств? Вероятно, потому, что в прежние времена графические драйверы составляли единственную заметную категорию драйверов, поставляемых разработчиками оборудования. Драйвер видеопорта и мини-драйвер видеопорта У каждого драйвера экрана существует парный ему мини-драйвер видеопорта, работающий в режиме ядра. Префикс «мини» говорит о том, что существует другой, «макси»-драйвер, управляющий работой мини-драйвера. В данном случае мини-драйвером видеопорта управляет драйвер видеопорта. Драйвер видеопорта и мини-драйвер видеопорта управляют всем взаимодействием системы с видеоадаптером, включая инициализацию и распознавание карты, отображение на память, обращения к регистрам видеоадаптера и т. д. Мини-драйвер видеопорта может отображать регистры видеоадаптера в пространство памяти драйвера, что позволяет работать с ними через стандартный механизм обращения к памяти. В системе Windows 2000, спроектированной с расчетом на поддержку DirectX на уровне драйвера видеоадаптера, мини-драйвер видеопорта также отвечает за поддержку DirectX. Например, одним из важнейших преимуществ DirectX перед GDI является то, что пользовательскому приложению предоставляется прямой доступ к буферу видеопамяти. Такая возможность достигается при помощи мини-драйвера видеопорта, который отображает буфер в область виртуальных адресов, доступную для пользовательских приложений. Драйвер экрана взаимодействует с мини-драйвером видеопорта посредством вызовов функции EngDeviceloControl графического механизма, которые переда-
124 Глава 2. Архитектура графической системы Windows ются диспетчером ввода-вывода ядра NT драйверу видеопорта, а затем поступают к мини-драйверу видеопорта. Назначение драйвера экрана Хотя прямой доступ к видеооборудованию предоставляется мини-драйвером видеопорта, обычно он находится под управлением драйвера экрана. Задачи, решаемые драйвером экрана, делятся на четыре класса. О Предоставление и запрет доступа к ресурсам графического оборудования, включая отображение видеопамяти, банки и внеэкранную кучу, аппаратный курсор мыши, аппаратную палитру, кэш кистей и аппаратную поддержку DirectDraw/Direct3D/OpenGL (если она присутствует). Как правило, драйвер экрана передает запросы драйверу видеопорта. О Передача механизму GDI сведений о возможностях оборудования и драйвера через специальные структуры данных GDI. О Создание и актуализация поверхностей. Это могут быть как DIB-поверхно- сти, управляемые GDI, так и DIB-поверхности, управляемые устройством, а также поверхности других форматов, управляемые устройством. О Реализация основных (или всех) графических операций с поверхностью посредством создания перехватчиков. Драйвер экрана также может создать поверхность, управляемую GDI, и разрешить графическому механизму работать с ней напрямую. Инициализация драйвера экрана Драйвер экрана обычно представляет собой DLL режима ядра, которая импортирует функции только из графического механизма (win32k.sys). Главная точка входа драйвера экрана, по смещению совпадающая с DllMainCRTStartup, обычно называется DrvEnableDriver. Функция DrvEnableDriver обычно вызывается GDI после загрузки драйвера. Драйвер выполняет простую проверку версии и возвращает механизму GDI таблицу функций, в которой перечислены все поддерживаемые им функции DDL Таблица возвращается в виде структуры DRVENABLEDATA. Каждая функция DDI, поддерживаемая драйвером экрана Windows NT/2000, обладает заранее определенным индексом. В Windows 2000 в общей сложности определяется 89 функций DDL Например, у DrvEnableDriver существует парная функция DrvDisableDriver, имеющая индекс 8. После получения таблицы функций графический механизм обычно вызывает DrvEnablePDEV, чтобы драйвер создал экземпляр физического устройства и вернул важную информацию о графическом оборудовании и драйвере. При вызове DrvEnablePDEV графический механизм передает драйверу копию структуры DEVM0DEW, описывающей характеристики графического устройства. Для видеоадаптеров DEVM0DEW определяет частоту развертки, разрешение и особые режимы (например, вывод в оттенках серого или чересстрочный (interlaced) вывод). Для принтеров DEVM0DEW содержит еще более важную информацию о типе и размере бумаги, ориентации, качестве печати, количестве копий и способе подачи.
Драйверы экрана 125 DrvEnablePDEV создает экземпляр структуры PDEV (Physical DEVice), определяемой драйвером и содержащей закрытые данные драйвера. Функция возвращает манипулятор структуры PDEV, по которому механизм GDI ссылается на данный экземпляр физического устройства при последующих вызовах. Кроме того, DrvEnablePDEV заполняет структуру GDI INFO, из которой GDI получает информацию о разрешении устройства, физическом размере, цветовом формате, битах DAC, коэффициенте вертикального сжатия, размере палитры, порядке цветовых плоскостей, размере и формате полутонового узора, частоте обновления и т. д. Информация также возвращается в структуре DEVINF0, описывающей графические возможности драйвера, шрифты по умолчанию, количество шрифтов устройства и формат смешивания цветов. Флаги графических возможностей сообщают графическому механизму, поддерживает ли устройство обработку кривых Безье, геометрическое расширение, типы заполнения многоугольников (ALTERNATE или WINDING), печать EMF, сглаживание текста, аппаратную растеризацию шрифтов, JPEG, загрузку гамма-таблиц, аппаратную поддержку альфа-курсора и т. д. После вызова DrvEnablePDEV графический механизм производит собственную внутреннюю инициализацию физического устройства и в завершение вызывает DrvCompleteDEV, сообщая тем самым, что физическое устройство готово к работе. При завершении использования PDEV вызывается функция DrvDisablePDEV, которая обычно освобождает память, выделенную для физического устройства. Прежде чем GDI начнет вывод на устройство, графический механизм вызывает DrvEnableSurface, чтобы драйвер создал графическую поверхность. Если видеоадаптер работает с кадровым буфером в стандартном формате DIB, он создает поверхность, управляемую GDI, путем вызова EngCreateBitmap. В противном случае драйвер экрана самостоятельно выделяет память для поверхности и при помощи EngCreateDeviceSurface сообщает графическому механизму размер и совместимый формат поверхности. В любом случае драйвер устройства затем вызывает EngAssociateSurface, указать, какие вызовы графических операций DDI должны перехватываться драйвером. При этом используется информация из таблицы функций, возвращаемой при вызове DrvEnableDriver. Завершив работу с поверхностью, графический механизм вызывает DrvDisableSurface, чтобы разрешить драйверу освободить все выделенные ресурсы. Вывод на поверхность, перехват и возврат После успешного создания поверхности графический механизм передает драйверу устройства графические вызовы в соответствии с установленными битами возможностей и флагами перехвата (hooking flags) для поверхности. В табл. 2.1 перечислены все операции вывода DDI, которые могут перехватываться при выводе на поверхность. Как видно из таблицы, у каждой графической операции DDI в механизме GRE имеется аналог с точно совпадающими параметрами, предназначенный для выполнения этой операции на стандартной поверхности в формате DIB. Ниже перечислены варианты реализации графических вызовов DDI драйвером. О Для поверхностей в стандартном формате DIB драйвер может отказаться от перехвата графических функций DDI и поручить обработку всех графических операций GRE. Так, пример драйвера из Windows 2000 DDK не перехватывает ни одной функции (ddk\src\video\displays\framebuf).
126 Глава 2. Архитектура графической системы Windows Таблица 2.1. Перехватываемые графические операции Windows 2000 Индекс H00K_BITBLT H00KSTRETCHBLT H00K_PLGBLT H00KTEXT0UT H00KPAINT HOOKJTROKEPATH H00KJILLPATH H00K_STR0KEANDFILLPATH H00KLINET0 H00KC0PYBITS HOOKMOVEPANNING H00K_SYNCHR0NIZE H00K_STRETCHBLTR0P HOOKSYNCHRONIZEACCESS H00K_TRANSPARENTBLT H00K_ALPHABLEND H00K_GRADIENTFILL Функция графического механизма EngBitBIt EngStretchBlt EngPlgBlt EngTextOut EngPaint EngStrokePath EngFillPath EngStrokeAndFillPath EngLineTo EngCopyBits EngMovePanning EngSynchronize EngStretchBltROP EngSynchroni zeAccess EngTransparentBlt EngAlphaBlend EngGradientFill Функция драйвера DrvBitBlt DrvStretchBlt DrvPlgBlt DrvTextOut DrvPaint DrvStrokePath DrvFillPath DrvStrokeAndFillPath DrvLineTo DrvCopyBits DrvMovePanning DrvSynchronize DrvStretchBltROP DrvSynchroni zeAccess DrvTransparentBlt DrvAlphaBlend DrvGradientFill О Если поверхность управляется устройством, драйвер может перехватывать несколько обязательных примитивов и предоставить графическому механизму разбивку всех остальных вызовов на примитивы. Драйвер также может перехватывать все графические вызовы для применения аппаратного ускорения или оптимизированной программной реализации. Скажем, пример драйвера s3virge из Windows 2000 DDK обеспечивает оптимизированную ассемблерную реализацию для некоторых видов блиттинга между экранным буфером и внеэкранными DIB. В этом случае вызовы DrvBitBlt должны перехватываться. О Функция-перехватчик, реализуемая драйвером, может вызывать системные функции графического механизма для разбиения сложной области отсечения на более простые группы прямоугольников. Драйвер также может возвращать вызовы GRE, когда он не справляется с поставленной задачей. Например, упоминавшийся выше драйвер s3virge для выполнения блиттинга между двумя внеэкранными DIB возвращает вызов графическому механизму.
Драйверы экрана 127 Дополнительные возможности драйвера Помимо инициализации/завершения и перехвата графических вызовов DDI, драйвер экрана также должен представить графическому механизму точки входа для выполнения следующих операций: О управление растрами устройств: DrvEnableDeviceBitmap и DrvDisableDeviceBitmap; О управление палитрой: DrvSetPalette; О реализация кистей, смешение цветов (dithering) и поддержка ICM (Image Color Management): DrvRealizeBrush, DrvDitherColor, DrvIcmCreateColorTransform, DrvIcmCheckBitmapsBits и т. д.; О обходные обращения к GDI: DrvEscape, DrvDrawEscape (например, для сквозной передачи данных PostScript); О управление мышью: DrvSetPointerShape, DrvMovePointer; О получение информации о шрифтах и поддержка шрифтовых драйверов: Drv- QueryFont, DrvQueryFontTree, DrvQueryFontData, DrvQueryFontFile, DrvQueryTrueType- FontTable и т. д.; О печать: DrvQuerySpoolType, DrvStartDoc, DrvEndDoc, DrvStartPage, DrvEndPage и т. д. (печать подробно рассматривается в главе 3); О поддержка OpenGL: DrvSetPixelFormat, DrvSwapBuffers и т. д.; О поддержка DirectDraw/Direct3D: DrvEnableDirectDraw, DrvGetDirectDrawInfo и DrvDi sableDi rectDraw. Многие из перечисленных функций являются необязательными и реализуются драйвером графического устройства лишь при наличии у устройства соответствующих аппаратных возможностей. Поддержка DirectDraw/Direct3D на уровне драйвера экрана Если драйвер экрана поддерживает DirectDraw/Direct3D, он должен экспортировать точку входа DrvGetDirectDrawInfo, через которую начинается взаимодействие графического механизма с аппаратной поддержкой DirectDraw. Когда приложение DirectDraw/Direct3D создает экземпляр объекта DirectDraw, графический механизм сначала вызывает DrvGetDirectDrawInfo, чтобы получить от драйвера экрана информацию о поддержке DirectDraw. DrvGetDirectDrawInfo возвращает GDI сведения о поддержке DirectDraw/Direct3D, включая описание аппаратных возможностей и список поддерживаемых форматов. Информация об аппаратных возможностях (аппаратный блиттинг, масштабирование, поддержка альфа-канала, отсечение, цветовые ключи, оверлеи, палитры, поддержка Direct3D и т. д.) кодируется в структуре DDHALINFO. Информация о форматах видеопамяти возвращается в виде массива структур VIDE0MEM0RYINF0. Каждый формат кодируется 32-разрядным значением FOURCC, которое служит для обозначения типа носителя в мультимедийном API. DirectDraw использует FOURCC для описания форматов пикселов, поддерживаемых видеоадаптерами, и форматов пикселов в сжатых текстурах.
128 Глава 2. Архитектура графической системы Windows Затем графический механизм вызывает функцию DrvEnableDirectDraw, тем самым приказывая драйверу включить аппаратную поддержкуБ1гес1Вга\у. Функция DrvEnableDirectDraw заполняет три структуры адресами функций косвенного вызова для интерфейсов IDirectDraw, IDirectDrawSurface и IDirectDrawPalette. Нечто похожее происходит в главной точке входа драйвера экрана, DrvEnableDriver, возвращающей индексированный список функций косвенного вызова для реализации DDL Каждая из трех структур данных, возвращаемых DrvEnableDirectDraw, соответствует одному из основных компонентов интерфейса DirectDraw (см. описание DirectDraw API). В структуру входит поле флагов, определяющее поддерживаемые функции косвенного вызова, и указатели на все функции косвенного вызова данного интерфейса. Например, структура DDCALLBACKS относится к реализации DirectDraw и содержит информацию о девяти функциях косвенного вызова. Если в поле dwFlags присутствует флаг DDHALCB32CREATESURFACE, то поле Create- Surface содержит адрес функции косвенного вызова, которой обычно присваивается имя DdCreateSurface. В действительности интерфейс IDirectDraw содержит более девяти методов. Часть методов реализуется внутри клиентской DLL DirectDraw Win32, а остальные функции уровня драйвера возвращаются в других структурах (например, DD_NTCALLBACKS). Поддержка Direct3D со стороны драйвера экрана обозначается несколькими флагами в структуре DDHALINFO, возвращаемой DrvGetDirectDrawInfo. Флаг DDCAPS3D в поле ddCaps.dwCaps означает, что обслуживаемое драйвером устройство поддерживает ускорение трехмерной графики. Флаги поля ddCaps.ddsCaps (например, DDSCAPS3DDEVICE, DDSCAPSTEXTURE и DDSCAPSZBUFFER) описывают трехмерные возможности для поверхности видеопамяти. Кроме того, DDHALINFO содержит указатель на структуру D3DNTHALCALLBACKS, содержащую адреса функций косвенного вызова DDI для Direct3D. В табл. 2.2 перечислены некоторые структуры, в которых передаются сведения о функциях поддержки DirectDraw/Direct3D в драйвере экрана. Таблица 2.2. Функции косвенного вызова DDI, обеспечивающие поддержку DirectDraw/Direct3D (неполный список) Структура Функции DD_CALLBACKS DdDestroyDriver, DdCreateSurface, DdSetColorKey, DdSetMode, DdWai tForVerti cal Bl ank, DdCanCreateSurface, DdCreatePalette, DdGBetSeal Line, DdMapMemory DD_SURFACECALLBACKS DdDestroySurface, DdFli p, DdSetCli pLi st, DdLock, DdUnlock, DdBlt, DdSetColorKey, DddAddAttachedSurface, DdGetBltStatus, DdGetFlipStatus, DdUpdateOverlay, DdSetOverlayPositions, DdSetPalette DD_PALETTECALLBACKS DdDestroyPalette, DdSetEntri es DD_NTCALLBACKS DdFreeDriverMemory, DdSetExclusiveMode, DdFlipToGDISurface DD_C0L0RC0NTR0LCALLBACKS DdColorControl DD_MISCELLANEOUSCALLBACKS DdGetAvai1Dri verMemory
Драйверы принтеров 129 Структура Функции D3DNTHAL_CALLBACKS D3dContextCreate, D3dContextDestroy, D3dContextDestroyAl1, D3dSceneCapture, D3dTextureCreate, D3dTextureDestroy, D3dTextureSwap, D3dTextureGetSurf D3DNTHAL_CALLBACKS3 D3dClear2, D3dValidateTextureStageState, D2dDrawPrinritives2 Даже при кратком знакомстве с интерфейсами GDI DDI и DirectDraw/ Direct3D DDI становится очевидным, что они имеют абсолютно разную архитектуру. Ниже перечислены наиболее принципиальные различия. О Интерфейс GDI DDI работает на более примитивном уровне, нежели Direct- Draw/Direct3D DDI. Следовательно, перед обращением к интерфейсу GDI DDI графическому механизму приходится выполнить большое количество предварительных операций, тогда как путь DirectDraw/Direct3D, ведущий от Win32 API, проще и прямее. О В поддержке GDI DDI драйвер экрана всегда может получить помощь от графического механизма, вернув ему полученный вызов. В интерфейсе Direct- Draw/Direct3D DDI программная эмуляция выполняется в клиентской DLL пользовательского режима, поэтому драйвер экрана не сможет воспользоваться помощью уровня драйвера режима ядра. О Для получения информации о драйверных функциях косвенного вызова в интерфейсе GDI DDI используется простой и легко расширяемый способ, тогда как в DirectDraw/Direct3D DDI функции косвенного вызова описываются массивом структур данных. Итак, мы рассмотрели процесс инициализации драйвера экрана для поддержки GDI, DirectDraw и Direct3D и даже кое-что узнали об основных точках входа и функциях косвенного вызова драйвера. Мы еще вернемся к этой теме и посмотрим, как эти функции косвенного вызова используются графическим механизмом, при исследовании внутренних структур данных графической системы Windows (глава 3) и отслеживании работы GDI/DirectDraw (глава 4). Драйверы принтеров Драйвер экрана, описанный в предыдущем разделе, составляет всего лишь один из классов драйверов графических устройств, поддерживаемых ОС. Другой важный класс драйверов графических устройств управляет работой устройств создания жестких копий — принтеров, плоттеров, факсов и т. д. Драйверы этих графических устройств имеют одинаковую структуру, поэтому все, что будет сказано о драйвере принтера, в принципе относится и к драйверу факса. В соответствии с технологией вывода устройства создания жестких копий делятся на три класса. О Текстовые устройства — традиционные устройства строчной печати, способные выводить только обычный текст. В среде Windows, ориентированной на графический интерфейс пользователя в режиме WYSIWYG, они встречают-
130 Глава 2. Архитектура графической системы Windows ся довольно редко. Драйвер устройства передает текстовому устройству текстовый поток с минимальным форматированием (разрывы строк и страниц). О Растровые устройства — к этой категории относятся матричные принтеры, факсы и большинство струйных принтеров. Драйвер устройства должен уметь преобразовывать графические команды DDI в растровое изображение и кодировать его на языке принтера (PCL3, ESC/2 и т. д.). О Векторные устройства — лазерные принтеры, плоттеры, принтеры PostScript, а также некоторые современные модели DeskJet. Хотя на некоторых из этих устройств непосредственная печать происходит в растровом режиме, все они принимают входные данные в векторном формате, а растровое преобразование производится самим принтером. Драйвер векторного устройства обычно преобразует графические команды DDI в команды на языке принтера — например, PCL5, PCL6, HPGL, HPGL/2 или PostScript. Векторные устройства наряду с векторными данными обычно принимают и растровые данные. Полный драйвер принтера для Windows NT/2000 состоит из нескольких компонентов, из которых обязательными являются лишь первые два: О DLL графического вывода, которая (как и драйвер экрана) получает графические команды DDI, переводит их на язык принтера и отправляет данные спулеру; О интерфейсная DLL, обеспечивающая пользовательский интерфейс к параметрам конфигурации принтера и спулеру для управления установкой, конфигурацией и выводом сообщений об ошибках; О необязательный процессор печати помогает процессу спулера передавать задания на печать; О необязательный языковой монитор обеспечивает двустороннюю связь между спулером и пользователем; О необязательный монитор порта передает готовые к печати данные драйверам аппаратных портов. Управляющие драйверы принтеров от Microsoft Компания Microsoft создала несколько стандартных драйверов, которые могут использоваться производителями принтеров для подключения специализированных драйверов в виде модулей (вместо разработки полноценных драйверов). О Универсальный драйвер принтера (Unidrv) предназначен для принтеров без поддержки PostScript — например, матричных принтеров, DeskJet и LaserJet. Производителю принтера остается лишь предоставить мини-драйвер для Unidrv, который в минимальном варианте представляет собой текстовый GPD-файл с описанием возможностей принтера, параметров, условных ограничений и команд принтера. Архитектура Unidrv допускает использование подключаемых модулей (plug-ins). Модуль визуализации обеспечивает нестандартную обработку графических команд, полутоновые преобразования и построение данных, готовых к передаче на принтер. Модуль пользовательского интерфейса позволяет настраивать страницы свойств принтера, структуру DEVM0DE и процесс обработки событий печати.
Драйверы принтеров 131 О Драйвер принтера PostScript (Pscript) предназначен для принтеров с поддержкой PostScript. Мини-драйвер PostScript состоит из текстового PPD-файла с описанием характеристик принтера, двоичного NTF-файла с описанием шрифтов принтера, модуля визуализации и модуля пользовательского интерфейса. О Драйвер плоттера представляет собой стандарт Microsoft для поддержки плоттеров, совместимых с языком HPGL/2 (Hewlett-Packard Graphics Language). Мини-драйвер плоттера представляет собой двоичный PCD-файл с описанием характеристик плоттера. Модули для него не создаются, поскольку язык HPGL/2 имеет достаточно жесткую структуру. Windows 2000 DDK содержит полный исходный текст драйвера плоттера от Microsoft. В стандартных драйверах Microsoft использована очень интересная архитектура, управляемая данными. Эти драйверы поддерживают тысячи моделей всевозможных принтеров, представленных на рынке, а отличия между ними часто нивелируются до небольших различий в файлах данных. GPD-файл драйвера Unidrv во всех подробностях описывает ориентацию листа, входной лоток, размер бумаги, разрешение, режим печати, тип носителя, цветовой режим, качество печати, полутоновые преобразования, конфигурационные ограничения, команды конфигурации принтера и команды печати. Нередко бывает так, что при выпуске новой модели принтера производителю остается лишь обновить GPD- файл и внести в него сведения о новом режиме печати с повышенным разрешением. GPD-файлы пишутся на достаточно выразительном языке с поддержкой простейших типов данных (целые числа, пары, строки и списки) и даже переменных с командами выбора. И все же интересно, почему Microsoft не воспользовалась стандартными языками типа Lisp или Prolog, которые обладают большими возможностями и легче обрабатываются? Графическая библиотека DLL драйвера принтера Графическая DLL драйвера принтера очень похожа на драйвер экрана, рассматривавшийся в разделе «Драйверы экрана». Главное отличие заключается в том, что в драйвере принтера должны присутствовать дополнительные точки входа для управления документами и страничным выводом, но зато не нужны точки входа для поддержки курсора мыши, DirectDraw и Direct3D. Разумеется, драйвер принтера должен поддерживать основные функции, отвечающие за инициализацию драйверов графических устройств, — а именно, DrvEnableDriver, DrvEnablePDEV, DrvCompletePDEV, DrvDisablePDEV, DrvEnableSurface, DrvDisableSurface и, наконец, DrvDisableDriver. Драйвер принтера также должен обеспечивать разбивку печатного документа на отдельные страницы и запросы, специфические для конкретного принтера. В табл. 2.3 перечислены дополнительные точки входа, которые должны или могут поддерживаться принтером. У драйверов принтеров Windows 2000 есть одна интересная особенность — они могут существовать не только в виде DLL режима ядра, но и в режиме пользовательских DLL. Microsoft прикладывает особые усилия к выводу драйверов принтеров из адресного пространства ядра в пользовательское адресное пространство. Но помните: драйвер принтера может импортировать функции графического механизма win32k.sys, недоступные на уровне GDI. Для решения этой
132 Глава 2. Архитектура графической системы Windows проблемы Windows 2000 GDI экспортирует подмножество функций графического механизма, чтобы драйвер принтера пользовательского режима мог работать с ними напрямую. Графический механизм особым образом передает вызовы, обращенные к драйверу принтера, из режима ядра в пользовательский режим, после чего GDI преобразует обращения к механизму от драйвера из пользовательского режима обратно в режим ядра. Драйверы принтеров, работающие в пользовательском режиме, обладают рядом преимуществ, в числе которых — снижение стоимости разработки, повышенная гибкость используемых средств Win32 API и, что еще важнее, — снижение степени вмешательства в ядро ОС. Если драйвер принтера работает в пользовательском режиме, то DLL драйвера должна экспортировать функции DrvEnableDriver, DrvDisableDriver и DrvQueryDriver, причем функция DrvQueryDriverlnfo должна выдавать соответствующую информацию при обработке запроса DRVQUERYUSERMODE. Все стандартные драйверы принтеров Microsoft Windows 2000 являются драйверами пользовательского режима. Таблица 2.3. Специализированные точки входа драйвера принтера Точка входа Назначение DrvQueryDriverlnfo (необязательна) DrvQueryDeviceSupport (необязательна) DrvStartDoc DrvEndDoc DrvStartPage DrvSendPage DrvStartBanding DrvQueryPerBandlnfо (необязательна) DrvNextBand (необязательна) Интерпретация запроса зависит от драйвера. В настоящее время используется для получения информации от драйверов пользовательского режима Интерпретация запроса зависит от устройства. В настоящее время используется для запросов о поддержке JPEG и PNG Сообщает драйверу о готовности GDI к передаче документа Сообщает драйверу о завершении передачи документа Сообщает драйверу о готовности GDI к передаче графических команд новой страницы Сообщает драйверу о завершении передачи графических команд страницы — драйвер может передать обработанные данные спулеру У драйвера запрашивается информация о том, где на странице должна начинаться разбивка на полосы У драйвера запрашивается структура PERBANDINF0 с информацией о размере и разрешении полосы Сообщает драйверу о завершении передачи графических команд полосы — драйвер может передать обработанные данные спулеру Главной точкой входа драйвера принтера по-прежнему остается DrvEnable- Printer. Когда приложение вызывает CreateDC, чтобы создать контекст устройства для принтера, графический механизм проверяет, загружен ли драйвер принтера. Если драйвер не загружен, он загружается, после чего вызывается функция DrvEnableDriver.
Драйверы принтеров 133 Функция DrvEnablePDEV драйвера принтера вызывается графическим механизмом, когда приложение вызывает функцию CreateDC для принтера. По сравнению с драйвером экрана эта функция сложнее, поскольку ей приходится учитывать многочисленные параметры печати, переданные в структуре DEVM0DE. В частности, драйверу приходится регулировать разрешение вывода в зависимости от выбранного качества печати, переключать размеры бумаги для альбомного (landscape) режима, вычислять размеры области вывода на основании размера бумаги и передавать информацию о полях. В структуре DEVM0DE могут передаваться и другие параметры печати — режим двусторонней печати, разбор по копиям, количество экземпляров, количество страниц на листе, а также специализированные параметры, обеспечиваемые другими компонентами системы печати. Например, в Windows 2000 двусторонняя печать, разбор по копиям, печать нескольких эк- земпляров-и режим печати нескольких страниц на листе реализуются стандартным процессором печати Windows 2000, благодаря чему базовый драйвер принтера должен обеспечивать лишь вывод отдельной страницы. Драйвер растрового принтера может создать поверхность, управляемую графическим механизмом, при вызове DrvEnableSurface и затем потребовать, чтобы графический механизм выполнял весь вывод (или его большую часть). Однако при этом возникает проблема — принтер работает на значительно большем разрешении, чем экран монитора, поэтому одновременное воспроизведение всей страницы потребует чрезмерных затрат памяти. Например, страница формата Letter в разрешении 300 х 300 dpi состоит из 300 х 300 х 11,5 х 8 пикселов — получается около 8 мегапикселов. При одноцветной печати на 300 dpi страничный растр занимает около 1 мегабайта, а при печати на цветном принтере с разрешением 600 dpi и 24-битным цветом размер страничного растра приближается к 96 мегабайтам. Чтобы свести огромные затраты памяти до разумного уровня, графический механизм позволяет разделить страницу на горизонтальные полосы. Если разделить страницу формата Letter на равные полосы шириной в 1 дюйм, 96 мегабайт уменьшаются до 4,17 мегабайта. В этом случае драйвер должен при помощи функции EngMarkBandingSurface сообщить графическому механизму о том, что при выводе поверхности используется разбивка. Векторному принтеру не нужно воспроизводить сразу всю страницу в виде растра; вместо этого он последовательно транслирует графические команды DDI в команды принтера. Как правило, создается поверхность, управляемая устройством, и драйвер перехватывает графические команды DDL На векторных принтерах разбивка обычно не применяется. После загрузки драйвера и создания структур данных для физического устройства и поверхности GDI при содействии графического механизма передает весь документ драйверу принтера. Процесс вывода выглядит примерно так: DrvStartDocCDocName. Jobld) for (int i = 0; i<nPageNo; i++) { DrvStartPageO: DrvStartBandingO; for (BOOL bMoreBands=TRUE; bMoreBands; ) { DrvQueryPerBandInfo(); for (c=0: c<nCommands; C++) )
134 Глава 2. Архитектура графической системы Windows DrawCcommandCc]): bMoreBands = DrvNextBandO; } DrvSendPageO; } DrvEndDocO: Вывод всего задания печати производится между вызовами DrvStartDoc и Drv- EndDoc, а вывод отдельной страницы — между вызовами DrvStartPage и DrvEndPage. Для каждой страницы сначала вызывается функция DrvStartBanding, которая сообщает драйверу о начале разбивки на полосы. Графический механизм вызывает функцию DrvQueryPerBandlnfo для получения геометрической информации о выводимой полосе, после чего перебирает команды GDI, хранящиеся в файле, и передает все команды, задействованные в текущей полосе. После завершения полосы GDI переходит к следующей полосе и т. д. до завершения всей страницы. Графические команды DDI либо воспроизводятся GRE непосредственно на поверхности, управляемой GDI, либо передаются функциям, предоставленным драйвером. Для векторных устройств преобразованные команды могут передаваться спулеру при каждой операции графического вывода. Для растровых устройств полученный растр проходит полутоновое преобразование в соответствии с цветовой глубиной принтера, делится на несколько цветовых плоскостей (например, в схеме CYMK), сжимается и кодируется на языке принтера. При передаче данных спулеру в качестве параметра указывается манипулятор, переданный драйверу при вызове DrvEnablePDEV. Функция EngWriteSpooler использует этот манипулятор для общения со спулером. Драйвер принтера также может поддерживать функции DrvEscape и DrvDraw- Escape для «официального» и «закулисного» взаимодействия приложения с драйвером. Например, драйвер PostScript позволяет вставлять данные в формате PostScript прямо в поток данных при помощи функции DrvDrawEscape. Информация о поддержке этой возможности может быть получена при помощи функции DrvEscape. В процессе обработки задания печати драйвер принтера может вызвать функцию EngCheckAbort, чтобы проверить, не отменил ли пользователь печать. Ресурсы, выделенные для поверхности, должны освобождаться функцией драйвера DrvDisableSurface. При вызове функции DeleteDC приложением или GDI также вызывается функция DrvDisablePDEV, что позволяет драйверу освободить ресурсы, выделенные для физического устройства. Если приложение вызывает ResetDC в процессе печати, GDI вызывает DrvEnablePDEV для создания нового экземпляра. Далее вызывается функция DrvResetPDEV, чтобы драйвер мог скопировать информацию из старого экземпляра в новый, затем вызывается DrvDisableSurface для старого устройства, после чего вся последовательность операций вывода начинается заново для нового устройства. Перед выгрузкой графической DLL принтера вызывается функция DrvDisableDriver. Драйвер принтера для вывода документа HTML Вы когда-нибудь размышляли над вопросом, как преобразовать страницу документа в растровое изображение? Конечно, существует простое решение — со-
Драйверы принтеров 135 хранить копию экрана. А если на экране помещается лишь часть сохраняемой информации? Сохранять несколько копий экрана и «сшивать» их вручную не хочется. А вдруг вам захочется преобразовать документ, состоящий из 100 страниц, в 100 растровых изображений? Существует простое решение — раздобыть драйвер принтера для печати в растровом формате... или написать его самостоятельно. Обычно на печать выводятся многостраничные документы, поэтому работать с драйвером принтера, который генерирует растр всего для одной страницы, неудобно. Если вы можете сгенерировать один растр, значит, вы можете легко сгенерировать документ HTML, связывающий воедино отдельные растры. Ниже описан пример драйвера принтера, генерирующий выходные данные на языке HTML. Конечно, не существует принтера, который бы принимал документы HTML в качестве непосредственного ввода, однако вы можете легко выполнить печать в файл и просмотреть полученный документ в браузере. HTML не является языком векторного вывода, поэтому мы не сможем однозначно преобразовать графические команды DDI в команды HTML. Вместо этого страница выводится в виде растрового изображения, которое затем связывается с документом HTML. Чтобы этот проект мог воплотиться на практике, необходимо поставить разумные цели. По этой причине мы ограничимся поддержкой одного размера бумаги (11,5 х 8 дюймов, формат Letter), одного разрешения (96 dpi) и одного цветового формата (24-битный DIB). В результате поверхность для вывода всей страницы будет занимать 2,46 мегабайта, что позволит обойтись без разбивки на полосы. Самостоятельная реализация команд GDI — дело хлопотное; вместо этого мы создадим поверхность, управляемую GDI, и поручим всю черновую работу графическому механизму. На самом деле писать специальный драйвер для вывода нескольких растров было бы неразумно, но этот пример дает очень хорошее представление об устройстве GDI. По этой причине наш драйвер перехватывает все стандартные вызовы DDI, чтобы вы могли проверить работу всех параметров. Весь фактический вывод перепоручается графическому механизму. Построение страницы HTML со ссылками на растровые изображения не сводится к простой передаче потока данных спулеру — растровые изображения приходится сохранять в отдельных файлах. К счастью, в win32k.sys предусмотрены простые операции с файлами, отображаемыми на память (функции EngMapFile и EngUnmapFile). Наша реализация драйвера принтера HTML состоит из двух частей: класса KDevice, в котором инкапсулируется физический блок данных устройства, созданный при вызове DrvEnablePDEV, а также операции с устройством, и интерфейсной части DDL Ниже приведен заголовочный файл класса KDevice. struct Pair; class KDevice { int nNesting: // документ, страница int nPages; // количество выведенных страниц
136 Глава 2. Архитектура графической системы Windows void Write(const char * pStr); void WriteW(const WCHAR * pwStr); void WriteHex(unsigned val); void WritelnCconst char * pStr = NULL): void Write(DWORD index, const PAIR * pTable); char * CopyBlock(char * pDest. void * pData. int size); void CopySurface(char * pDest. const SURFOBJ * pso); void LogCalKint index, const void * para, int parano); public: int width: int height: HPALETTE hPalette: HSURF hSurface: HDEV hDevice: HANDLE hSpooler; int nlmage; void Create(void) // ширина в дюймах * 10 // высота в дюймах * 10 // При использовании GDI палитра нужна // даже для 24-битных растров // Стандартная поверхность. // управляемая устройством // Манипулятор устройства GDI // Манипулятор спулера nNesting » 0 nPages = 0 nlmage = 0 void DumpSurface(const SURFOBJ * psoBM); BOOL Ca11Engine(int index, const void * para, int parano): BOOL StartDoc(LPCWSTR pszDocName. const void * firstpara. int parano): BOOL EndDoc(const void * firstpara. int parano): BOOL StartPage(const void * firstpara. int parano): BOOL SendPage(const void * firstpara. int parano): Класс KDevice содержит переменные для хранения размеров бумаги, а также манипуляторов палитры, поверхности, устройства и спулера. Другие переменные класса предназначены для внутреннего использования. Переменная nNesting обеспечивает правильную последовательность вызовов DrvStartDoc, DrvEndDoc, DrvStartPage и DrvSendPage; переменная nPages содержит количество печатаемых страниц; переменная nlmage — порядковый номер ссылки HTML на графическое изображение. В классе KDevice нет ни полноценного конструктора, ни деструктора, ни виртуальных функций — мы не хотим включать runtime-поддержку C++ в DLL режима ядра. Частичная инициализация выполняется методом Create. Методы Write сбрасывают данные HTML в поток данных, передаваемых спулеру. Метод DumpSurface записывает содержимое DIB-поверхности в отдельный растровый файл.
Драйверы принтеров 137 Обратите внимание на функцию KDevice: :LogCall, предназначенную для вывода имени точки входа драйвера и списка параметров. При вызове передается индекс точки входа, адрес первого параметра в стеке и количество параметров (при передаче параметров используются соглашения языка Pascal). Функция ограничивается простой выдачей шестнадцатеричного дампа параметров. void KDeviсе::LogCal1(int index, const void * firstpara. int parano) { Write("<li>"); WriteCindex, Pair_DDIFunction); // Имя функции берется из таблицы Writer С): const unsigned * pDWORD = (const unsigned *) firstpara; for (int i=0; i<parano; i++) { WriteHex(pDWORD[i]); if ( i!=(parano-l) ) WriteC, "); } Writeln(")</li>M); } Функция KDevice:: Call Engine проверяет указатель на KDevice; если указатель отличен от NULL, она вызывает функцию LogCal 1. Функция Call Engine вызывается всеми графическими функциями DDI драйвера перед возвращением вызова графическому механизму. Таким образом, реализация Call Engine может избирательно блокировать некоторые функции DDI, чтобы заставить графический механизм разбить их на упрощенные вызовы. Интерфейс DDI драйвера реализуется в файле HTMLDrv.cpp. Файл начинается с таблицы поддерживаемых точек входа: const DRVFN DDI_Funcs[] « { INDEX DrvEnablePDEV, INDEX DrvCompletePDEV, INDEX DrvResetPDEV. INDEXJDrvDisablePDEV, INDEX_DrvEnableSurface, INDEX_DrvDisableSurface. INDEX DrvStartDoc. INDEX_DrvEndDoc. INDEX_DrvStartPage. INDEX_DrvSendPage. INDEX DrvStrokePath, INDEX DrvFillPath. INDEX DrvStrokeAndFillPath INDEX_DrvLineTo. INDEX DrvPaint, INDEX DrvBitBlt. INDEX DrvCopyBits. (PFN) DrvEnablePDEV, (PFN) DrvCompletePDEV. (PFN) DrvResetPDEV. (PFN) DrvDisablePDEV. (PFN) DrvEnableSurface, (PFN) DrvDisableSurface. (PFN) DrvStartDoc. (PFN) DrvEndDoc, (PFN) DrvStartPage. (PFN) DrvSendPage. (PFN) DrvStrokePath. (PFN) DrvFillPath. .(PFN) DrvStrokeAndFillPath. (PFN) DrvLineTo. (PFN) DrvPaint. (PFN) DrvBitBlt, (PFN) DrvCopyBits.
138 Глава 2. Архитектура графической системы Windows INDEX_DrvStretchBlt, (PFN) DrvStretchBlt. INDEX_DrvTextOut. (PFN) DrvTextOut }: Функция DrvEnableDriver после несложной проверки передает таблицу функций графическому механизму: BOOL APIENTRY DrvEnableDriver(UL0NG iEngineVersion. ULONG cj. DRVENABLEDATA *pded) { // Проверить параметры if (iEngineVersion < DDI_DRIVER_VERSION) { EngSetLastError(ERROR_BAD_DRIVER_LEVEL); return FALSE; if (cj < sizeof(DRVENABLEDATA)) { EngSetLastError(ERROR_INVALID_PARAMETER); return FALSE; pded->iDriverVersion = DDI_DRIVER_VERSION; pded->c = sizeof(DDI_Hooks) / sizeof(DDI_Hooks[0]); pded->pdrvfn - (DRVFN *) DDIJooks; return TRUE; } Ниже приведена часть функции DrvEnablePDEV, создающей новый экземпляр класса KDevice. Эта функция заносит информацию о возможностях драйвера в структуры GDI INFO и DEVINFO в соответствии со значениями полей полученной структуры DEVMODW. В данном случае программа проверяет ориентацию бумаги. DHPDEV APIENTRY DrvEnablePDEV(DEVMODEW *pdm LPWSTR ULONG HSURF ULONG ULONG ULONG DEVINFO HDEV PWSTR HANDLE pwszLogAddress, cPat. *phsurfPatterns, cjCaps. *pdevcaps, cjDevInfo. *pdi. hdev, pwszDeviceName. hDriver) if ( (cjCaps<sizeof(GDIINFO)) || (cjDevInfo<sizeof(DEVINFO)) ) { EngSetLastError(ERRORJNVALIDJ>ARAMETER); return FALSE: KDevice * pDevice; // Создать объект физического устройства. Маркер - HTMD pDevice - (KDevice *) EngAllocMem (FL_ZER0_MEM0RY. sizeof(KDevice). 'DMTH'):
Драйверы принтеров 139 if (pDevice — NULL) { EngSetLastError(ERROR_OUTOFMEMORY); return NULL; pDevice->Create(); pDevice->hSpooler - hDriver; pDevice->hPalette - EngCreatePalette (PAL_BGR. 0. 0, 0. 0. 0); if (pdm — NULL || pdm->dmOrientation == DMORIENT_PORTRAIT) { pDevice->width - PaperWidth: pDevice->height = PaperHeight; } else { pDevice->width - PaperHeight; pDevice->height - PaperWidth; } // Инициализация GDI INFO пропущена // Инициализация DEVINFO пропущена pdi->hpalDefault = pDevice->hPalette; return (DHPDEV) pDevice; } Функция DrvEnableSurface создает полностраничную 24-битную DIB-поверх- ность, управляемую GDI, и сообщает графическому механизму, что драйвер желает перехватывать некоторые вызовы DDL Обратите внимание: размеры бумаги задаются в десятых долях дюйма, чтобы избежать выполнения операций с плавающей точкой в ядре. Поверхность инициализируется белым цветом не при создании, а при вызове DrvStartPage. HSURF APIENTRY DrvEnableSurfaceCDHPDEV dhpdev) { «Device * pDevice = («Device *) dhpdev; SIZEL sizl - { pDevice->width * Dpi / 10, pDevice->height * Dpi / 10 }; pDevice->hSurface = (HSURF) EngCreateBitmap(sizl, sizl.cy. BMF_24BPP, BMFJOZEROINIT. NULL); if (pDevice->hSurface — NULL) return NULL: EngAssociateSurface(pDevice->hSurface, pDevice->hDevice. HOOKJITBLT | HOOKJTRETCHBLT | HOOKJEXTOUT | H00K_PAINT | H00K_STR0KEPATH | HOOKJILLPATH | HOOK_STROKEANDFILLPATH | H00K_C0PYBITS | H00K_LINET0); return pDevice->hSurface; }
140 Глава 2. Архитектура графической системы Windows Хотя драйвер HTML перехватывает некоторые графические функции, вся реализация сводится к простому выводу информации о параметрах, после чего вызов возвращается графическому механизму. Ниже приведен лишь один типичный пример, который дает представление и об остальных реализациях. В первом параметре всех графических вызовов DDI передается указатель на SURF0BJ — структуру данных, используемую графическим механизмом для представления поверхности вывода. Поле dhpdev содержит манипулятор физического устройства, который предоставляется драйвером и возвращается функцией DrvEnablePDEV. В данном случае манипулятор преобразуется в указатель на KDevice. BOOL АРI ENTRY DrvBitBlt(SURFOBJ *psoTrg. SURFOBJ *psoSrc. SURFOBJ *psoMask. CLIPOBJ *pco, XLATEOBJ *pxlo. RECTL *prclTrg, POINTL *pptlSrc. POINTL *pptlMask. BRUSHOBJ *pbo. POINTL *pptlBrush. R0P4 rop4) { KDevice * pDevice = (KDevice *) psoTrg->dhpdev; if ( pDevice->CallEngine(INDEX_DrvBitBlt. SpsoTrg, 11) ) return EngBitBltCpsoTrg. psoSrc. psoMask. pco, pxlo. prclTrg. pptlSrc, pptlMask, pbo, pptlBrush, rop4): else return FALSE; } Так выглядят самые интересные компоненты драйвера HTML. Ниже приведена сокращенная версия результатов, полученных при печати стандартной тестовой страницы. В web-браузере она выглядит вполне прилично (рис. 2.9). <html> <head> <tit!e>Test Page </title> </head> <body bgcolor=#80B090><font size=l> <ol> <li>DrvStartDoc(e2229558, ele86488. 2)</li> <li>DrvStartPage(e2229558)</li> <1i>DrvFinPath(e2229558. fld2fa68 l)</li> <li>DrvBitBlt(e2229558. 0. 0. fld2f7b0 fOfO)</li> <li>DrvText0ut(e2229558. fld2f824 dOd)</li> <li>DrvText0ut(e2229558. fld2f824 dOd)</li> <li>DrvSendPage(e22295586)</1i> <p><img src="c:\htmd_000.bmp "></p> <li>DrvEndDoc(e2229558, 0)</li> </ol> </body> </html>
Итоги 141 f е^ММсс, е^МЬШ e'AbWicTWd) ' Tjl j 281. DrvTextOut(el390e58, ft>317828, e2727d08,fb31792c, 0,ft>317834, 1 e25154cc, e2515520, e251541c, dOd) j 282. DrvSendPage(el390e58) Sm i 4Wnclorvys2coo О : ■! .- J",.... Windows 2000 Printer Test Page J - j ►n Рис. 2.9. Тестовая страница в браузере Как видите, упрощенный драйвер принтера (а точнее, его графическая DLL) несложен. Его можно было бы еще упростить, отказавшись от вывода параметров. Настоящий драйвер принтера устроен гораздо сложнее. Если вы захотите убедиться в этом, обратитесь к примеру драйвера плоттера из Microsoft Windows 2000 DDK или драйверу PostScript из Windows NT 4.0 DDK. Впрочем, полноценный, качественный, оптимизированный драйвер принтера по своей сложности превосходит примеры, включенные в DDK. Итоги В этой главе мы рассмотрели общую архитектуру графической системы Windows, архитектуру клиентской стороны Win32 GDI, архитектуру DirectX и архитектуру системы печати, познакомились с графическим механизмом, драйверами экрана и принтера. Была создана программа для отслеживания графических системных вызовов как на стороне клиента, так и на стороне сервера. Глава завершается описанием простого драйвера принтера, генерирующего данные в формате HTML. Главное, что читатель должен вынести из этой главы, — это блок-схемы с изображением различных уровней архитектуры графической системы. Вы должны в общих чертах представлять, какие аспекты графической системы Windows NT/2000 обслуживаются тем или иным компонентом системы и как вызовы графических функций Win32 API реализуются различными компонентами в цепочке обработки. Хотя в этой главе рассматривались общие вопросы архитектуры, а материал сопровождался блок-схемами, столь нелюбимыми многими программистами, дальнейшее изложение будет более конкретным. В главе 3 мы изучим недоку-
142 Глава 2. Архитектура графической системы Windows ментированные структуры данных, на которых основана работа GDI и DirectDraw, а потом перейдем к более интересной главе 4 и познакомимся с закулисным устройством графической системы. Примеры программ На прилагаемом компакт-диске находятся полные исходные тексты программ, описанных в этой главе (табл. 2.4). Таблица 2.4. Программы главы 2 Каталог проекта Описание 1 Samples\Chapt_02\SysCall Вывод списка системных функций DLL подсистемы Win32 (ntdll.dll, gdi32.dll и user32.dll) и системных функций ядра ОС (ntoskrnl.exe, win32k.sys) Samples\ChaptJ)2\Timer Сравнительный анализ четырех способов хронометража: GetTickCount, timeGetTime, QueryPerformanceCounter и чтение счетчика тактов процессора Intel Pentium Samples\Chapt_02\HTMLDrv Драйвер принтера (построение страниц HTML, ведение протокола команд DDI и воспроизведение страниц на внедренном растре)
Глава 3 Внутренние структуры данных GDI/ DirectDraw Интерфейс Windows API часто называют «объектно-базированным» (object based) — не путайте с «объектно-ориентированным» (object oriented), это не одно и то же. При использовании Win32 API часто приходится создавать разнообразные объекты, выполнять с ними различные операции при помощи функций и в конечном счете уничтожать их. Операционная система полностью управляет внутренним представлением объекта, а в распоряжении программиста находится только манипулятор (handle). В GDI используются десятки всевозможных объектов — контексты устройств, логические перья, логические кисти, логические шрифты, логические палитры, аппаратно-независимые растры, DIB-секции и т. д. Но для любого объекта вы имеете дело только с манипулятором — таинственным числом, с которым и сделать-то ничего нельзя (кроме передачи при вызове функции GDI). В этой главе во всех подробностях описаны манипуляторы GDI и, что еще важнее, — стоящие за ними структуры данных. Вы узнаете, что означает каждый бит в манипуляторе GDI, как устанавливается соответствие между манипулятором и элементом таблицы объектов GDI, и даже познакомитесь со структурами данных, используемыми во внутреннем представлении всех объектов GDI. Кроме того, в этой главе рассматриваются структуры данных DirectDraw. При помощи здравого смысла, «хакерских» приемов, утилит от Microsoft и нескольких программ, написанных специально для этой главы, мы добьемся главной цели — понимания ключевых структур данных GDI/DirectDraw. Возможно, вы не слишком интересуетесь техническими подробностями структур данных GDI. Тем не менее знание общих принципов внутреннего устройства GDI/DirectDraw повысит вашу квалификацию в программировании для Windows. В этой главе также рассматриваются некоторые полезные приемы — например, просмотр содержимого виртуальной памяти, написание драйвера
144 Глава 3. Внутренние структуры данных GDI/DirectDraw устройства режима ядра (нет, не для принтера!) и установка расширения отладчика WinDbg для исследования ядра NT/2000 на том же компьютере. Манипуляторы и объектно-ориентированное программирование В объектно-ориентированных языках и средах объектом называется совокупность данных и функций, моделирующая некоторую сущность в реальном или воображаемом мире. Объекты делятся на классы в соответствии со своими общими чертами. Как правило, в объектно-ориентированных языках центральное место занимают именно определения классов; объект всего лишь является экземпляром класса, созданным во время работы программы. В Win32 API также определяются различные виды объектов. Самыми распространенными объектами GDI являются контексты устройств, логические перья, логические кисти, логические шрифты, логические палитры и аппаратно- зависимые растры. Таким образом, все объекты контекстов устройств являются экземплярами класса контекста устройства, а все логические палитры являются экземплярами класса логической палитры. Класс и объект Классы в объектно-ориентированных языках содержат как данные (переменные класса), так и программный код (функции класса). Доступ к членам класса (то есть его переменным и функциям) контролируется определением класса. Одни члены класса объявляются закрытыми (private) и защищенными (protected), а другие — открытыми (public). При создании экземпляра класса сначала выделяется память, а затем вызывается конструктор. Применение закрытых и защищенных членов класса позволяет изолировать внутреннюю реализацию класса от программного кода, использующего этот класс. Концепции инкапсуляции и маскировки реализации являются краеугольными камнями объектно-ориентированного программирования. В Win32 API реализация некоторых классов также хорошо инкапсулируется на системном уровне. Как будет показано позже, объекты всегда содержат переменные — обычно оформленные в структуру данных или даже в сложную иерархическую сеть структур. Для каждого класса определяется стандартный набор функций, применяемых к объектам этого класса. Например, контекст устройства является объектом GDI, экземпляром класса контекста устройства. В этом классе определяются такие функции, как GetSetColor и SetTextColor, предназначенные для получения/назначения цвета текста. Инстинкт программиста подсказывает, что цвет текста является переменной класса, ассоциированной с объектом контекста устройства, но мы понятия не имеем, где и в каком внутреннем представлении он хранится. Другими словами, внутренняя реализация контекста устройства полностью скрыта от прикладных программистов.
Манипуляторы и объектно-ориентированное программирование 145 Инкапсуляция и маскировка реализации В обычной практике объектно-ориентированного программирования некоторые члены класса объявляются закрытыми или защищенными и не могут использоваться кодом клиентской стороны. Однако компилятор все равно должен точно знать все члены класса, их типы и имена. По крайней мере, компилятору должен быть известен точный размер экземпляра класса для выделения памяти. Это может вызвать массу проблем при модульной разработке программ. Каждый раз, когда в классе изменяется переменная или функция, всю программу приходится компилировать заново. Программы, откомпилированные для старых версий определения класса, не будут работать с новыми версиями. Для решения этой проблемы создаются абстрактные базовые классы. Абстрактный базовый класс при помощи виртуальных функций определяет интерфейс с клиентскими программами, полностью абстрагируясь от его реализации, что способствует маскировке реализации и улучшению модульности программы. Крайним проявлением маскировки реализации являются СОМ-интерфейсы, которые представляют собой классы без переменных, состоящие из одних чисто виртуальных функций. Класс, содержащий чисто виртуальную функцию, не может использоваться для создания объектов. Программист должен создать на его основе производный класс, реализовать все чисто виртуальные функции и создать экземпляр производного класса. Для маскировки производного класса от клиента создается специальная статическая функция, предназначенная для создания объектов. Например, COM DLL всегда экспортируют функцию DllGetClassObject, которая (при содействии фабрики класса) отвечает за создание новых объектов, поддерживаемых COM DLL. Для маскировки реализации от клиентской стороны класса обычно определяется специальная функция, которая создает экземпляры производного класса и выделяет память для них, и другая функция, которая уничтожает экземпляры с освобождением выделенной памяти. Объекты Win32 API можно рассматривать как реализованные с использованием абстрактного базового класса, не содержащего ни одной переменной. Внутреннее представление данных объекта полностью скрыто от пользовательского приложения. Преимущества такого подхода огромны; программа, откомпилированная для Win32s (подмножество Win32 API, реализованное в Windows 3.1), без всяких проблем работает в Windows 95, а программа, откомпилированная для Windows 95, прекрасно работает в Windows NT и Windows 2000. Двоичный код программ Win32 совместим с разными версиями операционной системы, реализующими Win32 API на одном типе процессора. Хотя возможности использования единого Win32 API все же не безграничны, значительное подмножество Win32 API реализуется на разных платформах с одинаковой семантикой. Что касается GDI, реализация этого интерфейса для Windows 95/98 в значительной степени основана на его 16-разрядной реализации для Windows 3.1; в Windows NT 3.51 GDI функционирует в виде отдельного системного процесса, работающего в пользовательском режиме, а в Windows NT 4.0 и Windows 2000 используется 32-разрядный графический механизм режима ядра. Между этими реализациями существуют заметные различия, однако их безукоризненная маскировка в Win32 API обеспечивает переносимость программ. GDI обычно
146 Глава 3. Внутренние структуры данных GDI/DirectDraw поддерживает несколько функций для создания экземпляра объекта и несколько функций для его уничтожения. Чтобы продемонстрировать аналогию между объектно-ориентированным программированием и Win32 API, попробуем написать на C++ минимальную псев- до-реализацию GDI. Результат приведен в листинге 3.1. Листинг 3.1. Псевдо-реализация GDI на C++ // gdi.h class _GdiObj { public: virtual int GetObjectType(void) = 0; virtual int GetObject(int cbBuffer, void * pBuffer) =0; virtual bool DeleteObject(void) = 0; virtual bool UnrealizeObject(void) * 0; }: class _Pen : public _GdiObj { public: virtual int GetObjectType(void) { return 0BJ_PEN: } virtual int GetObjectCint cbBuffer. void * pBuffer) = 0: virtual bool DeleteObject(void) = 0: virtual bool UnrealizeObject(void) { return true: } }: _Pen * _CreatePen(int fnPenStyle. int nWidth. COLORREF crColor): // gdi.cpp #define STRICT #define WIN32_LEAN_AND_MEAN #include <windows.h> #include "gdi.h" class _RealPen : public _Pen { LOGPEN m_LogPen: public: _RealPen(int fnPenStyle. int nWidth. COLORREF crColor) T m_LogPen.lopnStyle = fnPenStyle: m_LogPen.lopnWidth.x = nWidth: m_LogPen.lopnWidth.y - 0:
Манипуляторы и объектно-ориентированное программирование 147 m_LogPen.lopnColor - crColor; } int GetObjectCint cbBuffer, void * pBuffer) { if ( pBuffer==NULL ) return sizeof(LOGPEN); else if ( cbBuffer>=sizeof(m_LogPen) ) { memcpy(pBuffer, & m_LogPen. sizeof(m_l_ogPen)); return sizeof(LOGPEN); } else { SetLastError(ERRORJNVALID_PARAMETER); return 0; } } bool DeleteObject(void) { if ( this ) { delete this; return true; } else return false; } }: _Pen * _CreatePen(int fnPenStyle. int nWidth, COLORREF crColor) { return new _RealPen(fnPenStyle. nWidth. crColor); } void Test(void) { _Pen * pPen = _CreatePen(PS_SOLID, 1. RGB(0. 0. OxFF)); //// pPen->DeleteObject(); } В листинге 3.1 определяется абстрактный базовый класс GdiObj, представляющий обобщенный объект GDI. Он состоит из четырех чисто виртуальных функций и не содержит ни одной переменной. Обобщенный класс пера Реп определяется как производный от GdiObj; он реализует две виртуальные функции и оставляет две другие чисто виртуальными. Функция CreatePen создает экземпляры класса Реп. В файле реализации (GDI.cpp) определяется настоящий класс пера (Real Pen), который хранит информацию о пере в структуре L0GPEN. Класс Real Pen представляет собой полную реализацию абстрактного класса Реп с конструктором и двух оставшихся виртуальных функций. Функция CreatePen
148 Глава 3. Внутренние структуры данных GDI/DirectDraw создает экземпляр класса Real Pen и передает указатель на него вместо указателя на обобщенный класс пера Реп. Клиентская сторона не знает, сколько памяти занимает объект пера, откуда выделяется эта память и как реализуются виртуальные функции. Все эти подробности остаются скрытыми. Клиентская сторона должна знать лишь имена методов интерфейса, их назначение и семантику. Указатели и манипуляторы При создании объекта в объектно-ориентированном языке необходимо выделить блок памяти для хранения переменных объекта. Если класс содержит виртуальные функции, вместе с переменными в памяти создается дополнительный указатель на таблицу всех реализаций виртуальных функций данного класса. В таких языках, как C++, центральное место занимают указатели на объекты. Указатели передаются всем не статическим функциям класса, что позволяет обращаться к переменным объекта и вызывать нужные виртуальные функции. В C++ указатель на текущий объект обозначается ключевым словом this. Рисунок 3.1 на примере класса _RealPen (см. листинг 3.1) показывает, на что именно ссылается указатель на объект. В классе Real Pen 16 байт нужны для хранения единственной переменной класса, mLogPen, и еще 4 байта — для указателя на таблицу виртуальных функций. Следовательно, для каждого объекта необходимо выделить минимум 20 байт. Указатель на таблицу виртуальных функций ссылается на блок из четырех указателей на функции. В приведенном примере две функции реализуются классом _Реп, а две другие — классом JtealPen. Экземпляр Knacca_RealPen Таблица виртуальных функций для класса _RealPen Class Указатель" на объект Указатель на таблицу виртуальных функций LOGPEN lopnStyle lopnWidth lopnColor w & _Pen::GetObjectType & _RealPen::GetObject & _RealPen::DeleteObject & _Pen::UnrealizeObject Рис. З.1. Пример представления объекта в C++ В СОМ указатель на объект обычно называется интерфейсным указателем и ссылается на указатель на таблицу функций. В приведенном примере функция CreatePen создает экземпляр Real Pen, но возвращает указатель на класс Реп. Как и в СОМ, клиентский код ничего не знает о внутреннем представлении данных. Хотя в Win32 API для каждого объекта где-то в памяти выделяется блок данных, разработчики Microsoft не стали возвращать указатель на него пользовательскому приложению. Возможно, это было сделано из тех соображений, что указатель несет слишком много информации для «умных» программистов — он выдает точное местонахождение объекта в памяти. Указатели позволяют выпол-
Манипуляторы и объектно-ориентированное программирование 149 нять операции чтения/записи с внутренним представлением объектов, которое операционная система предпочла бы скрыть от пользователя. Кроме того, указатели затрудняют совместное использование объектов из адресных пространств разных процессов. Чтобы скрыть эту информацию от программистов, функции создания объектов Win32 вместо указателя обычно возвращают манипулятор (handle) объекта. Манипулятор определяется как число, которое однозначно идентифицирует объект и может использоваться для косвенных ссылок на него. Взаимосвязь объектов с манипуляторами не документирована, ее неизменность в будущих версиях Windows не гарантируется, и вообще все подробности известны разве что Microsoft да еще нескольким производителям системных утилит. Можно считать, что отображение на манипуляторы указателей на объекты и наоборот производится двумя функциями Encode и Decode, прототипы которых приведены ниже. HANDLE EncodeCvoid * pObject); // Преобразовать указатель в манипулятор void * Decode(HANDLE hObject): // Преобразовать манипулятор в указатель Тождественное отображение Иногда значение манипулятора может совпадать со значением указателя на объект; в этом случае функции Encode и Decode ограничиваются преобразованием типа, а связь между указателями на объекты и манипуляторами является тождественной. В Win32 API манипулятор экземпляра (HINSTANCE) или манипулятор модуля (HM0DULE) представляет собой обычный указатель на образ РЕ-файла, отображаемого на память. Считается, что функция LockResource фиксирует ресурс в памяти и отображает глобальный манипулятор на указатель, но в действительности их значения совпадают. Манипулятор ресурса, возвращаемый функцией Load- Resource, в действительности представляет собой «замаскированный» указатель на ресурс, отображенный на память. Табличное отображение Наиболее распространенным механизмом установления связи между объектом и его манипулятором является табличное отображение. Операционная система строит таблицу всех используемых объектов. При создании нового объекта в таблице находится пустая строка, которая заполняется данными объекта. При удалении объекта его переменные удаляются из памяти, а соответствующий элемент таблицы освобождается для последующего использования. В табличной схеме управления объектами индексы таблицы являются хорошими кандидатами на роль манипуляторов, а преобразование указателей в манипуляторы и наоборот выполняется тривиально. В Win32 API информация о объектах ядра хранится в таблицах уровня процесса. К категории объектов ядра относятся мьютексы, семафоры, события, ключи реестра, порты, файлы, символические ссылки, каталоги объектов, файлы, отображаемые на память, программные потоки, рабочие столы, таймеры и т. д. Для управления многочисленными объектами ядра каждый объект создает свою
150 Глава 3. Внутренние структуры данных GDI/DirectDraw собственную таблицу объектов ядра. Одним из компонентов исполнительной части ядра NT/2000 является диспетчер объектов (object manager), предназначенный для управления объектами ядра. Одна из функций диспетчера объектов называется ObReferenceObjectByHandle. Согласно документации DDK, эта функция проверяет права доступа для заданного манипулятора объекта и, если доступ разрешен, возвращает указатель на тело объекта. В сущности, эта функция преобразует манипулятор объекта в указатель на объект с некоторой дополнительной проверкой безопасности. Также существует очень хорошая утилита HandleEx (доступна на сайте www.sysinternals.com), предназначенная для составления списка объектов ядра на компьютерах с Windows NT/2000. Когда манипулятора недостаточно Хотя манипуляторы обеспечивают почти идеальную абстракцию, защиту и маскировку информации, они также причиняют немало хлопот программистам. Поскольку Win32 API ориентируется на применение манипуляторов, Microsoft не документирует внутреннее представление объектов и не описывает операции с ними. Никаких эталонных реализаций — в распоряжении программиста только прототипы функций, документация Microsoft и книги, материал которых в большей или меньшей степени основан на документации Microsoft. Первая категория проблем, с которыми сталкиваются программисты, связана с системными ресурсами. Никто не знает, какие ресурсы затрачиваются при создании объекта и получении его манипулятора, поскольку внутреннее представление объекта неизвестно. Как действовать программисту — хранить и заново использовать объект или же удалить его при первой возможности? В GDI поддерживаются три типа растров — какой тип следует выбрать, чтобы сократить затраты системных ресурсов? Главным ресурсом компьютера является процессорное время. Маскировка внутреннего представления от программиста затрудняет оценку сложности выполнения некоторых операций при проектировании сложных алгоритмов. Допустим, вы строите сложный регион средствами GDI; какую сложность имеет ваш алгоритм — линейную, квадратичную, кубическую? Полная маскировка реализации также усложняет отладку. Если после 5 минут работы ваша программа начинает «гнать мусор», вероятно, где-то происходит утечка ресурсов, но где именно и как ее исправить? Если вы — системный администратор и в вашей системе работают сотни приложений, как при хронической нехватке системных ресурсов вычислить источник бед? Похоже, единственным инструментом для борьбы с утечками ресурсов является программа BoundsChecker, которая использует специальные средства наблюдения для поиска несоответствий при создании и удаления объектов. И все же самые серьезные проблемы возникают с совместимостью программ. Почему в Windows 95 программа может передавать объекты GDI от одного процесса к другому, а в Windows NT/2000 — не может? Почему Windows 95 не справляется с обработкой больших аппаратно-независимых растров? Похоже, «идеальная» абстракция API в разных системах обладает разной семантикой. В основной части этой главы мы поближе познакомимся с манипуляторами GDI и исследуем недокументированный мир, скрытый за манипуляторами Windows NT/2000.
Расшифровка манипуляторов объектов GDI 151 Расшифровка манипуляторов объектов GDI При создании объекта GDI вы получаете манипулятор этого объекта. В зависимости от типа создаваемого объекта манипулятор может относиться к типу HPEN, HBRUSH, HFONT, HDC и т. д. Однако самым общим типом манипулятора объекта GDI является тип HGDI0BJ. Тип HGDI0BJ определяется как указатель на void. Определение типа HPEN, используемое при компиляции, изменяется в зависимости от состояния макроса компиляции STRICT. Если макрос определен, то HPEN определяется следующим образом: struct HPEN { int unused; }; typedef struct HPEN * HPEN; Если макрос STRICT не определен, то определение HPEN выглядит так: typedef void * HANDLE; typedef HANDLE HPEN; Проще говоря, если макрос STRICT определен, HPEN определяется как указатель на структуру с одним неиспользуемым полем, а если нет — как указатель на void. Компилятор C/C++ позволяет передать указатель на любой тип вместо указателя на void (но не наоборот!). Два указателя на разные типы, отличные от void, не являются взаимозаменяемыми. При определении STRICT компилятор выдает предупреждения при некорректной подмене типов манипуляторов объектов GDI или других объектов (скажем, HWND, HMENU и т. д.), а без определения STRICT вы можете спокойно смешивать разные типы манипуляторов, не рискуя получить предупреждение на стадии компиляции. Например, при определении STRICT можно передать HPEN функции, получающей HGDI0BJ (скажем, функции DeleteObject), но нельзя без предварительного преобразования передать HGDI0BJ функции, получающей HBRUSH (такой, как функция FillRgn). Столь четкое разделение различных манипуляторов GDI имитирует иерархию классов объектов GDI, хотя на самом деле иерархии классов не существует. Для каждого объекта GDI может быть создан только один манипулятор, поэтому вы не сможете создать другой манипулятор для объекта простым дублированием. Обычно манипуляторы объектов GDI действительны только в рамках конкретного процесса — другими словами, манипулятор может использоваться только тем процессом, который его создал. Манипуляторы, переданные из других процессов, недействительны. Как правило, объекты GDI могут создаваться несколькими разными способами, а уничтожаются одной функцией DeleteObject с параметром HGDI0BJ. Помимо непосредственного создания объекта, можно воспользоваться функцией GetStockObject для получения манипулятора заранее созданного объекта GDI или же при помощи более сложных функций преобразовать ресурс, связанный с модулем, в объект GDI. Функции загрузки ресурсов GDI (такие, как LoadBitmap или Loadlmage) создают необходимые объекты GDI за вас. Впрочем, все сказанное выше можно найти и в электронной документации. Мы же хотим узнать о манипуляторах объектов GDI гораздо больше. Подробности работы манипуляторов GDI Windows NT/2000 никогда не документировались, к тому же не существует никаких готовых программ, способных упростить наши исследования. Поэтому мы напишем свою, довольно сложную программу
152 Глава 3. Внутренние структуры данных GDI/DirectDraw GDIHandles, главное окно которой состоит из трех страниц-вкладок. Строение, реализация и использование этой программы будут рассматриваться постепенно по мере изложения материала. А пока взгляните на первую страницу Decode GDI Handle (Расшифровка манипулятора GDI), изображенную на рис. 3.2. Decode GDI Handle | Legate ODI Handle Tabb | Desode BOI Hm<$& Table | C*6fct,0E; jGet Stock Ob j ect (SYSTEM_FIXED_FONT) Jjxl Copi&s^ 1шШёммш£В!£мм2м1 01900011 01900013 0190001S 0190001S 01b00017 oiboooie 01b00018 018a0028 018a0027 018a00Z9 018&0021 018a002S GetStockObject GetStockObject GetStockObj ect GetStockObject GetStockObject GetStockObj ect GetStockObj ect GetStockObject GetStockObject GetStockObject GetStockObject GetStockObject (BLACKJBP.USH) 0 <DKGRAY_BRUSH) 0 (H0LL0IiT__BRUSH) 0 <NULL_BRUSH) 0 (BLACK_PEN) 0 (HULL_PEN) 0 <WHITE_PEN) 0 <ANSI_FIXED_FONT) 0 <ANSI_VAR_FONT) 0 <DEFAULT_GUI_FONT) ( (SYSTEH_FONT) 0 (SYSTEH FIXED FONT) Щ, 0ВЗМРСШТ OK Рис. З.2. Расшифровка манипуляторов GDI В верхней части страницы расположены два комбинированных списка для выбора способа создания объекта (от разнообразных вызовов GetStockObject до CreateEnhMetafile) и количества экземпляров (от 1 до 65 536). После выбора способа создания и количества экземпляров щелкните на кнопке Create — программа создаст заданное количество объектов. Манипуляторы, полученные в результате создания объектов, выводятся в большом списке в шестнадцатеричной записи, вместе с именем функции-создателя и порядковым номером в группе (нумерация начинается с 0). Цикл создания завершается при неудачном вызове функции-создателя или в случае возвращения того же манипулятора, что и при предыдущем вызове. Давайте проведем несколько экспериментов, понаблюдаем за процессом создания объектов GDI и проанализируем закономерности в значениях манипуляторов.
Расшифровка манипуляторов объектов GDI 153 Манипуляторы стандартных объектов — константы Манипуляторы, возвращаемые функцией GetStockObject, всегда являются константами независимо от порядка их вызова. Например, функция GetStockObject (BLACK_ BRUSH) возвращает стандартный (встроенный) объект черной кисти с манипулятором 0x01900011; GetStockObject (BLACKPEN) возвращает стандартный объект черного пера с манипулятором 0х01Ь00017 и т. д. Даже если запустить два экземпляра этой программы, GetStockObject возвращает одинаковые значения в обоих процессах. Можно предположить, что встроенные объекты создаются при инициализации системы и используются заново всеми процессами. HGDIOBJ не является указателем Хотя в заголовочных файлах Windows манипуляторы GDI определяются как указатели, при ближайшем рассмотрении они совершенно не похожи на указатели. Создайте несколько объектов GDI и посмотрите на полученные манипуляторы; вы увидите, что их значения лежат в интервале от 0x01900011 до 0xba040389. Если бы значение типа HGDIOBJ в действительности было указателем, как утверждает заголовочный файл wingdi.h, то нижняя граница соответствовала бы недействительному указателю на свободную область пользовательского адресного пространства, а верхняя адресовала бы адресное пространство ядра. Можно предположить, что манипуляторы GDI на самом деле не являются указателями. Обращает на себя внимание еще один факт: значения манипуляторов, полученных при вызовах GetStockObject(BLACKPEN) и GetStockObject (NULLPEN), отличаются всего на 1, что явно меньше объема памяти, необходимого для хранения внутренних объектов GDI, если бы манипуляторы действительно были указателями. Поэтому можно уверенно сказать, что HGDIOBJ не является указателем. Максимальное количество манипуляторов GDI на уровне процесса — 12 000 Если вызвать функцию CreatePen 16 раз, будет создано 16 новых логических перьев. Но если попытаться создать 65 536 логических перьев, далеко не все вызовы функции будут успешными. В процессе тестирования успешно создается около 12 000 перьев, а остальные вызовы завершаются неудачей. Обратите внимание: когда это происходит, значения в полях комбинированных списков Creator и Copies отображаются неправильно. Более того, вы даже не сможете сохранить копию экрана клавишей PrintScreen, если главное окно программы GDIHandles будет на переднем плане. Но если активизировать другую программу, клавиша PrintScreen работает нормально. ПРИМЕЧАНИЕ По результатам наших тестов выяснилось, что Windows NT устанавливает процессные квоты на количество манипуляторов GDI, чтобы один процесс не мог нарушить работу всей системы GDI. Однако в первой версии Windows 2000 это ограничение не соблюдается, что можно считать дефектом.
154 Глава 3. Внутренние структуры данных GDI/DirectDraw И еще одно интересное обстоятельство: когда CreatePen перестает создавать новые объекты GDI в процессе, другие процессы в системе работают нормально. Похоже, для каждого процесса устанавливается предельное количество активных манипуляторов GDI, равное примерно 12 000. Максимальное количество манипуляторов GDI на уровне системы — 16 384 Теперь запустите два экземпляра программы GDIHandles в одной системе и попробуйте вызвать CreatePen по 8192 раза в каждом процессе. Первый процесс создаст все запрашиваемые объекты, а второй остановится где-то на 7200. Когда второй процесс перестает создавать объекты, система приходит в замешательство. Даже если переключиться на другой процесс, весь вывод на экран нарушается. Хотя из документации Microsoft возникает впечатление, что объекты GDI пользуются только локальными ресурсами процесса, эксперимент наглядно показывает, что объекты GDI выделяются из общесистемного пула ресурсов. Таким образом, интенсивное использование ресурсов GDI одним процессом влияет на работу других процессов. 8192 + 7200 - 15 392. Учитывая манипуляторы объектов GDI, используемые окном GDIHandles и другими процессами, можно обоснованно предположить, что максимальное количество манипуляторов GDI в системе равно 16 384. Часть HGDIOBJ содержит индекс Создавая многочисленные объекты GDI при помощи программы GDIHandles, обратите особое внимание на младшие слова отображаемых двойных слов; вы увидите, что их значения лежат в интервале от 0x0000 до 0x3FFF. Младшие слова манипуляторов всегда уникальны в границах процесса; более того, их уникальность сохраняется и между процессами, если не считать стандартных объектов. Значения младших слов манипуляторов иногда увеличиваются, иногда уменьшаются, причем закономерность порой сохраняется даже между процессами. Например, при вызове CreatePen в одном процессе младшее слово манипулятора может быть равно 0х03С1, а при следующем вызове CreatePen в другом процессе младшее слово манипулятора оказывается равным 0х03С2. У этих фактов имеется простое объяснение: младшее слово HGDIOBJ представляет собой индекс в таблице системного уровня, содержащей информацию о 16 384 (0x4000) объектах GDI. Часть HGDIOBJ содержит тип объекта GDI В Windows NT/2000 манипулятор объекта GDI всегда возвращается в виде 32- разрядного числа. В программе GDIHandles это число отображается в виде 8 шест- надцатеричных цифр. Как было показано выше, младшие 4 шестнадцатеричные цифры манипулятора GDI содержат индекс объекта, поэтому мы можем заняться старшими 4 шестнадцатеричными цифрами.
Расшифровка манипуляторов объектов GDI 155 Если создавать объекты по типам (например, создать несколько кистей, затем несколько перьев, несколько шрифтов, контекстов устройств и т. д.), нетрудно убедиться в том, что манипуляторы GDI однотипных объектов имеют нечто общее — а именно, третья и четвертая шестнадцатеричные цифры их манипуляторов практически всегда совпадают. У кистей третья и четвертая цифры манипулятора всегда равны 0x90 и 0x10; у перьев — 0x30 и ОхЬО; у шрифтов — 0x8а и 0x0а; у палитр — 0x88 и 0x08; у растров — 0x05, а у контекстов устройств — 0x01. Манипуляторы, у которых старший бит этой группы цифр равен 1, принадлежат стандартным объектам. Таким образом, у нас имеется достаточно оснований, чтобы утверждать: третья и четвертая шестнадцатеричные цифры манипулятора содержат признак типа объекта и признак стандартного объекта GDI. Смысл двух оставшихся шестнадцатеричных цифр 32-разрядного манипулятора GDI пока остается неясным. Давайте подведем итог того, что мы знаем о манипуляторах Windows NT/2000. Манипулятор объекта GDI начинается с 8 старших бит, смысл которых пока неизвестен; далее следуют: 1 бит признака стандартного объекта, 7 бит с информацией о типе объекта и 16-битного индекса, старшие 4 бита которого всегда равны 0. Нам известны значения 7-битного типа объекта для контекста устройства, региона, растра, палитры, шрифта, кисти, расширенного метафайла, пера и расширенного пера. Структура манипулятора GDI изображена на рис. 3.3. 1 бит — признак стандартного объекта 7 бит — тип объекта Рис. 3.3. Структура манипулятора GDI в Windows NT/2000 Ниже приведены некоторые определения типов и функций C++, упрощающих кодирование и расшифровку манипуляторов GDI. typedef enum { gdi_objtypeb_dc - 0x01. gdi_objtypeb_region - 0x04. gdi_objtypeb_bitmap = 0x05. gdi_objtypeb_palette = 0x08. gdi_objtypeb_font = 0x0a. gdi_objtypeb_brush - 0x10. gdi_objtypeb_enhmetafile = 0x21.
156 Глава 3. Внутренние структуры данных GDI/DirectDraw gdi_objtypeb_pen = 0x30. gdi_objtypeb_extpen = 0x50 }: inline HGDIOBJ makeHGDIOBJ(unsigned top. bool stock, unsigned objtype. unsigned index) { return ((top & OxFF) « 24) | ((stock & 1) « 23) | ((objtype & 0x7F) « 23) | (index & 0x3FFF); } inline bool IsStockObj(HGDIOBJ hGDIObj) { return ((unsigned) hGDIObj) 0x00800000; } inline unsigned GetObjType(HGDIOBJ hGDIObj) { return ((unsigned) hGDIObj) » 16) & 0x7F; } inline unsigned GetObjIndex(HGDIOBJ hGDIObj) { return ((unsigned) hGDIObj & 0x3FFF); } При помощи этих функций можно узнать, принадлежит ли манипулятор стандартному объекту GDI, а также получить тип и индекс объекта в таблице. Поиск таблицы объектов GDI В ходе экспериментов раздела «Расшифровка манипуляторов объектов GDI» мы выяснили, что младшее слово манипулятора объекта GDI (HGDIOBJ) содержит индекс в интервале от 0 до 0x3FFF. Возникает предположение, что где-то существует таблица объектов GDI, находящаяся под управлением системы (скорее всего — GDI), и индексы относятся к элементам этой таблицы. Такие таблицы существовали в Win3.1 и Win95, поэтому вполне логично было бы встретить их и в Windows NT и Windows 2000. В этом разделе мы займемся поисками этой недокументированной таблицы. В этом месте программисты Windows обычно спрашивают, нельзя ли получить указатель на эту таблицу при помощи какой-нибудь функции Win32 API, а еще лучше — функции MFC, автоматически генерируемой мастером MSVC. На оба вопроса ответ будет отрицательным. Ни в одном официальном документе не подтверждается даже само существование этой таблицы, не говоря уже о документированных функциях API для работы с ней. Давайте ненадолго выйдем из образа программиста, знающего только API и библиотечные функции, и представим себя на месте Шерлока Холмса.
Поиск таблицы объектов GDI 157 Прежде всего предположим, что в системе действительно существует таблица объектов GDI и мы собираемся найти доказательства — то есть обнаружить эту таблицу в памяти. Если таблица существует, скорее всего, она может читаться из пользовательского адресного пространства. Дело в том, что gdi32.dll находится в пользовательском адресном пространстве, рядом с вашими DLL- и ЕХЕ-файлами. Если бы эта таблица могла читаться только из адресного пространства ядра, то для решения простейших задач вроде вызова GetObjectTypeO GDI32 приходилось бы обращаться за помощью к графическому механизму режима ядра win32k.sys, что сильно замедлило бы работу GDI. Поэтому наше второе предположение заключается в том, что таблица объектов GDI по крайней мере читается из программ пользовательского режима — то есть находится в пределах первых 2 Гбайт адресного пространства Win32. Если таблица объектов GDI существует, то при создании нового объекта GDI в нее заносятся новые данные, что приводит к изменению ее содержимого. Обратите внимание: в данном случае речь идет именно о создании нового объекта GDI, поскольку, как было показано выше, функция GetStockObjectO всегда возвращает один и тот же результат. Вполне возможно, что она возвращает заранее созданный манипулятор, не создавая нового объекта, и содержимое таблицы при этом не изменяется. Если создание нового объекта приводит к модификации таблицы объектов, то для поиска таблицы можно сравнить содержимое памяти до и после создания нового объекта GDI. В соответствии с нашими предположениями, при сравнении можно ограничиться пользовательским адресным пространством, не беспокоясь об адресном пространстве режима ядра. Одна из изменившихся областей памяти должна находиться внутри таблицы объектов GDI. От общих идей переходим к построению алгоритма. В сущности, мы должны сохранить содержимое пользовательского адресного пространства до и после создания простого объекта GDI, а затем сравнить их байт за байтом; любая различающаяся ячейка памяти может принадлежать таблице объектов GDI. Впрочем, подобные простые идеи никогда не работают на практике. При чтении первого байта пользовательского адресного пространства, имеющего нулевое смещение, возникает ошибка защиты; это делается для того, чтобы перехватывать попытки разыменования (dereferencing) NULL-указателей. В 2-гигабайтном пользовательском пространстве существуют pi другие области, недоступные для чтения. Вдобавок запись, чтение и сравнение всех доступных для этого областей памяти потребует огромных расходов дискового пространства и будет происходить очень медленно. Чтобы сканирование пользовательского адресного пространства ограничивалось областями, доступными для чтения, мы воспользуемся функцией Win32 API Virtual Query, которая делит виртуальное адресное пространство на блоки с одинаковыми флагами защиты (например, доступ только для чтения, возможность записи и исполнения). Построение контрольных сумм для областей памяти, доступных для чтения, значительно уменьшает объем памяти, участвующей в сохранении и сравнении. Ниже приведен рабочий алгоритм с функцией, которая сохраняет содержимое блоков памяти и сравнивает их.
158 Глава 3. Внутренние структуры данных GDI/DirectDraw void shot(vector<CRegion> & Regions) { MEMORY_BASIC_INFORMATION info; for (LPBYTE start=NULL; Virtual Query(start. & info, sizeof(info)): ) { if (info.State — MEM_COMMITED) { CRegion * pRgn = Regions.Lookup(start. info.RegionSize); if (pRgn==NULL) pRgn = Regions.Add(start. info.RegionSize); pRgn->CRC[0] = pRgn->CRC[l]; pRgn->CRC[l] - GenerateCRC(start. info.RegionSize); pRgn->usage ++; if ( (pReg->usage >- 2) && (pReg->CRC[0]!=pReg->CRC[l]) ) printfC'Possible Table location Ш1х". start); } start += info.RegionSize: } } void SearchGDIObjectTable(void) { vector<CRegion> UserRAM; shot(UserRAM); CreateSolidBrush(RGB(Oxll. 0x22. 0x33)); shot(UserRAM); } В наши дни такой неудобный интерфейс недопустим, поэтому в окне программы GDIHandles создается новая страница Locate GDI Handle Table (Поиск таблицы манипуляторов GDI). На ней отображается табличный список, в котором для каждого блока выводится контрольная сумма, начальный адрес, размер, состояние, тип и даже имя модуля и сегмента (если их удается определить). Для таких модулей, как gdi32.dll, имя модуля определяется функцией GetModuleFileName. Для секций РЕ-модуля (например, для секции .text, обычно содержащей исполняемый код) программа определяет имя секции анализом внутренней структуры РЕ-файла. Кроме того, программа пытается идентифицировать блоки с кучами (heaps) процессов и стеками программных потоков. На странице имеется кнопка Query Virtual Memory, позволяющая в любой момент получить «снимок» виртуальной памяти. Запустите программу и щелкните на кнопке Query Virtual Memory; функция VirtualQuery делит 2-гигабайтное пространство виртуальных адресов на 100 с лишним блоков. Большинство блоков помечено флагами F (Free, свободная память) и R (Reserved, зарезервированная память). Для нас интерес представляют блоки с флагом С (Commited, актуализированная память).
Поиск таблицы объектов GDI 159 Большинство актуализированных блоков содержит сегменты ЕХЕ-файлов программ и системных DLL — таких, как kernel32.dll, gdi32.dll и даже msldle.dll (трудно сказать, почему msidle.dll отображается в это адресное пространство, но факт остается фактом). Несколько блоков содержат кучи; один блок содержит стек. Для каждого актуализированного блока слева выводится контрольная сумма. Перейдите на страницу Decode GDI Handle, создайте однородную кисть, вернитесь на страницу Locate GDI Handle Table и создайте второй снимок памяти. На этот раз почти для всех актуализированных блоков у нас имеются две контрольные суммы (до и после создания объекта). Некоторые блоки могут иметь только одну контрольную сумму, поскольку у них изменился начальный адрес или размер. На рис. 3.4 показано, как выглядит экран после создания второго снимка виртуальной памяти. ншжя^шнн^^^шнннш №Ь /'4 >'' *•/ •' А/ ', " &/"*4-ъ'.»>$* 4'%*- >"'"* W<*: JiSl *A^i..M.i~*MbA~.i.b~.***..L. J..Jj.J...1^Jfl[r^-^J..-..^.^..J...J...,.^...^.^.^..J.J..^..^^ ^—f.....J.J.J.^J.....JJ—..j.—^.^-or[trri. "4шт/\ЬШ М Ыт '<';ttA4iw<>Y'?'\ 'тюш,У'"<; I мыт*' <"\" 1 '-'<?Ж р£ ecOe af cl zz S9tZ %Z 39b8 ST 9Ь12 ££dd77 %Z d044 =S 9dla ?£ al6a & 7714 69f2 39b8 9Ы2 dd77 d044 9dla f49a 3132 :491b 491b ООЗЬОООО 003b2000 003b8000 00400000 00401000 0043b000 0043f000 00444000 0044S000 0044a000 004S0000 00493000 004a0000 00500000 007a0000 nm»i nnn 00002000 00006000 00048000 00001000 ОООЗаООО 00004000 00005000 00001000 00005000 00006000 00043000 OOOOdOOO 00060000 002a0000 00001000 nnnnfnnn С М er R И er F С I С I С I С I С I С I F С И го F С М er R M er С Р rw ewe ewe ewe ewe ewe ewe Handles.exe .text .rdata .data . rsrc T7 HIWfriyiftHII чНююЩт mim !/^';Ччл'и *<<::& ? * ,< »>*>/, ОС*" Cano$ Рис. 3.4. Поиск таблицы объектов GDI (отмечены изменившиеся блоки) Перед теми блоками, у которых контрольные суммы совпадают, появляется зеленый знак равенства, а перед блоками с разными контрольными суммами — предупреждающий красный знак. Блоки с одной контрольной суммой после двух снимков тоже считаются изменившимися.
160 Глава 3. Внутренние структуры данных GDI/DirectDraw ПРИМЕЧАНИЕ Каждый квалифицированный Windows-программист должен хорошо разбираться в работе механизма виртуальной памяти. Это поможет лучше понять, как устроен интерфейс Win32 API и как работает ваша программа. Например, виртуальная память начинается с 64-килобайтного свободного блока с нулевым адресом. Если вы когда-нибудь пытались разыменовать указатель, старшие 16 бит которого равны нулю, вы тем самым обращались к этой «запретной зоне». Поскольку данный блок виртуальной памяти объявлен свободным, при любых попытках чтения/записи возникают ошибки защиты. Каждый поток вашей программы создает отдельный стек, представленный в виртуальной памяти тремя блоками: большой зарезервированный блок для роста стека, одностра- ничный «сторожевой» блок для обнаружения роста стека и актуализированный блок для реально используемой части стека. Все DLIVEXE вашей программы могут создавать свои собственные кучи, если они не используют DLL-версию runtime-библиотеки C/C++ (вот почему в виртуальной памяти так часто встречаются кучи). Пользовательские модули обычно загружаются в нижнюю часть виртуальной памяти, а системные DLL — в верхнюю часть. Наибольший свободный блок между ними определяет максимальный объем данных, которые могут одновременно обрабатываться программой Win32. Обычно объем этого свободного блока виртуальной памяти составляет около 1,5 гигабайта. В нашем тесте между двумя «снимками» памяти примерно у десяти блоков изменились контрольные суммы или поменялся начальный адрес/размер. При этом произошло несколько событий — вывод результата первого «снимка», переключение на другую страницу, создание однородной кисти и возвращение к предыдущей странице. Поскольку при этом был создан по крайней мере один новый объект GDI, таблица объектов GDI должна находиться в одном из этих блоков. Впрочем, десять блоков — все еще слишком много, чтобы просматривать их один за другим. Однако большинство кандидатов удается сразу отвергнуть, поскольку размер блока должен быть больше некоторого порогового значения. Из предыдущего раздела мы знаем, что максимальное количество манипуляторов объектов GDI равно 12 000 для одного процесса или 16 000 для всей системы. Если предположить, что каждый элемент таблицы объектов GDI кодируется минимум четырьмя байтами, размер таблицы должен превышать 64 Кбайт (в шест- надцатеричной записи — 0x10000). Четыре байта составляют минимальный объем памяти для хранения указателя на более сложную структуру данных. С учетом ограничений на размер остается всего два блока (оба видны на рис. 3.4). Оба блока актуализированы, защищены от записи и не имеют осмысленных имен. Оба имеют довольно крупный размер, 268 Кбайт (0x43000) и 384 Кбайт (0x60000). Один блок имеет атрибут PAGE_READ0NLY, а другой - PAGE_ EXECUTE_READ. Чтобы понять, в каком блоке может находиться искомая таблица, проще всего просмотреть их содержимое. При двойном щелчке на первом столбце таблицы на экране появляется диалоговое окно, в котором отображается ше- стнадцатеричный дамп выбранного блока. Теперь дважды щелкните на первом столбце блока, начинающегося с адреса 0x0045000. Преобразуйте дамп к формату двойных слов (для этого устанавливается переключатель Dword). При просмотре содержимого блока вскоре становится ясно, что перед вами таблица с элементами размером по 16 байт. Чтобы убедиться в том, что таблица по адресу 0x00450000 действительно является искомой таблицей объектов GDI, сохраните содержимое блока в текстовом файле (кнопка Dump), создайте несколько объектов GDI, запомните их манипуляторы, со-
Поиск таблицы объектов GDI 161 храните новый дамп того же блока и сравните два файла при помощи какой- нибудь утилиты (например, WinDiff). Допустим, вы создали 256 однородных кистей и получили манипуляторы со значениями от 0x01300440 до 0х0130052Ь; индексы этих манипуляторов лежат в интервале от 0x440 до 0x52b. Просмотрите дамп по адресам от 0x00454400 до 0х004552Ь0; вы увидите, что после создания объектов содержимое этих адресов изменилось. На рис. 3.5 показан дамп блока памяти, начинающегося с адреса 0x45000. ?ffi%ffi$±\&>£- п>. Г Word & 0G45G1GQ: QCWSOUQ? 00450*20; 0D45O1308 QU45Di40i 00450150s OQ450WO? OD450170\ e13с£3вв e!3837G8 000GGGGQ OQGOQQQB йййййййй 00OOOOO0 QOOOOO0O 01100190 01103*90 01100190 01100*90 01100190 01100190 оиосшк* 0000GGGG dqqockkki 00000800 00000000 00000000 00000000 00000000 00000000 * * t * Л8* .78. Ц. % Ч Ч Ч % л «• # * * 4 * * * * I ■ * * % i ► » » 4» J I- * * * * 4 K< \\ШЛ Dump 1 Search jc I Рис. З.5. Дамп памяти возможной таблицы объектов GDI В этой программе таблица объектов GDI нашлась по адресу 0x450000, но нет никаких оснований полагать, что этот адрес является фиксированным. Если внимательно присмотреться к структуре виртуальной памяти, вы увидите, что блок 0x450000 расположен в памяти после главной программы Handles.exe. Следовательно, для программы меньшего размера таблица объектов могла бы начинаться с адреса 0x420000, а для большой программы — с адреса 0x630000. Нам нужен более простой и надежный способ поиска таблицы в памяти. Поскольку адрес таблицы в памяти не фиксируется, a GDI часто приходится обращаться к ней, можно сделать вывод — ссылка на таблицу должна присутствовать в сегменте данных GDI. Откройте диалоговое окно Memory Dump для секции данных GDI32 (.data), перейдите в режим двойных слов (переключатель Dword), введите адрес 450000 и щелкните на кнопке Search. На экране появляется следующий отчет: Search for 0x00450000 in region start at 77f78000. size 1000 bytes 77f78008 77f780bc Две найденные ссылки означают, что в gdi32.dll хранятся две внутренние переменные для обращения к таблице объектов GDI. Продолжим поиск в секции кода GDI (.text) с адресами этих двух переменных, 0x77f78008 и 0x77f780bc. На вторую переменную находятся четыре ссылки, а на первую — несколько сотен. Сравнение адресов с выходными данными Quick-
162 Глава 3. Внутренние структуры данных GDI/DirectDraw View или Dumpbin для gdi32.dll наглядно показывает, что ссылки встречаются во множестве функций, в том числе в SelectObject и GetObjectType. Однако среди функций, использующих указатели на таблицу объектов GDI, особый интерес вызывает одна недокументированная функция — GdiQueryTable. В высшей степени любопытное имя... Оно подсказывает, что где-то существует какая-то таблица, и при помощи этой функции можно получить информацию о ней. Давайте посмотрим, что же делает эта загадочная функция. // querytab.cpp #define STRICT #iinclude <windows.h> typedef unsigned (CALLBACK * ProcO) (void); void TestGdiQueryTable(void) { ProcO p = (ProcO) GetProcAddress(GetModuleHandle("GDI32.DLL"). "GdiQueryTable"); if (p) { TCHAR temp[32]; wsprintf(temp. "Я81Х". p()); MyMessageBox(NULL. temp. "GdiQueryTableO returns". MB_0K); } return 0; } Функция GdiQueryTable возвращает тот же адрес 0x45000, который был получен экспериментальным путем. После долгих хлопот с поисками в виртуальной памяти мы достигли своей цели — действительно, в Windows NT/2000 существует общесистемная таблица объектов GDI и даже имеется недокументированная функция GdiQueryTable, которая возвращает указатель на эту таблицу. В программах пользовательского режима эта таблица доступна только для чтения. Если на вашем компьютере установлены символические файлы для gdi32.dll, запустите программу Handles.exe в отладочном режиме, переключитесь в режим ассемблерного кода и выберите команду Edit ► Go To — на экране появляется диалоговое окно. Введите в нем адрес 0x77f78008 или 0x77f780bc. Отладчик Visual C++ показывает для первого адреса имя _pGdiSharedHandleTable, а для второго — _pGdiSharedMemory. Итак, первый адрес соответствует указателю на общую таблицу объектов GDI, а второй — указателю на общую память GDI, причем оба блока памяти начинаются с одного и того же адреса. Если вместо адреса ввести имя _GdiQueryTable@0 (суффикс означает, что функция вызывается без параметров), отладчик покажет ассемблерный код недокументированной функции GdiQueryTable. Функция устроена элементарно — она просто возвращает содержимое указателя _pGdiSharedHandleTable. Расшифровка таблицы объектов GDI В разделе «Расшифровка манипуляторов объектов GDI» говорилось, что максимальное количество манипуляторов в таблице равно 16 384. В разделе «Поиск таблицы объектов GDI» мы убедились в том, что таблица объектов GDI сущест-
Расшифровка таблицы объектов GDI 163 вует и что она доступна из адресного пространства пользовательского режима. На рис. 3.5 приведено начальное содержимое таблицы объектов GDI. При внимательном изучении дампа на рис. 3.5 вырисовывается четкая закономерность циклов, повторяющихся через каждые 16 байт: сначала следует большое 32-разрядное значение, затем нулевая 32-разрядная величина, еще одно ненулевое 32-разрядное значение и еще 32 нулевых бита. Размер предполагаемой таблицы объектов GDI равен 268 Кбайт, что при делении на 16 384 дает 16,75. Итак, можно с уверенностью сказать, что размер элемента таблицы объектов GDI равен 16 байтам. Главной задачей этого раздела станет расшифровка структуры этой 16-байтовой записи. Если воспользоваться экспериментальными методами, описанными в двух предыдущих разделах, можно прийти к следующей структуре: typedef struct { void * pKernel; unsigned short nProcess; unsigned short nCount; unsigned short nUpper: unsigned short nType; void * pUser; } GdiTableCell: В первых 4 байтах элемента таблицы GDI содержится указатель, значение которого обычно превышает ОхЕ 1000000. Следовательно, он относится к верхним 2 гигабайтам адресного пространства Windows NT/2000, доступным только для кода режима ядра. Речь идет о том, что для каждого объекта GDI в адресном пространстве режима ядра существует структура данных, на которую ссылается таблица объектов GDI. ПРИМЕЧАНИЕ В Windows NT/2000 область памяти от ОхЕЮООООО до OxECFFFFFF (192 Мбайт) представляет собой выгружаемый (paged) пул ядра, в котором хранятся динамически выделяемые структуры данных компонентов ядра. Его отличие от невыгружаемого пула заключается в том, что первый при нехватке системной памяти может выгружаться на диск, тогда как последний заведомо всегда остается в физической памяти. Как будет показано ниже, структуры данных GDI, относящиеся к режиму ядра (включая аппаратно-зависимые растры, DDB), обычно хранятся в выгружаемом пуле. Следующие два байта (поле nProcess) содержат идентификатор процесса, создавшего объект. Идентификатор текущего процесса возвращается функцией GetCurrentProcessId. Для некоторых объектов (например, стандартных объектов GDI) это поле может быть равно 0. Два байта, следующих за nProcess, обычно равны нулю. Впрочем, при некоторых условиях значение может быть и ненулевым. Похоже, в них хранится счетчик применений манипулятора объекта; по этой причине в определении структуры этому полю присвоено имя nCount. За nCount следует поле nUpper — точная копия верхних двух байтов манипулятора объекта GDI. Из предыдущих разделов мы знаем, что nUpper состоит из неизвестного старшего байта и младшего байта с информацией о типе объекта.
164 Глава 3. Внутренние структуры данных GDI/DirectDraw За полем nUpper следует 2-байтовое поле пТуре, содержащее внутреннюю информацию о типе объекта. Последние 4 байта GdiTableCell (поле pUser) содержат еще один указатель. Как правило, значение pUser равно NULL. Если это поле отлично от NULL, в нем хранится указатель на нижние 2 гигабайта адресного пространства, доступных для программного кода пользовательского режима. Для некоторых типов объектов GDI создает структуру данных, локальную по отношению к текущему процессу. Указатели пользовательского режима доступны из адресного пространства режима ядра, но лишь в том случае, если они относятся к текущему процессу. Итак, мы знаем, как получить адрес таблицы объектов GDI и какую структуру имеет каждый элемент таблицы. Все эти сведения будут объединены в класс C++, упрощающий работу с таблицей объектов GDI в Windows-программах. Класс KGDITable приведен в листинге 3.2. Листинг 3.2. Класс KGDITable для работы с таблицей объектов GDI // GDITable.h #pragma once class KGDITable { GDITableCell * pGDITable; public: KGDITableO; GDITableCell operator[](HGDIOBJ hHandle) const { return pGDITableC (unsigned) hHandle & OxFFFF ]; } GDITableCell operator[](unsigned nlndex) const { return pGDITableC nlndex & OxFFFF ]; } }: // GDITable.cpp #define STRICT #include <windows.h> #include <assert.h> #include "Gditable.h" KGDITable::KGDITable() { typedef unsigned (CALLBACK * ProcO) (void); ProcO pGdiQueryTable = (ProcO) GetProcAddress( GetModuleHandle("GDI32.dll". "GdiQueryTable"); assert(pGdiQueryTable): if ( pGdiQueryTable ) pGDITable = (GDITableCell *) pGdiQueryTableO: else
Расшифровка таблицы объектов GDI 165 pGDITable = NULL; } Работать с классом KGDITable очень просто. Ниже показано, как получить адрес структуры данных режима ядра для стандартного объекта черного пера. const void * BlackPenpKernel(void) { KGDITable gditable; return gditable[GetStockObject(BLACK_PEN)].pKernel; } На рис. 3.6 изображена новая страница свойств, Decode GDI Object Table (Расшифровка таблицы объектов GDI) нашей программы GDIHandles. На этой странице содержимое таблицы объектов GDI выводится в структурированном виде. Decode SOI Heftdte \ Uoate GDI Handle Table Qeceds SW ■W £*»се*Я ОзлХу fie | jQuery GDI Table i£xi 1 Xn&gx 11шшш*&?388к 57 4a9 4d4 4d3 1 4e8 I 4f2 4f4 537 S3b SaS 5a7 N Index: 1 |sK«!ira«l e271ale8 elec5008 elec44c8 elec29e8 e2307328 e26012c8 e272e008 e2789388 e2713008 e2S89008 e27164c8 e21a4aa8 55, Handle: r — } nCmmfc 0 0 0 0 0 0 0 0 0 0 0 0 740S00SS | «tP.5tO« Sc8 Sc8 Sc8 Sc8 5c8 Sc8 Sc8 Sc8 Sc8 Sc8 Sc8 Sc8 , Type: OB ntTp^fftr j 740S 0101 eeOa SeOl 6504 8el0 9101 760a 4605 3f0a leOa 3310 JJBITMAP ttfVpe 0005 0401 000a 0001 0004 0010 0401 000a 0005 000a 000a 0010 j |*TJs«r 0 7aOS70 135e68 7a01d0 7b0018 0 7a03a0 13Se78 0 135e80 13Se88 7b0000 *i ? *-J A l*>''i *' ж Рис. 3.6. Содержимое таблицы объектов GDI При помощи флажка, находящегося в левом верхнем углу страницы, пользователь выбирает между выводом всех объектов таблицы или только тех объектов, которые были созданы текущим процессом. Попробуйте выделить любой
166 Глава 3. Внутренние структуры данных GDI/DirectDraw объект GDI в списке; в нижней части страницы появится дополнительная информация о его индексе, значении HGI0BJ и типе объекта. Располагая таким замечательным инструментом для вывода содержимого таблицы объектов GDI, мы можем провести дополнительные эксперименты с объектами GDI и глубже исследовать принципы управления этими объектами. Указатель pKernel ссылается на выгружаемый пул Для любого действительного объекта GDI указатель pKernel всегда отличен от NULL и имеет уникальное значение. Похоже, для каждого объекта GDI существует некая структура данных, обращения к которой производятся только из кода режима ядра (и даже не из gdi32.dll!). Как видно из значений pKernel, объекты разных процессов не имеют четкого деления на разные области памяти. Адреса объектов, на которые указывает pKernel, всегда начинаются с ОхЕЮООООО. Как сообщается в книге «Inside Windows NT», область памяти, начинающаяся с ОхЕЮООООО, представляет собой выгружаемую системную кучу, которая обычно называется «выгружаемым пулом» (paged pool). Visual C++ не разыменовывает эти указатели, поэтому мы пока не сможем узнать, что за ними скрывается. В сущности, Visual Studio — обычная программа пользовательского режима, не поддерживаемая специальными драйверами ядра. Мы вернемся к указателю pKernel в разделе «WinDbg и расширение отладчика GDI» и исследуем его при помощи драйвера режима ядра, который мы создадим в разделе «Обращение к адресному пространству режима ядра». Поле nCount иногда используется как счетчик выбора объектов В Windows 2000 поле nCount всегда равно нулю, то есть оно не используется. Однако в Windows NT 4.0 это поле требуется для некоторых объектов GDI. Чтобы лучше понять смысл nCount, поэкспериментируйте с выбором и восстановлением объектов в одном или нескольких контекстах устройств и проследите за изменениями nCount. В сущности, вы должны создать объект, выбрать его в двух контекстах устройств, потом восстановить старые объекты и, наконец, удалить созданный объект. Как выясняется из этого маленького эксперимента, при создании объекта его поле nCount равно нулю, и для многих типов объектов это значение остается неизменным. Для аппаратно-зависимых растров (DDB) поле nCount при выборе объекта в DC изменяет значение с 0 на 1. Если попробовать заново выбрать растр в другом DC, попытка завершится неудачей. При исключении растра из первого DC поле nCount возвращается к нулевому состоянию. Несомненно, применительно к DDB поле nCount обеспечивает выполнение требования о том, что растр не может выбираться в нескольких контекстах одновременно. Для шрифтов — другого типа объектов GDI, использующего поле nCount, — в этом поле хранится простой счетчик выбора, не накладывающий никаких ог-
Расшифровка таблицы объектов GDI 167 раничений. Выбор логического шрифта во втором контексте устройства проходит успешно, а значение поля nCount при этом увеличивается. Многие программисты задают один очевидный вопрос — существует ли в GDI какой-то механизм защиты от удаления объектов, выбранных в контексте устройства? Ответ — да, существует... по крайней мере, для палитр. Как видно из табл. 3.1, первый вызов DeleteObject после выбора палитры в двух DC завершается неудачей, но второй вызов DeleteObject после исключения палитры из обоих DC работает нормально. Впрочем, поле nCount в этой защите не используется. Другие объекты GDI (например, шрифты, растры, кисти и перья) могут быть удалены программистом в любой момент времени, при этом манипулятор выбранного объекта становится недействительным. Трудно сказать, почему Windows не поддерживает единые правила использования nCount, которые бы предотвращали удаление всех выбранных объектов. Таблица 3.1. Использование поля nCount Функция API Растр (DDB) Шрифт Палитра Create...() SelectObject(hDCl) Select0bject(hDC2) DeleteObject() (De)Select0bject(hDC2) (De)SelectObject(hDCl) DeleteObjectO Успех, nCount^O Успех, nCount=l Неудача, nCountsl Неудача, nCount^l Успех, nCount=0 Успех Успех, nCount=0 Успех, nCount^l Успех, nCount=2 Успех, nCount^l Успех, nCount=0 Успех Успех, nCount^O Успех, nCounte0 Успех, nCount«0 Неудача Успех, nCount^O Успех, nCount-0 Успех Поле nProcess связывает манипулятор GDI с конкретным процессом Если программа пытается воспользоваться манипулятором объекта GDI, относящегося к другому процессу, вызов функции Win32 API обычно завершается неудачей. За этим «волшебством» стоит поле nProcess структуры GdiTableCell. Для стандартных объектов (например, GetStockObject(BLACK_PEN)) поле nProcess равно нулю. Для других объектов GDI, созданных пользовательскими процессами, поле nProcess содержит идентификатор процесса, создавшего объект. Чтобы получить идентификатор текущего процесса, вызовите функцию GetCurrent- ProcessIdO. GDI проверяет, совпадает ли идентификатор текущего процесса с содержимым поля nProcess объекта GDI; тем самым обеспечивается выполнение требования о том, чтобы манипуляторы объектов не использовались другими процессами. Страница Decode GDI Object Table позволяет выбрать между отображением всех объектов GDI и только тех объектов, которые были созданы текущим процессом. Если щелкнуть в строке таблицы, в нижней части страницы выводится
168 Глава 3. Внутренние структуры данных GDI/DirectDraw подробная информация о выбранном объекте — в том числе и информация, возвращаемая при вызове GetObject. Но если переключиться в режим вывода всех объектов GDI и щелкнуть на объекте, созданным другим процессом, вызов GetObject завершается неудачей, а программа выводит ошибку «Invalid Object». Согласно документации Microsoft, при завершении процесса освобождаются все созданные им объекты GDI. Вас когда-нибудь интересовало, как это делается? GDI просто перебирает все записи в таблице объектов GDI и удаляет все объекты с идентификатором текущего процесса. nUpper: дополнительная проверка Поле nUpper в таблице объектов GDI содержит точную копию двух старших байтов 4-байтового манипулятора — эта относительно малая избыточность обеспечивает дополнительную проверку манипуляторов объектов GDI. Предположим, вы создали шрифт; функция CreateFont возвращает 0x9d0a047f. Новый объект соответствует элементу таблицы с индексом 0x047f, у которого поле nUpper равно 0x9d0a. Теперь какая-нибудь другая часть программы удаляет шрифт, не зная, что он используется, в результате запись 0x047f освобождается; затем программа создает другой шрифт. Допустим, GDI почему-либо решает задействовать для нового объекта GDI элемент с индексом 0x047f и назначает ему манипулятор 0x9e0a047f. Если первая часть программы попытается воспользоваться манипулятором 0x9d0a047f, вызовы функций Win32 GDI завершатся неудачей — GDI обнаруживает, что 0x9d0a не совпадает с новым значением nUpper элемента 0x047f, которое теперь равно ОхЗреОа. Попробуйте изменить старший байт манипулятора GDI, сохранив три остальных байта, в которых хранится информация о типе объекта; вы увидите, что вызовы GetObject и GetObjectType завершаются неудачей. Хранение старшего слова манипулятора в таблице находит и другие применения. Если вам известен только индекс манипулятора в таблице GDI, вы сможете восстановить весь манипулятор, прочитав nUpper из таблицы и объединив эти два значения. Например, эта возможность используется при реализации 16- разрядной поддержки GDI в Windows NT. Вспомните: в 16-разрядном интерфейсе GDI используется 16-разрядный манипулятор HGDI0BJ, фактически являющийся индексом. Чтобы 16-разрядная поддержка GDI работала в Windows NT, вызов необходимо переадресовать 32-разрядному интерфейсу GDI, работающему с полноценными 32-разрядными манипуляторами. При анализе структуры манипуляторов GDI в разделе «Поиск таблицы объектов GDI» нерасшифрованными остались лишь старшие 8 бит. Дополнительные эксперименты показывают, что в них хранится счетчик повторного использования — еще одно простое средство проверки манипуляторов. У каждого элемента таблицы объектов GDI первоначальное значение счетчика равно 0. Когда в элемент таблицы заносится информация о новом объекте GDI, его счетчик повторного использования увеличивается (когда значение достигает 255, счетчик снова сбрасывается в 0). Таким образом, когда элемент задействуется впервые, его счетчик повторного использования равен 0x01; это относится ко всем стандартным объектам GDI, которые создаются один раз и никогда не удаляются. Если
Расшифровка таблицы объектов GDI 169 вы удаляете объект GDI и создаете новый объект в том же элементе таблицы, даже при совпадении типов объектов манипуляторы будут отличаться, поскольку значение счетчика повторного использования увеличилось. Все вызовы функций, в которых присутствует исходный манипулятор, завершатся неудачей. Применение счетчика продемонстрировано в разделе «Структуры данных пользовательского режима» (см. ниже). пТуре: внутренний тип объекта В процессе анализа структуры манипуляторов GDI (см. раздел «Расшифровка манипуляторов объектов GDI») мы выяснили, что в каждом манипуляторе присутствует 7-разрядная информация о типе объекта. Эта информация, расширенная до двух байт, имеется и в таблице объектов GDI. Младший байт пТуре обычно содержит те же 7 бит типа, что и HGDI0BJ, а старший байт обычно равен нулю. В поле пТуре манипулятор расширенного метафайла интерпретируется как манипулятор контекста устройства, а манипулятор расширенного пера — как манипулятор кисти. Для некоторых объектов старший байт пТуре определяет подтип объекта — скажем, подтип «совместимый контекст» (memory context) для типа «контекст устройства». Вот что мы знаем об этом слове внутреннего типа объекта: typedef enum gdi_i nt_objtypew_dc gdi_i nt_objtypew_memdc gdi_int__objtypew_region gdi_int_objtypew_bitmap gdi_int_objtypew_palette gdi_i nt_objtypew_font gdi_i nt_objtypew_brush gdi_int_objtypew_enhmetafi1e gdi_int_objtypew_pen gdi_i nt_objtypew_extpen = 0x0001, = 0x0401. = 0x0004, « 0x0004. = 0x0008. = 0x000a. = 0x0010. = 0x0001. - 0x0030. = 0x0010. // He все совмеси // Как для DC // Как для кисти pUser: указатель на структуру данных пользовательского режима Вероятно, вы обратили внимание на симметричное расположение полей в структуре GdiTableCell: она начинается с указателя, затем следуют четыре 16-разрядных слова, а затем следует другой указатель pUser. Обычно указатель pUser равен NULL — исключение составляют некоторые типы объектов GDI. Если указатель отличен от NULL, он принимает такие значения, как 0х001420с8 или 0x790320. Как нетрудно убедиться, эти значения соответствуют действительным адресами блоков памяти, доступным для чтения и записи. Структуры данных объектов GDI более подробно рассматриваются в следующем разделе.
170 Глава 3. Внутренние структуры данных GDI/DirectDraw Структуры данных пользовательского режима Как было показано в предыдущем разделе, каждому объекту GDI соответствует элемент глобальной таблицы объектов GDI, в котором хранится указатель с именем pUser. Для большинства объектов GDI указатель pUser равен NULL (то есть не используется). Тем не менее для объектов кистей, регионов, шрифтов и контекстов устройств поля pUser в таблице объектов GDI ссылаются на довольно интересные структуры данных в адресном пространстве пользовательского режима. Этой теме и посвящен данный раздел. Структура данных пользовательского режима для кистей: оптимизация создания однородных кистей Для однородных кистей указатель pUser ссылается на блок из 24 байт, в котором первые 12 байт содержат копию структуры L0GBRUSH. Если кисть является однородной, она обладает лишь одним атрибутом — цветом. Для остальных типов кистей pUser содержит NULL. typedef struct { LOGBRUSH logbrush; DWORD dwUnused[3]; } User_Data_SolidBrush; Если вам непонятно, почему в реализации GDI однородные кисти занимают особое место, попробуем поставить вопрос иначе — чем однородные кисти отличаются от остальных кистей? Прежде всего тем, что эти объекты GDI живут недолго и используются в больших количествах. При создании градиентных заливок, теней или эффектов освещения сотни и тысячи однородных кистей создаются, разок-другой используются при выводе фрагмента изображения, а затем немедленно удаляются. Поскольку однородные кисти требуются в больших количествах, приложение не может хранить их до следующего раза; в противном случае вы рискуете превысить максимальный размер таблицы объектов GDI. Таким образом, большинство однородных кистей уничтожается сразу же после использования и создается заново в случае необходимости. Сохраняя копию структуры LOGBRUSH в пользовательском режиме, GDI оптимизирует стандартную последовательность действий «создание — использование — удаление» для большого количества кистей. При удалении первой однородной кисти GDI не производит фактического уничтожения создания структуры данных, а сохраняет ее на будущее. Когда программе потребуется новая однородная кисть, GDI берет готовую кисть и изменяет ее цвет; это позволяет обойтись без обращения к режиму ядра для выделения блока памяти и заполнения его данными новой кисти. Чтобы разобраться в происходящем, проведем несложный эксперимент. Попробуйте в цикле создать, проанализировать и уничтожить восемь однородных кистей. Как видно из табл. 3.2, GDI сохраняет в таблице GDI несколько одно-
Структуры данных пользовательского режима 171 родных кистей для дальнейшего использования. Обратите внимание: кисти 1, 3 и 6 имеют одинаковый индекс ОхЗеН. Их поля pKernel и pUser совпадают, но поля lbColor в структуре L0GBRUSH, на которую ссылается pUser, различаются. Таблица 3.2. Повторное использование манипуляторов однородных кистей Манипулятор ОхабЮЗеП ОхЗсЮЗШ 0ха7103е11 0x941031be 0x3dl031f5 0xa8103ell 0x5fl03f49 0x951031be lbColor 0x000000 0x202020 0x404040 0x606060 0x808080 OxaOaOaO OxcOcOcO OxeOeOeO pKernel 0xel25d710 0xel25d878 0xel25d710 0xel25da70 0xel25d878 0xel25d710 0xel25d908 0xel25da70 pUser 0x870048 0x870060 0x870048 0x870078 0x870060 0x870048 0x870090 0x870078 Таблица 3.2 также иллюстрирует то, что говорилось выше о счетчике повторного использования (старшие 8 бит манипулятора GDI). Манипуляторы 1, 3 и 6 в табл. 3.2 создаются в одном и том же элементе таблицы GDI ОхЗеН; все они соответствуют объекту кисти (0x10), однако их счетчики повторного использования отличаются на 1. Структура данных пользовательского режима для регионов: оптимизация прямоугольных регионов Объекты регионов создаются такими функциями, как CreateRectRgn и ExtCreateRgn. По аналогии с кистями, поле pUser используется для простейшего случая — прямоугольных регионов. Размер блока данных прямоугольного региона, адресуемого указателем pUser, равен 24 байтам. Смысл первых двух двойных слов в этом блоке неизвестен, а остальные 16 байт образуют структуру RECT: typedef struct { DWORD dwUnknownl: // - 17 DWORD dwUnknown2: //-1,2 RECT rcBound: } UserData_RectRgn; Как и следовало предположить, манипуляторы прямоугольных регионов, как и манипуляторы кистей, многократно используются GDI. Попробуйте провести простой эксперимент — создайте прямоугольный регион, сохраните значения указателей pKernel и pUser и затем удалите регион. Повторите 8 раз. Вы увидите, что GDI три раза использует старый индекс без изменения указателей pKernel и pUser, хотя координаты прямоугольника при этом изменяются.
172 Глава 3. Внутренние структуры данных GDI/DirectDraw Как правило, создание и последующее использование объектов GDI осуществляется только средствами GDI. Состояние созданного объекта GDI жестко фиксируется. В объектно-ориентированном программировании подобные объекты называются неизменяемыми (immutable). Например, после создания кисти вы уже не сможете напрямую изменить ее цвет. Объекты регионов являются исключением из этого правила — функция SetRectRgn преобразует существующий регион в прямоугольный регион с заданными координатами. Зная определение структуры данных, указатель на которую хранится в поле pUser, вы легко поймете, как реализуется эта функция — GDI просто убеждается в том, что поле pUser не пусто (то есть в памяти была создана структура UserDataRectRgn), и присваивает координатам заданные значения. Таким образом, регионы как объекты GDI являются изменяемыми (mutable). Структура данных пользовательского режима для шрифтов: таблица значений ширины Для шрифтов в Windows GDI определяется больше структур данных, чем для любого другого объекта: LOGFONT, TEXTMETRIC, PANOSE, ABC, GLYPHSET и т. д. Однако в таблице объектов GDI не обнаруживается ни малейшего следа этих структур. Структура данных пользовательского режима для манипулятора шрифта устроена очень просто: typedef struct { DWORD dwUnknown; // = О void *pCharWidthData: // = 1. 2 } UserData_Font; Первое поле UserDataFont всегда равно нулю. Второе поле обычно равно нулю и изменяется только после вызова таких функций, как GetCharWidth. Функция GetCharWidth заполняет целочисленный массив сведениями о ширине символов, принадлежащих заданному интервалу. После вызова GetCharWidth указатель pChar- WidthData указывает на структуру данных, выделенную из системной кучи, которая в основном содержит кэшируемую таблицу значений ширины. Перед нами еще один пример того, как GDI прикладывает дополнительные усилия для оптимизации быстродействия. Получив значение pCharWidthData (например, 0х1456Ь0), вы можете без особого труда вычислить, где находится этот адрес. На странице Locate GDI Object Table программы GDIHandles отображается список всех блоков памяти в пользовательском адресном пространстве. Из этого списка видно, что адрес 0х1456Ь0 принадлежит первой куче, то есть куче процесса по умолчанию. Если дважды щелкнуть на строке первой кучи, на экране появляется окно дампа памяти (см. рис. 3.5). Щелкните на кнопке Dump — содержимое блока сохраняется в текстовом файле вместе со списком всех блоков, выделенных из кучи. Структура данных пользовательского режима для контекста устройства: атрибуты Перед выполнением любых операций вывода в Windows GDI необходимо получить манипулятор контекста устройства. Вы можете создать собственный мани-
Структуры данных пользовательского режима 173 пулятор или получить его от операционной системы. Контекст устройства обладает двумя десятками атрибутов, значения которых могут читаться и задаваться в программах. Например, к числу распространенных атрибутов контекстов устройства относятся режим отображения, цвет текста, цвет фона, а также выбранные объекты кисти, пера и шрифта. Естественно, GDI хранит информацию об атрибутах контекста устройства в структуре данных. В Windows NT/2000 указатель на эту структуру хранится в поле pUser таблицы объектов GDI для манипулятора контекста устройства. После утомительного процесса изменения атрибутов контекста и наблюдения за модификациями двоичных данных можно получить примерное представление о структуре, на которую ссылается указатель pUser для контекста устройства. Впрочем, полученная информация будет неполной и недостоверной. При использовании расширения отладчика GDI уровня ядра, предоставляемого Microsoft, в сочетании с утилитой WinDbg (отладчик исходных текстов системного уровня от Microsoft) вырисовывается значительно более полная и завершенная картина. Использование расширения отладчика GDI подробно описано в разделе «WinDbg и расширение отладчика GDI». Ниже приведена та информация, которую нам удалось получить об этой структуре данных, занимающей 456 байт в Windows 2000 (400 байт в Windows NT 4.0). // dcattr.h typedef struct { UL0NG ull; UL0NG ul2; } FL0AT0BJ; typedef struct { FL0AT0BJ efMll; FL0AT0BJ efM12; FL0AT0BJ efM21: FL0AT0BJ efM22; FL0AT0BJ efDx; FL0AT0BJ efDy; int fxDx; i nt f xDy; long flAccel; } MATRIX; // Windows NT 4.0: 0x190 байт // Windows 2000 : 0xlC8 байт typedef struct { void * pvLDC; // 000 UL0NG ulDirty; HBRUSH hbrush; HPEN hpen; C0L0RREF crBackgroundClr; // 010 UL0NG ulBackgroundClr;
174 Глава 3. Внутренние структуры данных GDI/DirectDraw COLORREF ULONG crForegroundClr; ulForegroundClr; #if (_WIN32_WINNT >- 0x0500) unsigned #endif int int BYTE BYTE BYTE BYTE POINT POINTFX long long long f20[4]; iCS_CP; iGraphicsMode; JR0P2; jBkMode; jFillMode; jStretchBltMode; ptlCurrent; ptfxCurrent; IBkMode; IFillMode; IStretchBltMode: #1f (_WIN32__WINNT >- 0x0500) long long unsigned flFontMapper; HcmMode; hcmXform; HCOLORSPACE hColorSpace; unsigned unsigned unsigned unsigned #endif long long long long long long HFONT MATRIX MATRIX MATRIX f68; IcmBrushColor; IcmPenColor; f74; flTextAlign; ITextAlign; ITextExtra: IRelAbs; IBreakExtra; cBreak; hlfntNew; mxWorldToDevice; mxDeviceToWorld: mxWorldToPage; // 020 // 030 // 038 // 03C // 044 // 04C // 050 // 058 // 060 // 070 // 078 // 080 // 090 // 094 // 0D0 // 10C unsigned fl48[8]: int iMapMode; #if (_WIN32_WINNT >= 0x0500) DWORD dwLayout; long lWindowOrgx; #endif // 148 // 168 // 16c // 170 POINT ptlWindowOrg; SIZE szlWindowExt; // 174 // 17c
Структуры данных пользовательского режима 175 POINT SIZE long SIZE SIZE POINT unsigned RECT ptlViewportOrg: szlViewportExt; flXform: szlVirtualDevicePixel: szlVirtual DeviceMm; ptlBrushOrigin; flb0[2]: VisRectRegion; // 184 // 18c // 194 // 198 // laO // la8 // IbO // lb8 } DCAttr; Смысл большей части полей структуры DC_ATTR понятен без объяснений. При выборе в контексте устройства объектов GDI (таких, как кисти, перья и шрифты) их манипуляторы сохраняются в соответствующих атрибутах. В структуре не видно и следа присутствия аппаратно-зависимых растров, палитр и регионов. Скалярные атрибуты (цвет текста, цвет фона, графический режим, бинарная растровая операция, режим блиттинга с растяжением, тип выравнивания текста и режим отображения) также хранятся в этой структуре. Некоторые атрибуты (цвет и выравнивание текста) по каким-то неизвестным причинам хранятся в двух экземплярах. В Windows NT/2000 GDI поддерживаются мировые преобразования между логической и физической системами координат. Путем мировых преобразований выполняются трансформации переноса, масштабирования, поворота и сдвига. Мировое преобразование описывается вещественной матрицей XF0RM 2x3, передаваемой при вызове функции SetWorldTransform. Матрица XF0RM не сохраняется в структуре данных DC_ATTR непосредственно в вещественном формате. XF0RM состоит из шести вещественных чисел с одинарной точностью, описывающих линейное преобразование на плоскости. Известно, что стандартное представление вещественных чисел с одинарной точностью в формате IEEE занимает 4 байта, тогда как представление числа с двойной точностью содержит 8 байт. Однако в представлении XF0RM в DC_ATTR не используется ни один из этих двух форматов. XF0RM представляется структурой MATRIX, состоящей из шести пар DWORD и трех 32-разрядных чисел. Ближайшим аналогом этих пар DWORD является структура FL0AT0BJ, определяемая в WinNT DDK. Вещественное число с одинарной точностью в формате IEEE состоит из 32 бит. Оно содержит один знаковый бит, 8-разрядную экспоненту со смещением 127 и 23-разрядную мантиссу с одним скрытым битом, который всегда равен 1. Вещественное число вычисляется по формуле знак * 2А(экспонента-127) * (1«24 + мантисса)2*24. Например, число 1.0 хранится в виде 0x3F800000. Знаковый бит соответствует положительному числу, экспонента равна 127, а все биты мантиссы равны нулю. В соответствии с приведенной выше формулой мы получаем: 1 * 24127-127) * (1 « 24 + 0)/2"24 = 1 Microsoft имитирует вещественные вычисления с помощью целочисленной арифметики с «высоким быстродействием» и точностью. Высокая точность означает длинную мантиссу, а быстродействие достигается конструированием формата, из которого в процессе вычислений легко выделяются компоненты числа.
176 Глава 3. Внутренние структуры данных GDI/DirectDraw Для представления вещественных чисел в GDI Microsoft использует структуру FL0AT0BJ. Эта структура делится на два 32-разрядных числа: старшее двойное слово (и12) определяет экспоненту, а младшее (ull) — мантиссу в сумме со знаковым битом. В отличие от формата IEEE скрытые биты или смещения в FL0AT0BJ не используются. Преобразование структуры FL0AT0BJ в вещественное число выполняется очень просто: double FL0AT0BJ2Double(const FLOATOBJ & f) { return (double) f.ull * pow(2, (double)f.u!2-32)); } Например, при представлении в формате FLOATOBJ числа 1.0 поле и12 равно 2, а поле ull — 0x40000000. Эти два числа легко преобразуются в исходную величину 2А30 * 2А(2 - 32) = 1. Помимо представления XF0RM в формате FLOATOBJ, GDI также хранит в целочисленных полях XF0RM_eDxI и XF0RM_eDyI округленные версии смещений (eDx и eDy). В структуре DCATTR содержится немало полей, смысл которых так и остается для нас загадкой. В то же время многие функции контекстов устройств не приводят к непосредственным изменениям DCATTR; например, вызовы SelectPalette, SetMiterLimit и SetArtDi recti on не изменяют содержимого DC_ATTR. Как будет показано ниже, DC_ATTR всего лишь является частью более сложной структуры данных, поддерживаемой GDI для контекста устройства. В структуре данных контекста устройства, хранящейся в адресном пространстве ядра, содержится зеркальная копия структуры DC_ATTR с большим количеством дополнительной информации о драйвере устройства, поддерживающем контекст. Подведем итог: в этом разделе мы рассмотрели структуры данных, доступные в пользовательском режиме, для объектов однородной кисти, прямоугольного региона, шрифта и контекста устройства. Эти структуры данных достаточно просты и в основном предназначены для оптимизации работы GDI при частых переключениях между привилегиями пользовательского режима и режима ядра. Чтобы лучше разобраться во внутренних структурах данных GDI, необходимо проанализировать остальные структуры данных, доступные в режиме ядра. ПРИМЕЧАНИЕ В системах с процессором Intel не рекомендуется использовать вещественные вычисления и инструкции ММХ в компонентах режима ядра, поскольку состояние этих операций не сохраняется при переключении задач. Это одна из причин, по которой в GDI вещественные числа представляются двумя 32-разрядными целыми. Другая причина — быстродействие на компьютерах с недостаточно быстрой или вовсе отсутствующей поддержкой вещественных вычислений. Графический механизм Windows NT/2000 содержит десятки функций, эмулирующих вещественные операций, — FLOATOBJ_ Add, FLOATOBJ_GreaterThan и т. д. На новых процессорах семейства Intel вещественные операции могут выполняться с такой же скоростью, как и целочисленные, однако преобразование вещественного числа в целое происходит относительно медленно. Windows 2000 содержит пару новых функций, позволяющих драйверу сохранить текущий контекст вычислений и использовать аппаратную поддержку вещественных операций и операций ММХ в режиме ядра.
Обращение к адресному пространству режима ядра 177 Обращение к адресному пространству режима ядра Нашим первым шагом к расшифровке структур данных GDI режима ядра должна стать возможность чтения данных из адресного пространства режима ядра в программе пользовательского режима (вроде GDIHandle). В Windows NT/2000 каждому процессу отводится адресное пространство объемом 4 гигабайта, но только нижние 2 гигабайта доступны из программ пользовательского режима. Верхние два гигабайта недоступны для программ пользовательского режима как для чтения, так и для записи или исполнения. При любых попытках обратиться к верхним 2 гигабайтам адресного пространства непосредственно из программы пользовательского режима генерируется аппаратная ошибка защиты. Даже отладчик Microsoft Visual C++ является программой пользовательского режима. Именно по этой причине он не позволяет, например, получить данные по адресу ОхЕ 1234580 или провести пошаговое выполнение DLL режима ядра (как, например, win32k.sys). Работа более мощных отладчиков — таких, как Numega Softlce/W — обеспечивается драйверами режима ядра. Если вы уже работали с Softlce/W, возможно, вы заметили, что при ручном запуске Softlce/W на короткое время появляется окно DOS с командой net start ntice. Эта команда загружает DLL режима ядра ntice.sys в адресное пространство ядра и создает новое устройство — компонент пользовательского режима, с которым взаимодействует Softlce/W. Драйверы режима ядра представляют собой специальные DLL, построенные по определенным правилам. Например, драйверы режима ядра не могут вызывать функции Win32 API, поскольку их точки входа расположены в пользовательском адресном пространстве. Драйверы режима ядра загружаются в адресное пространство ядра, в котором программы могут работать со всеми 4 гигабайтами адресного пространства. Большинство драйверов устройств Windows NT поддерживает операции ввода-вывода, моделируемые посредством файловых операций. Чтобы обратиться к этим драйверам средствами Win32 API, достаточно вызвать функцию Create- File, ReadFile, WriteFile или менее известную функцию DeviceloControl. Например, при помощи файловых операций можно работать с драйверами последовательного порта, параллельного порта и файловой системы. Кроме того, в Win32 предусмотрен набор функций для загрузки, запуска, остановки и закрытия драйверов устройств через служебный интерфейс API. Изящество подобного решения заключается в том, что драйвер устройства не обязан соответствовать реальному физическому устройству — такому, как параллельный порт или USB (Universal Serial Bus). Вы можете создать воображаемое устройство, написать для него драйвер, установить его функцией Win32 API и затем работать с ним при помощи файловых операций Win32. Архитектура драйверов устройств Windows NT/2000 позволяет решать всевозможные хитроумные задачи, не решаемые одними средствами Win32. Все, что требуется на текущей стадии наших исследований, — это возможность чтения данных из адресного пространства ядра. Если рассматривать 2-гигабайтное адресное пространство как виртуальный диск, можно написать для него
178 Глава 3. Внутренние структуры данных GDI/DirectDraw драйвер, который позволит прочитать любой блок памяти и передать его приложению пользовательского режима. Обычно драйвер устройства ввода-вывода для режима ядра Windows NT/2000 содержит одну точку входа, DriverEntry, вызываемую при загрузке драйвера: NTSTATUS DriverEntrydN PDRIVER_OBJECT Driver. IN PUNICODEJTRING RegistryPath) Функция DriverEntry предназначена для тех же целей, что и _DllMainStart- CRTStartup, точка входа в DLL пользовательского режима. Однако в отличие от DLL пользовательского режима, драйверы режима ядра обычно не экспортируют функций. Вместо этого DriverEntry сообщает системе адреса функций, которые должны экспортироваться системными средствами, с использованием структуры DRIVERJBJECT. Простой драйвер ввода-вывода может ограничиться реализацией минимального подмножества функций. Например, прршеденный ниже фрагмент DriverEntry экспортирует две функции. Функция DrvUnload вызывается при выгрузке драйвера. Функция DrvDispatch вызывается при создании, закрытии и вызове DeviceloControl. Driver->Driverllnload = DrvUnload; Driver->MajorFunction[IRP__MJ_CREATE] - DrvDispatch; Driver->MajorFunction[IRP_MJ_CLOSE] - DrvDispatch; Driver->MajorFunction[IRP_MJ__DEVICE_CONTROL] - DrvDispatch; Для достижения поставленной цели — чтения данных из адресного пространства ядра в пользовательском режиме — нам понадобится простой драйвер устройства. Назовем его Periscope. Главная функция драйвера — обработка запроса DeviceloControl. В параметре DeviceloControl передается начальный адрес и размер читаемого блока данных. Periscope читает данные в режиме ядра и сохраняет их в буфере, доступном из пользовательского режима при выходе из DeviceloControl. Ниже приведен полный исходный текст драйвера Periscope — «перископа», через который мы будем наблюдать за работой ядра. #include "kernelopt.h" #include "periscope.h" const WCHAR DeviceNameC] - L"\\Device\\Periscope"; const WCHAR DeviceLinkC] - L"\\DosDevices\\PERISCOPE"; // Обработка CreateFile. CloseHandle NTSTATUS DrvCreateClosedN PDEVICE_OBJECT DeviceObject. IN PIRP Irp) { Irp->IoStatus.Information = 0; Irp->IoStatus.Status - STATUS_SUCCESS: IoCompleteRequestdrp, I0_N0_INCREMENT); return STATUSJUCCESS: } // Обработка DeviceloControl NTSTATUS DrvDeviceControKIN PDEVICE_OBJECT DeviceObject. IN PIRP Irp)
Обращение к адресному пространству режима ядра 179 NTSTATUS nStatus = STATUSJNVALID_PARAMETER; Irp->IoStatus.Information = 0; // Получить указатель на текущую позицию стека. // в которой находятся коды функций и параметры PI0_STACK_L0CATI0N irpStack - IoGetCurrentIrpStackLocation (Irp); unsigned * ioBuffer = (unsigned *) Irp->AssociatedIrp.SystemBuffer; if ( (irpStack->Parameters.DeviceIoControl.loControlCode — IOCTL_PERISCOPE) && (ioBuffer!=NULL) && (irpStack->Parameters.DeviceIoControl. InputBufferLength >« 8) ) { unsigned leng - ioBuffer[l]; if ( irpStack->Parameters.DeviceIoControl. OutputBufferLength >- leng ) { Irp->IoStatus.Information * leng; nStatus - STATUSJUCCESS: _try { memcpy(ioBuffer. (void *) ioBuffer[0]. leng); } ^.except ( EXCEPTION JXECUTEJANDLER ) { Irp->IoStatus.Information - 0; nStatus - STATUSJNVALID_PARAMETER; } } } Irp->IoStatus.Status - nStatus: IoCompleteRequestCIrp. IOJJOJNCREMENT); return nStatus; // Обработка выгрузки драйвера void DrvUnloadCIN PDRIVER_OBJECT DriverObject) { UNICODE_STRING deviceLinkUnicodeString; RtlInitUnicodeString(&deviceLinkUnicodeString, DeviceLink); IoDeleteSymbolicLinkC&devi ceLi nkUni codeStri ng); IoDeleteDevice(DriverObject->DeviceObject); }
180 Глава 3. Внутренние структуры данных GDI/DirectDraw // Инициализационная точка входа // для устанавливаемых (installable) драйверов NTSTATUS DriverEntrydN PDRIVER_OBJECT Driver. IN PUNICODE_STRING RegistryPath) { UNICODE_STRING deviceNameUnicodeString; RtlInitUnicodeString( SdeviceNameUnicodeString. DeviceName ); // Создать устройство PDEVICE_OBJECT deviceObject = NULL; NTSTATUS ntStatus = IoCreateDevice (Driver. sizeof(KDeviceExtension). & deviceNameUnicodeString. FILE_DEVICE_PERISCOPE. 0. TRUE. & deviceObject); if ( NT_SUCCESS(ntStatus) ) { // Создать символическую ссылку, по которой приложения Win32 // будут получать доступ к драйверу/устройству UNICODEJTRING deviceLinkUnicodeString; RtllnitUnicodeString (SdeviceLinkUnicodeString. DeviceLink); ntStatus = IoCreateSymbolicLink( &devi ceLinkUni codeStri ng. &deviceNameUnicodeString); // Создать диспетчерскую таблицу драйвера if ( NT_SUCCESS(ntStatus) ) { Driver->DriverUnload = DrvUnload; Driver->MajorFunction[IRP_MJ_CREATE] = DrvCreateClose; Dri ver->MajorFuncti on[IRP_MJ_CLOSE] = DrvCreateClose; Driver->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DrvDeviceControl; } } if ( !NT_SUCCESS(ntStatus) && deviceObject!=NULL ) IoDeleteDevice(deviceObject): return ntStatus; } Основная часть кода составляет «скелет» базового драйвера режима ядра. Каждому устройству, поддерживаемому драйвером, должно соответствовать некоторое имя; в нашем примере используется имя Periscope. Это имя заносится в каталог Device пространства имен объектов Windows. В DDK входит небольшая утилита objdir, которая, помимо прочего, выводит список драйверов устройств, установленных в вашей системе. Функция DrvCreateClose обрабатывает создание и закрытие экземпляров устройства, инициируемые при вызове функций API CreateFile и CloseHandle. Функция DrvDeviceControl решает главную задачу — чтение блока памяти при вызове DeviceloControl в пользовательском приложении. Весь «интересный» код сосредоточен в нескольких строках функции DrvDeviceControl. Убедившись в том, что при вызове был передан правильный код, буфер
Обращение к адресному пространству режима ядра 181 ввода-вывода не пуст, а длина переданного параметра не менее 8 байт, программа получает начальный адрес и размер читаемого блока, после чего просто копирует запрашиваемые данные в выходной буфер. Обратите внимание: процесс чтения защищен механизмом обработки исключений — на тот случай, если какие-нибудь адреса окажутся недействительными. Функция DrvUnload обрабатывает выгрузку драйвера, а функция DriverEntry является главной точкой входа в драйвер. Чтобы приведенный код правильно откомпилировался в драйвер режима ядра, следует изменить некоторые параметры компилятора и компоновщика, используемые по умолчанию. Например, компилятор должен придерживаться соглашения о вызове stdcall вместо принятого по умолчанию соглашения cdecl. Флаг подсистемы Windows в драйвере должен быть равен «native,4.00» вместо Windows GUI. Эти изменения обеспечиваются включением соответствующих параметров в файл проекта и заголовочный файл kernelopt.h. При правильных настройках драйвер режима ядра будет успешно откомпилирован в Visual C++. Программа Periscope компилируется в крошечную библиотеку DLL режима ядра, Periscope.sys. В дальнейших программах предполагается, что эта DLL скопирована в корневой каталог диска С:. Драйвер написан для систем Windows NT 4.0/Windows 2000 и был в них протестирован. Динамическая загрузка, запуск, остановка и выгрузка драйверов устройств режима ядра хорошо поддерживаются на уровне Win32 API. Для выполнения этих функций мы определили класс KDevice C++. Конструктор KDevice устанавливает соединение с диспетчером управления службами, вызывая функцию OpenSCMManager. Открытая функция KDevice::Load загружает драйвер функцией CreateService, запускает драйвер функцией StartService, после чего получает манипулятор объекта устройства при помощи функции CreateFile. В качестве имени файла при вызове CreateFile указывается строка \\.\Periscope — стандартное обозначение открываемого устройства в Windows. После этого можно вызывать функцию DeviceloControl для полученного манипулятора и общаться с драйвером Periscope, работающем в режиме ядра. KDevice представляет собой обобщенный класс для работы с драйверами устройств Windows NT/2000. С таким же успехом можно воспользоваться им по отношению к другому драйверу. Класс KDevice устроен просто, поэтому мы не будем рассматривать его полный исходный текст и сразу перейдем к небольшой тестовой программе для работы с драйвером Periscope. // TestPeriscope.cpp #define STRICT #inc1ude <windows.h> #inc1ude <winioctl.h> #inc1ude <assert.h> #inc1ude "device.h" #include ". APeriscopeWPeriscope.h" class KPeriscopeClient : public KDevice { public: KPenscopeClient(const TCHAR * DeviceName) : KDevice(DeviceName)
182 Глава 3. Внутренние структуры данных GDI/DirectDraw { } bool Read(void * dst. const void * src, unsigned len); }: bool KPeriscopeClient::Read(void * dst. const void * src. unsigned len) { unsigned cmd[2] - { (unsigned) src. len }; unsigned long dwRead; return IoControl(IOCTL_PERISCOPE. cmd. sizeof(cmd). dst. len. &dwRead) && (dwRead==len): } int WINAPI WinMainCHINSTANCE. HINSTANCE. LPSTR. int) { KPeriscopeClient scope("PeriScope"); if ( scope.Load("c:\\periscope.sys")==ERROR_SUCCESS ) { unsigned char buf[256]; scope.Read(buf. (void*) 0xa000004E. sizeof(buf)); scope.CIose(); MessageBoxCNULL. (char*) buf. "Mem[0xa000004e]". MB_0K); } else MessageBox(NULL, fullname. "Unable to load c:\\periscope.sys". NULL. MB_0K): return 0; } Программа создает класс KPeriscopeClient, производный от KDevice, и включает в него дополнительный метод Read — оболочку для вызова DeviceloControl. Этот метод приказывает Periscope прочитать блок памяти при помощи специального управляющего кода IOCTL_PERISCOPE. Основная программа создает экземпляр KPeriscopeClient в стеке, загружает драйвер режима ядра и читает 256 байт, начиная с адреса 0ха000004е. Адрес принадлежит графическому механизму win32k.sys, обеспечивающему работу gdi32.dll и user32.dll. Базовый адрес win32k.sys равен ОхаООООООО. При чтении по смещению 0х4е от начала модуля Win32 обычно возвращается предупреждение, выводимое в DOS при выполнении Windows-программы: «This program cannot be run in DOS mode $». Если вы впервые работаете с текстом простого драйвера режима ядра Windows NT/2000 и элементарными средствами для работы с драйвером из пользовательского режима, вероятно, у вас возникнет искушение выполнить код в пошаговом режиме и посмотреть, как же все в действительности рзаботает. Вооружитесь отладчиком уровня ядра (таким, как Softlce/W), загрузите необходимые символы или таблицу экспортируемых функций для системных DLL, в по-
WinDbg и расширение отладчика GDI 183 шаговом режиме пройдите от функции WinMain в TestPeriscope.cpp до функции DrvDeviceControl в Periscope.cpp. Вы придете к состоянию стека, приведенному в табл. 3.3. Обратите внимание — между входом в функцию DeviceloControl в kernel32.dll и достижением DrvDeviceControl в Periscope работает системный код Windows, поэтому вам придется пройти через ассемблер. Также следует заметить, что ntdll.dll является библиотекой DLL пользовательского режима, а для переключения процессора в режим адресации ядра вызывается прерывание 2 Eh. Другими словами, прерывание 2 Eh обслуживается кодом режима ядра. Таблица 3.3. Состояние стека при переходе от программы пользовательского режима к драйверу режима ядра Уровень Функция Модуль/файл 1 WinMain TestPeriscope.cpp 2 KPeriscopedient::Read TestPeriscope.cpp 3 KDevice::IoContro1 Device.h 4 DeviceloControl Kernel32.dll 5 NTDeviceloControlFile Ntdll.dll 6 Int 2Eh 7 NTDeviceloControlFile Ntoskrnl.exe 8 Iof Call Driver Ntoskrnl.exe 9 DrvDeviceControl Periscope.cpp WinDbg и расширение отладчика GDI Возможность обращения к данным режима ядра Windows является неплохим базовым средством для начала исследований в области структур данных ядра, однако для этого необходимо знать, где искать информацию и как ее расшифровывать, а для этого потребуется хорошее знание ядра Windows. Самым авторитетным источником информации о ядре Windows остается компания Microsoft. Исходя из этого, мы обратимся к официальному инструментарию Microsoft и попробуем с его помощью разобраться в структурах данных GDI. В поставку Windows Platform SDK и Windows NT/2000 DDK входит мощная графическая утилита для отладки приложений Win32 и драйверов режима ядра Windows NT/2000, дающая помимо всего прочего возможность изучать аварийные дампы и данные «синих экранов». Речь идет о Microsoft Windows System Debugger (WinDbg). Самое приятное то, что эта программа распространяется бесплатно. Существует несколько вариантов применения WinDbg. О Для отладки приложений Win32 на одном компьютере как обычный отладчик пользовательского режима — например, отладчик Microsoft Visual C++.
184 Глава 3. Внутренние структуры данных GDI/DirectDraw В этом режиме вы не сможете войти в код режима ядра и работать с данными режима ядра. О Для удаленной отладки приложений Win32 по аналогии со средствами удаленной отладки в отладчике Visual C++. В этом режиме ведущий и ведомый компьютеры соединяются нуль-кабелем, через модем или по сети. Вы работаете с интерфейсом WinDbg на ведущем компьютере и отлаживаете программу, работающую на ведомом компьютере. При этом для отладчика доступен только пользовательский режим. О Для удаленной отладки кода режима ядра Windows NT/2000 по аналогии со средствами отладки ядра Softlce/W. В этом режиме ведущий и ведомый компьютеры соединяются нуль-кабелем. Ведомый компьютер запускается в специальной конфигурации с включенным режимом отладки ядра. WinDbg запускается на ведущем компьютере и управляет работой программ на ведомом компьютере. В режиме удаленной отладки ядра ведущий компьютер обладает доступом ко всему 4-гигабайтному адресному пространству ведомого компьютера. В области отладки кода режима ядра отладчик Softlce/W намного удобнее, поскольку для него достаточно одного компьютера, а для WinDbg нужен дополнительный ведущий компьютер. Кроме того, Softlce/W позволяет легко переходить из кода пользовательского режима в код режима ядра и обратно. С другой стороны, WinDbg превосходит Softlce/W в некоторых областях просто потому, что это официальная программа, разработанная в Microsoft. Отладчик WinDbg невелик, бесплатно распространяется и поддерживает разные версии Windows NT/2000, тогда как Softlce/W стоит немалых денег и нуждается в частых обновлениях при выходе новых версий Windows NT/2000. Самой замечательной особенностью отладчика WinDbg является его модульная, расширяемая архитектура. Обычный отладчик поддерживает ограниченный набор команд для обращения к данным и программному коду, установки точек прерывания, управления выполнением программы и т. д. WinDbg позволяет включать в отладчик новые команды за счет написания DLL расширения отладчика. Каждая DLL расширения обычно специализируется на конкретной области операционной системы Windows. В поставку WinDbg включены DLL расширения, разработанные компанией Microsoft (табл. 3.4). Таблица 3.4. Расширения отладчика WinDbg от Microsoft Расширение Gdikdx.dll Kdextx86.dll Ntsdexts.dll Rpcexts.dll Userexts.dll Userkdx.dll Vdmexts.dll Функциональность ОС GDI, режим ядра Исполнительная часть/HAL, режим ядра Стандартное расширение пользовательского режима Удаленный вызов процедур (RPC) USER, пользовательский режим USER, режим ядра NT DOS/WOW (Window in Window)
WinDbg и расширение отладчика GDI 185 Интерфейс WinDbg с расширениями отладчика организован очень просто, он полностью определяется в заголовочном файле DDK WDBGEXTS.h. Расширения отладчика должны экспортировать три обязательные функции CheckVersion, ExtensionApi Extension и WinDbgExtensionDllInit, выполняющие проверку версии и инициализацию. Функция CheckVersion убеждается в том, что версия ОС на ведомом компьютере совпадает с версией, для которой написано расширение. Не надейтесь получить правильные результаты при загрузке FREE-версии DLL расширения для отладки в CHECKED-версии ОС. Функция ExtensionApi Version проверяет, используют ли DLL расширения и хост WinDbg одну и ту же версию API. Функция WinDbgExtensionDllInit, самая важная из этих трех функций, передает структуру WINDBGEXTENSIONAPIS от WinDbg к DLL расширения. В настоящее время структура WINDBGEXTENSIONAPIS определяет 11 функций косвенного вызова, которые могут вызываться из DLL расширения. В реализации функций косвенного вызова задействованы DLL imagehlp, отладочные файлы символических имен и ведомая система, подключенная через нуль-кабель. typedef struct _WINDBG_EXTENSION_APIS { ULONG nSize: PWINDBG_OUTPUT_ROUTINE IpOutputRoutine; PWINDBG_GET_EXPRESSION 1pGetExpressi onRoutine; PWINDBG_GET_SYMBOL 1pGetSymbolRouti ne; PWINDBG_DISASM 1pDi sasmRouti ne; PWINDBG_CHECK_CONTROL_C 1pCheckControlCRouti ne; PWINDBG_READ_PROCESS_MEMORY_ROUTINE lpReadProcessMemoryRoutine; PWINDBG_WRITE_PROCESS_MEMORY_ROUTINE lpWriteProcessMemoryRoutine; PWINDBG_GET_THREAD_CONTEXT_ROUTINE lpGetThreadContextRoutine; PWINDBG_SET_THREAD_CONTEXT_ROUTINE IpSetThreadContextRoutine; PWINDBG_IOCTL_ROUTINE IpIoctlRoutine; PWINDBG_STACKTRACE_ROUTINE IpStackTraceRoutine; } WINDBG_EXTENSION_APIS. *PWINDBG_EXTENSION_APIS; Как видно из этого определения, DLL расширения могут обращаться к управляющей программе WinDbg с запросами на вывод строки, вычисление выражения, поиск символического имени, дизассемблирование кода, проверку аварийного завершения, чтение/запись содержимого памяти, чтение/запись контекста потока, вызов функций ввода-вывода и даже трассировку стека. Другими словами, вся информация об устройстве внутренних структур данных операционной системы находится у DLL расширения, a WinDbg обеспечивает интерфейс пользователя с отлаживаемой системой. Помимо трех обязательных функций DLL расширения может экспортировать и другие функции, которые могут использоваться в качестве команд в командной строке WnDbg. Имя экспортируемой функции совпадает с именем команды. Все экспортируемые функции имеют одинаковый прототип, определяемый следующим макросом: fine DECLARE API(s)s CPPMOD VOID с ( HANDLE hCurrentProcess. HANDLE hCurrentThread, ULONG dwCurrentPc. \ \ \ \ \ \
186 Глава 3. Внутренние структуры данных GDI/DirectDraw ULONG PCSTR dwProcessor, args ) Поскольку книга посвящена программированию графики в Windows NT/2000, нас в первую очередь интересует Gdikdx.dll — DLL расширения для отладки GDI в режиме ядра. После настройки WinDbg расширение Gdikdx.dll загружается командой 1 oad в командной строке WinDbg: > load gdikdx.dll Debugger extension library [.. .\system32\gdikdx] loaded Все команды расширений отладчика начинаются с символа !, чтобы их можно было отличить от стандартных команд WinDbg. Команда hel p выводит краткую сводку десятков команд, поддерживаемых расширением отладчика GDI. Как и следовало ожидать от внутреннего отладочного инструмента, для gdikdx.dll эта команда выводит устаревшую информацию. В частности, команды brush, cliserv, gdicall и proxymsg приведены в справке, но в действительности не поддерживаются; команда difi была заменена командой ifi, а новые команды dbli и ddib вообще не упоминаются. К счастью, у каждой команды имеется параметр •?, при помощи которого можно получить обновленную информацию. Обратившись к списку функций, экспортируемых gdikdx.dll, вы найдете имена новых команд, отсутствующие в справке. Команды расширения отладчика для отладки GDI в режиме ядра перечислены в табл. 3.5. Таблица 3.5. Команды расширения отладчика для GDI в режиме ядра Команда Параметры Использование dumphmgr dumpobj dumpdd dumpddobj dh dht ddib dbli ddc dpdev dldev [?] [?] [-P pid] [-1] [-s] object_typ [-P pid] [type] [-?] object handle [-?] object handle [-?] [-1 LPBITMAPINFO] [-w Width] [-h Height] [-f filename] [-b Bits] [-y Byte_Width] [-p palbits palsize] pbits [-?] BLTINFO * [-?adeghrstuvx] hdc [•?abdfghmnprRw] ppdev [■?] C-f] [-F#] ldev Сводка объектов GDI по типам Все объекты GDI заданного типа Объекты диспетчера манипуляторов DirectDraw Объекты DirectDraw заданного типа Запись HMGR для объекта GDI Тип/уникальность/индекс для манипулятора GDI Дамп растра Контекст устройства Объект физического устройства Объект логического устройства
WinDbg и расширение отладчика GDI 187 Команда dgdev dco dpo dppal dpw32 dpbrush dfloat ebrush dpso dblt dr cr dddsurface dddlocal dddglobal dsprite dspritestate rgnlog stats verifier hdc del dca ca mix la ef dteb dpeb Параметры [-?m] dgdevptr [-?] clipobj [-?] pathobj [-?] pal [-?] [process] [-?] pbrush | hbrush [•?] [-1 num] Value [-?] pbrush|hbrush [-?] [-f filename] surfobj [-?] BLTRECORD_PTR [-?] hrgn|prgn [-?] hrgn|prgn [-?haruln]ddsurface C-?ha] [-?ha] C-?ha] C-?ha] [-?] nnn[sl][s2][s3][s4] [-?] [•?hds] [-?gltf] handle [-?] DCLEVEL* [-?] DC_ATTR* [-?]COLORADJUSTMENT* [-?]MATRIX* [-?]LINEATTRS* [•?]address [count] [-?] TEB [-?] [-w] Использование GRAPHICS_DEVICE CLIPOBJ PATHOBJ EPALOBJ HBRUSH или PBRUSH Дамп вещественного числа или массива в формате IEEE HBRUSH или PBRUSH Структура SURFACE из SURFOBJ BLTRECORD REGION Проверка REGION EDDJURFACE EDD_DIRECTDRAW_LOCAL EDD_DIRECTDRAW_GLOBAL SPRITE SPRITE_STATE Последние nnn записей rgnlog Накапливаемая статистика Вывод информации верификатора Вывод структуры данных HDC пользовательского режима Вывод MATRIX из DC_ATTR Вывод команд из очереди ТЕВ Вывод кэшированных объектов РЕВ Продолжение #
188 Глава 3. Внутренние структуры данных GDI/DirectDraw Таблица 3.5. Продолжение Команда Параметры Использование с хо [-?] address [count] [-?] EXFORMOBJ* Шрифтовые расширения tstats gs gdata tm tmwi fo pfe pff pft stro gb gdf gp cache fh hb fv ffv helf ifi pubft pvtft devft dispcache [-?] [1..50] [-?] FDGLYPHSET* [-?] GLYPHDATA *elf [-?] TEXTETRICW* [-?]TMW_INTERNAL* [-?acfhwxy] FONTOBJ* [■?] PFE* [-?] PFF* [-?] PFT* [-?phe] STROBJ* [-?hmg] GLYPHBITS* [-?] GLYPHDEF* [-?] GLYPHPOS* [■?] CACHE* [•?] FONTHASH* [-?] HACHBUCKET* [-?] FILEVIEW* [-?] FONTFILEVIEW* [-?] font handle [-?] IFIMETRICS* [-?] [-?] [-?] [-?] Дамп всех открытых шрифтов Дамп всех закрытых или внедренных шрифтов Дамп всех шрифтов устройств Дамп кэша глифов для вывода структуры PDEV Вероятно, вам не терпится подключить второй компьютер через нуль-модем и опробовать на практике эти потрясающие команды, о существовании которых вы и не подозревали. Автору уже довелось через все это пройти. Даже если вам
WinDbg и расширение отладчика GDI 189 удастся правильно настроить ведущую и ведомую системы, связать их и запустить WinDbg на ведущем компьютере для управления ведомым компьютером, использовать команды расширения GDI непросто. Многие из них работают с манипуляторами объектов GDI или указателями на конкретные структуры данных. Чтобы воспользоваться этими командами, вам предстоит изрядно потрудиться над анализом ведомой системы и получением нужных манипуляторов объектов или указателей. Впрочем, исследования GDI требуют творческого и нетрадиционного подхода. Нельзя ли создать простейшую замену WinDbg, предназначенную не для общей отладки, а для единственной цели — лучшего понимания Windows NT/ 2000 GDI? Для этого нам понадобится простое приложение, управляющее DLL расширения GDI, которое работает на одном компьютере. Попробуйте представить, как команда dumphmgr расширения GDI выводит на ведущем компьютере сводку о таблице объектов GDI для ведомого компьютера. Процесс выглядит примерно так. 1. WinDbg по требованию пользователя загружает gdikdx.dll на ведущем компьютере. 2. Когда пользователь вводит команду ! dumphmgr, WinDbg передает ее функции dumphmgr, экспортируемой gdikdx.dll. 3. Функция dumphmgr библиотеки gdikdx.dll обращается к WinDbg с запросом на получение значения глобальной переменной win32k.sys, содержащей адрес таблицы объектов GDI в адресном пространстве ядра. Задача решается при помощи функций косвенного вызова, переданных Gdikdx.dll от WinDbg. WinDbg средствами IMAGEHLP API получает адрес по символическому имени. Не забывайте: отладочные файлы символических имен для ведомого компьютера должны быть установлены на ведущем компьютере, поэтому WinDbg обладает полным доступом к отладочной информации ведомого компьютера. 4. Gdikdx обращается к WinDbg с запросом на чтение значения переменной, содержащей указатель на таблицу объектов GDI, по адресу переменной в адресном пространстве ведомого компьютера. WinDbg посылает на ведомый ком* пьютер запрос по нуль-модему. Запрос обслуживается ведомым компьютером, работающим в режиме отладки. 5. Gdikdx обращается к WinDbg с запросом на чтение всей таблицы объектов GDI по ее начальному адресу. WinDbg снова передает запрос на ведомый компьютер. 6. Gdikdx обрабатывает полученные данные и обращается к WinDbg с запросом на вывод информации в окне. WinDbg как программа, управляющая работой расширения GDI gdikdx.dll, обеспечивает две основные функции — передачу команд gdikdx.dll и обслуживание функций косвенного вызова. Передача команд gdikdx.dll организуется очень просто; WinDbg передает экспортируемой функции манипуляторы текущего процесса и программного потока, программный счетчик процессора, количество процессов на ведомом процессоре и полную командную строку. Обслуживание функций косвенного вызова на первый взгляд кажется сложной задачей, поскольку существует 11 разных функций косвенного вызова. На самом деле gdikdx.dll
190 Глава 3. Внутренние структуры данных GDI/DirectDraw использует лишь некоторые из них. Больше всего трудностей возникает с функцией для чтения памяти процесса, находящейся в адресном пространстве ядра. К счастью, у вас имеется Periscope — драйвер режима ядра, созданный в предыдущем разделе. Давайте попробуем написать для gdikdx.dll небольшую управляющую программу. Программа Fosterer устроена несложно; это программа с пользовательским интерфейсом, через который разработчик вводит команды. Введенные команды передаются расширению отладчика GDI для выполнения. Когда расширению отладчика требуется декодировать символическое имя или прочитать блок памяти, оно обращается за помощью к Fosterer так, как обратилось бы к WinDbg. В следующем листинге приведено объявление класса KHost, обеспечивающего работу функций косвенного вызова. class KHost { public: KImageModule * pWin32k; KPeriscopeClient * pScope; HWND hwndOutput; HWND hwndLog; HANDLE hProcess: KHostO { pWin32k pScope hwndOutput hwndLog hProcess = NULL - NULL - NULL - NULL = NULL } void WndOutputCHWND hWnd. const char * format, vajist argptr): void Log(const char * format. ...): void ExtOutput(const char * format. ...): unsigned ExtGetExpression(const char * expr); bool ExtCheckControlC(void): bool ExtReadProcessMemory(const void * address, unsigned * buffer, unsigned count, unsigned long * bytesread); }: Класс KHost содержит пять переменных. Указатель pWin32k ссылается на экземпляр класса KImageModule, использующий функции imagehlp.dll для поиска символической информации в отладочных файлах графического механизма Windows win32k.sys. Второй указатель, pScope, ссылается на экземпляр класса KPeri scope, предназначенный для чтения данных из адресного пространства режима ядра. Первый манипулятор окна принадлежит главному текстовому окну, имитирующему окно вывода WinDbg. Второй манипулятор окна предназначен для сохранения дополнительной информации об использовании функций косвенного вызова в gdikdx.dll. Последняя переменная класса, hProcess, содержит манипулятор исследуемого процесса. Первые две функции решают вспомогательные задачи;
WinDbg и расширение отладчика GDI 191 за ними следуют пять функций, соответствующие пяти функциям косвенного вызова, которые мы собираемся реализовать. В следующем листинге приведена реализация функций ExtGetExpression и ExtReadProcessMemory. unsigned KHost::ExtGetExpression(const char * expr) { if ( (expr==NULL) || strlen(expr)==0 ) { assert(false); return 0; if ( (expr[0]>='0') && (expr[0]<='9') ) // Шести, число { DWORD number; sscanf(expr. "%x", & number); return number; } if ( pWin32k ) { const IMAGEHLP_SYMBOL * pis; if ( expr[0]=='&' ) // Пропустить первый & pis = pWin32k->ImageGetSymbol(expr+l); else pis - pWin32k->ImageGetSymbol(expr); if ( pis ) { Log("GetExpressionUs)=U081x\n". expr. pis->Address); return pis->Address; ExtOutput("Unknown GetExpression(""Us"")\n". expr); throw "Unknown Expression"; return 0; bool KHost;;ExtReadProcessMemory(const void * address, unsigned * buffer, unsigned count, unsigned long * bytesread) { if ( pScope ) { ULONG dwRead = 0; if ( (unsigned) address >= 0x80000000 ) dwRead = pScope->Read(buffer, address, count); else ReadProcessMemoryChProcess, address, buffer, count. & dwRead);
192 Глава 3. Внутренние структуры данных GDI/DirectDraw if ( bytesread ) * bytesread = dwRead; if ( (unsigned) address >= 0x80000000 ) Log("ReadKRamU08x. Xd)-\ address, count); else LogCReadURamUx. £08x. *d)=". hProcess. address, count); int len = min(4. count/4); for (int i=0; i<len; i++) Log("U08x ". buffer[i]); Log("\n"); return dwRead == count; } else { assert(false); return false; } } Функция KHost: .-ExtGetExpression получает символическое выражение, представленное символьной строкой, и пытается преобразовать его в числовую величину. Сначала функция пытается по возможности декодировать выражение в шестнадцатеричное число. В WinDbg манипуляторы и адреса обычно задаются именно в шестнадцатеричной системе. Если первая попытка завершается неудачей, функция считает, что ей было передано символическое имя, и вызывает pWin32k->ImageGetSymbol для получения адреса по полученному имени вида win32k!gcMaxHmgr. Указатель pWin32k ссылается на объект KImageModule, в который была предварительно загружена информация о символических именах для файла win32k.sys. Функция KImageModule: :ImageGetSymbol, не приведенная в книге, вызывает функцию SymGetSymFromName для преобразования символического имени в адрес. Интересная подробность: при вызове функция SymGetSymFromName получает указатель на неконстантный указатель на строку, тогда как ExtGetExpression в качестве параметра принимает только константный указатель на строку. Возникает естественное желание — преобразовать константный указатель в неконстантный, обмануть компилятор и добиться своего. Ничего не выйдет; вызов SymGetSymFromName завершится неудачей, и вы получите сообщение об ошибке доступа. Обе стороны настроены серьезно. Функция ExtGetExpression вызывается из библиотеки gdikdx.dll, которая компилируется в Visual C++ с параметром, перемещающим все строки в секцию, доступную только для чтения. Следовательно, строки, передаваемые ExtGetExpression, должны быть доступны только для чтения. Функция SymGetSymFromName ищет символ !, отделяющий имя модуля от имени функции, и заменяет его нуль-символом, чтобы обеспечить правильное завершение имени модуля. В результате для константной строки будет генерироваться ошибка. Проблема решается просто: перед вызовом SymGetSymFromName функция Image- GetSymbol копирует параметр в локальную переменную.
WinDbg и расширение отладчика GDI 193 Функция KHost: :ReadProcessMemory отвечает за чтение блоков памяти. Сначала она убеждается в том, что адрес принадлежит пространству ядра. Если проверка дает положительный результат, функция использует класс KPeriscopeClient (см. предыдущий раздел), который, в свою очередь, использует наш маленький драйвер режима ядра Periscope.sys; в противном случае просто вызывается функция Win32 API ReadProcessMemory с манипулятором процесса. Обратите внимание: при правильно заданном манипуляторе функция ReadProcessMemory позволяет читать содержимое адресного пространства пользовательского режима другого процесса. Однако KHost является классом C++, тогда как API расширения отладчика WinDbg определяется только с использованием средств С. Нам придется немного потрудиться, чтобы состыковать их. Ниже приведена часть оставшегося кода. KHost theHost; void WDBGAPI ExtOutputRoutine(PCSTR format. ...) { vajist ap; va_start(ap. format); theHost.WndOutput(theHost.hwndOutput. format, ap): va_end(ap); } UL0N6 WDBGAPI ExtGetExpression(PCSTR expr) { return theHost.ExtGetExpression(expr); } void WDBGAPI ExtGetSymboKPVOID offset. PUCHAR pchBuffer. PULONG pDisplacement) { throw "GetSymbol not implemented"; } ULONG WDBGAPI ExtReadProcessMemory(ULONG address. PVOID buffer. ULONG count. PULONG bytesread) { return theHost.ExtReadProcessMemory( (const void *)address. (unsigned *) buffer, count, bytesread): } WINDBG_EXTENSION_APIS ExtensionAPI - { sizeof(WINDBG_EXTENSION_APIS). ExtOutputRoutine. ExtGetExpression. ExtGetSymbol.
194 Глава 3. Внутренние структуры данных GDI/DirectDraw ExtDisAsm, ExtCheckControl_C, ExtReadProcessMemory, ExtWri teProcessMemory. ExtGetThreadContext. ExtSetThreadContext. ExtlOCTL, ExtStackTrace }: Для взаимодействия с расширением отладчика необходимо заполнить структуру WINDBG_EXTENSION_APIS информацией об И функциях косвенного вызова. Пять из этих функций отображаются на функции класса KHost через глобальный экземпляр theHost. Остальные функции просто инициируют исключения, которые перехватываются главной программой (если до этого не будут перехвачены в gdikdx.dll). В тексте приведена лишь небольшая часть программы Fosterer, но в целом это вполне стандартная и простая Windows-программа. Главная программа создает несколько дочерних окон; в одном окне вводится манипулятор процесса, в другом — команда. В третьем окне выполняется весь основной вывод. Кроме того, создается дополнительное всплывающее (pop-up) окно для вывода служебной информации. Главная программа отвечает за загрузку драйвера Periscope режима ядра, отладочную информацию win32k.sys, а самое главное — расширение отладчика WinDbg gdikdx.dll. Она инициализирует gdikdx.dll таблицей функций косвенного вызова и проверяет совместимость текущей версии ОС с версией ОС gdikdx.dll. У расширения отладчика GDI имеется очень интересная команда dumphmgr, с которой мы и начнем. Эта команда должна выводить общие сведения о манипуляторах GDI — то есть ту самую таблицу объектов GDI, за которой мы так долго охотились в этой главе. Если все было настроено правильно, введите в окне команды строку dumphmgr, щелкните на кнопке Do, закройте глаза и попытайтесь угадать, что вы сейчас увидите. Ура! Работает! Нам удалось успешно использовать gdikdx.dll без WinDbg, всего на одном компьютере, без запуска ОС в отладочном режиме, без нуль-модема — и мы получили сводку содержимого таблицы объектов GDI из адресного пространства ядра! Причем для работы программы Fosterer нам совершенно ничего не нужно знать о таблице объектов GDI, поскольку всей необходимой информацией владеет расширение отладчика GDI. Окно программы Fosterer изображено на рис. 3.7. В небольшом поле слева выводится идентификатор процесса; наверху справа находится поле ввода команды. Команда передается расширению отладчика GDI при щелчке на кнопке Do. В главном окне отображаются результаты работы самой программы и расширения отладчика GDI. В нескольких начальных строках выводится статус загрузки драйвера режима ядра Periscope, файла отладочной информации для графического механизма и расширения отладчика GDI. Расширения отладчика строятся вместе с ОС Windows, поэтому им присваивается тот же номер сборки. Программа убеждается в том, что номер сборки расширения отладчика совпадает с аналогичным номером ОС, и если номера различаются — выводит предупреждение. Точные совпадения встречаются редко, но вы должны постараться, чтобы эти номера были как можно ближе друг к другу.
Структуры данных режима ядра 195 НПЕЗЗжИ Рйе нф Command j20c I DO Urn Miiiiinl jPeriscope loaded JD:\WINNT50^ (Windows OS V osymbolsxsys^ v5.0, bui Id J"D:\WINMT50\System32\gd |««* Extension DLL(2013 jdumphmgr jMax handles jTotal Hmgr: |ulLoop-113C | TYPE JDEF TYPE !DC TYPE ;RGN TYPE JSURF TYPE iCLIOBJ TYPE PAL TYPE 1ICMLCS TYPE JLFONT TYPE Ipfe type |brush type Jtotals jcUnused obj out so f Reserved ar iumphmgr ,.\win32k. 2031 ikdx Free) 1130 memory dll" dbg loaded. loaded. does not match target ШШШВ№&'*:' ' system(2031 Free) 2097152 Committed 36864 gcMaxHmgr-1130 handl current 132, 102, 37, 492, 3, 34, : i. 95, 102, 132, 998, ects 132 ijcUnknown objects 0 0 0 0 0 0 0 0 0 0 0 0 0 - - - - - - - - - - - es, (objects) maximum allocated 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 - 0, 0 0 0 0 0 0 0 0 0 0 0 LookAside LAB Cur 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 0 - 0 ' M*\\ 1 LAB Max 0 1 о 3 о % 0 $ 0 | о % 0 0 1 о ;| о 3 0 Рис. З.7. Управление расширением отладчика WinDbg в программе Fosterer После статусной информации выводятся результаты выполнения команды dumphmgr. Из них видно, что диспетчер манипуляторов GDI (фрагмент кода, отвечающий за работу с таблицей объектов GDI) зарезервировал в адресном пространстве ядра целых 2 мегабайта, но из них актуализировано только 36 Кбайт. Из максимального количества манипуляторов GDI (16 384) с момента последней перезагрузки компьютера одновременно задействовалось не более ИЗО. В момент обработки команды dumphmgr использовались только 998 объектов GDI, а остальные 132 манипулятора относились к созданным, а затем удаленным объектам. В сводке объектов GDI выводится количество контекстов устройств, растров, палитр, логических шрифтов, кистей и т. д., фактически присутствующих в системе. Впрочем, этот пример дает лишь поверхностное представление о том, что можно сделать при помощи расширения отладчика GDI. Этот инструмент играет важнейшую роль в процессе анализа внутренних структур данных GDI. Структуры данных режима ядра Вооружившись драйвером устройства режима ядра Periscope, расширением отладчика WinDbg gdikdx.dll и простейшей программой для управления расширением отладчика Fosterer, можно, наконец, переходить к исследованию недокументированных структур данных GDI в режиме ядра Windows NT/2000.
196 Глава 3. Внутренние структуры данных GDI/DirectDraw Таблица объектов GDI в механизме GDI Как было показано в предыдущих разделах, каждый процесс Win32 работает с глобальной таблицей объектов GDI. В пользовательских процессах таблица доступна только для чтения и в разных процессах она отображается на разные адреса. В GDI существует недокументированная функция GdiQueryTable, возвращающая адрес таблицы объектов GDI для текущего пользовательского процесса. В действительности таблица объектов GDI находится под управлением графического механизма GDI Win32k.sys. Она доступна для чтения и записи с фиксированного адреса в адресном пространстве ядра. Таблица объектов GDI отображается в пользовательское адресное пространство каждого процесса, работающего со средствами GDI. Программный код, управляющий таблицей объектов GDI, называется диспетчером манипуляторов (Handle ManaGeR); вот почему при исследовании внутреннего строения GDI так часто встречается сокращение hmgr. В соответствии со служебными данными, полученными в программе Fosterer, win32k.sys поддерживает глобальную переменную с именем gpentHmgr, указывающую на начало таблицы объектов GDI в адресном пространстве ядра. Максимальное количество объектов GDI, на которое рассчитана таблица объектов GDI, равно 16 384. Обычно таблица используется лишь частично, поэтому многие элементы таблицы остаются пустыми. В Win32k.sys поддерживается еще одна глобальная переменная gcMaxHmgr, в которой хранится максимальный индекс задействованного элемента таблицы. GdiTableCell * gpentHmgr; unsigned long gcMaxHmgr; Элемент таблицы объектов GDI представляет собой 16-разрядную структуру, которую мы назвали GdiTableCell (см. раздел «Расшифровка таблицы объектов GDI»). Типы объектов GDI в механизме GDI Все мы хорошо знакомы с такими объектами GDI, как перья, кисти, шрифты, регионы, палитры и т. д. Однако в таблице объектов GDI присутствует немало других разновидностей объектов, не встречающихся на уровне Win32 API. В табл. 3.6 перечислены типы объектов GDI, полученные по команде dumphmgr. Таблица 3.6. Типы объектов GDI Тип Идентификатор типа Описание Удаленные объекты GDI Контекст устройства, метафайл Объект DirectDraw (теперь обрабатывается отдельно) Поверхность DirectDraw (теперь обрабатывается отдельно) Регион DEFJYPE DCJYPE DD_DRAW_TYPE DD_SURF_TYPE RGN TYPE 0x00 0x01, 0x21 0x02 0x03 0x04
Структуры данных режима ядра 197 Тип SURFJYPE CLIOBJ_TYPE PATH_TYPE PAL_TYPE ICMCSJYPE LFONTTYPE RFONTJYPE PFEJYPE PFTJYPE ICMCXFJYPE ICMDLL_TYPE BRUSH_TYPE D3D_HANDLE_TYPE DD_VPORT_TYPE SPACE_TYPE DD_MOTION_TYPE METAJYPE EFSTATEJYPE BMFD_TYPE VTFDJYPE TTFDJYPE RC_TYPE TEMPJYPE DRVOBJ_TYPE DCIOBJJYPE SPOOL_TYPE Идентификатор типа 0x05 0x06 0x07 0x08 0x09 0x0a OxOb OxOc OxOd OxOe OxOf 0x10, 0x30 Oxll 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 Oxla Oxlb Oxlc Oxld Oxle Описание Аппаратнозависимый растр Клиентский объект Траектория Палитра Логический шрифт Кисть, перо Из более чем 30 типов объектов, перечисленных в табл. 3.6, программистам Win32 известны лишь некоторые — например, объекты DCJTYPE, BRUSHJTYPE и LFONTTYPE, соответствующие контексту устройства, кисти/перу и логическому шрифту. Интересный факт: кисти и перья относятся к одному типу BRUSHJTYPE, хотя их идентификаторы типов несколько отличаются. Win32 API не содержит
198 Глава 3. Внутренние структуры данных GDI/DirectDraw функций для непосредственного создания объектов траекторий (PATHJTYPE), хотя логика подсказывает, что какой-то объект в памяти все же создается. Построение траектории начинается с вызова функции BeginPath. При помощи расширения отладчика GDI мы исследуем структуры данных ядра, создаваемые для объектов GDI. Контекст устройства в механизме GDI Контекст устройства является одним из основных объектов GDI. Его многочисленные атрибуты определяют различные аспекты взаимодействия Win32 API с графическим устройством, будь то видеоадаптер, принтер, плоттер или фотонаборная машина. GDI хранит данные контекста устройства в двух местах. Структура пользовательского режима DC_ATTR содержит такие атрибуты, как текущее перо, текущая кисть, цвета фона и текста. Определение структуры DC_ATTR приведено в разделе «Отслеживание СОМ-интерфейсов DirectDraw» главы 4. Механизм GDI также поддерживает структуру DC0BJ в адресном пространстве ядра; эта структура содержит полную информацию об объекте контекста устройства, включая копию DC_ATTR. Для манипулятора контекста устройства поле pKernel элемента таблицы объектов GDI ссылается на экземпляр DC0BJ, а поле pUser — на экземпляр DC_ATTR. Расширение отладчика GDI поддерживает несколько команд, предназначенных для расшифровки структуры данных, соответствующих манипуляторам устройств. Команда ddc расшифровывает HDC и выводит в основном содержимое DC0BJ; команда del выводит содержимое структуры DCLEVEL со структурой DC0BJ; команда dca выводит содержимое структуры DC_ATTR, присутствующей как в адресном пространстве ядра, так и в пользовательском адресном пространстве. Ниже показано то, что мы знаем об этих структурах. // // ty г 1 dcobj.h Windows 2000, pedef struct HPALETTE void * void * unsigned unsigned unsigned HGDIOBJ unsigned void * void * void * HGDIOBJ unsigned LINEATTRS void * void * 440(0xlB8) байт hpal; ppal; pColorSpace: HcmMode; ISaveDepth; unklJOOOOOOO; hdcSave; unk2 00000000[2]; pbrFill: pbrLine; unk3_ela28d88; hpath; // flPath; // lapath; // prgnClip; prgnMeta; COLORADJUSTMENT ca; // unsigned flFontState; HPATH PathFlags 0x20 байт 0x18 байт
Структуры данных режима ядра 199 unsigned unsigned unsigned unsigned MATRIX MATRIX FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ void * SIZE } DCLEVEL; // Windows 2000. typedef struct { HGDIOBJ void * ULONG ULONG DHPDEV unsigned unsigned void * void * unsigned unsigned unsigned DCLEVEL DC_ATTR unsigned unsigned RECTL unsigned RECTL RECTL unsigned void * void * void * POINT unsigned void * unsigned void * unsigned void * unsigned void * ufi: unk4 00000000C12]: Л; flbrush; mxWorldToDevice; mxDeviceToWorld; efMllPtoD; efM22PtoD: efDxPtoD; efDyPtoD: efMll TWIPS; efM22 TWIPS; efPrll; efPr22; pSurface; sizl; 1548(0x600 байт hHmgr; pEntry; cExcLock; Tid; dhpdev; dctype; fs; ppdev; hsem: f1 Graphics; flGraphics2; pdcattr; dcLevel: dcAttr; hdcNext; hdcPrev; erclClip; // 000 // 004 // 008 // 00c // 0x010 // Флаги // 0x020 // Указатель на DC ATTR // 0x030 0xlB8(440) байт // 0xlC8(456) байт // ОхЗВО unk4_00000000[2]; erclWindow; erclBounds; unk5_00000000[4]; prgnAPI; prgnVis; prgnRao: FillOrigin; unk6_00000000[10]; peal; // Указатель на DCLEVEL.ca unk7_00000000[20]; pca2; unk8_00000000[20]; рсаЗ; unk9_00000000[20]; pca4;
200 Глава 3. Внутренние структуры данных GDI/DirectDraw unsigned HFONT unsigned void * unsigned unsigned unsigned unsigned unka 00000000C10]: hlfntCur; unkb_00000000[2]: prfnt: unkc 00000000[33]: unkd OOOOffff; unke ffffffff; unkf 00000000C3]; } DCOBJ; В последний раз подробные описания структур вроде DCOBJ встречались в книге Шульмана (Schulman), Макси (Махеу) и Питрека (Pietrek) «Undocumented Windows», опубликованной в 1992 году. Эта книга помогла нам разобраться в некоторых полях, унаследованных от Windows 3.0/3.1, — как расшифрованных, так и не расшифрованных командами расширения отладчика. Для каждого объекта GDI данные режима ядра начинаются с 16-байтовой структуры. В первом поле хранится манипулятор GDI объекта; второе поле содержит неизвестный указатель; третье поле — счетчик блокировок, а последнее поле — идентификатор программного потока, создавшего объект. По манипулятору механизм GDI может обратиться к таблице объектов GDI и определить, какому процессу принадлежит манипулятор, а также получить доступ к структурам пользовательского режима (таким, как DCATTR). Первое поле после заголовка, dhpdev, содержит манипулятор структуры PDEV, находящейся под управлением драйвера графического устройства. Драйвер графического устройства должен обеспечивать управление несколькими физическими устройствами. Для этого драйвер устройства определяет структуру данных, необходимую для управления этими устройствами. В документации Windows DDI эти структуры упоминаются под именем PDEV; они определяются и используются только драйвером устройства. Чтобы драйвер создал и инициализировал структуру PDEV, механизм GDI вызывает функцию драйвера DrvEnablePDEV. Поскольку структура PDEV управляется исключительно драйвером устройства, механизм GDI не интересуют подробности ее строения, поэтому DDI (интерфейс драйвера устройства) позволяет DrvEnablePDEV вернуть манипулятор PDEV вместо указателя на PDEV. Механизм GDI действует честно — он позволяет разработчику драйвера скрыть реализацию за манипулятором по аналогии с тем, как сам механизм GDI скрывает свою реализацию за манипуляторами GDI. Манипулятор, полученный при вызове DrvEnablePDEV, используется механизмом GDI при последующих обращениях к физическому устройству для создания графической поверхности. Чтобы освободить память и ресурсы, занимаемые физическим устройством, механизм GDI вызывает функцию DrvDisablePDEV. В Windows NT/2000 DDK включены примеры исходных текстов нескольких драйверов экрана, причем все они используют разные структуры PDEV. Функция DrvEnablePDEV, как правило, возвращает в качестве манипулятора обычный указатель на PDEV. Как мы знаем из Win32 API, существует несколько разных типов контекстов устройств. В структуре DCOBJ эти различия обозначаются в поле dctype. В настоящее время выделяются три типа контекстов: typedef enum {
Структуры данных режима ядра 201 DCTYPEJ3IRECT =0. // обычный контекст устройства DCTYPEJ1EM0RY =1, // совместимый контекст DCTYPE__INF0 =2 // информационный контекст }: Поле fs структуры DC0BJ содержит флаги, относящиеся к контексту устройства. Ниже перечислены некоторые из флагов, выводимых расширением GDI. typedef enum { DC DISPLAY DC DIRECT DC CANCELED DC PERMANENT DC DIRTY RAO DC ACCUM WMGR DC ACCUM APP DC RESET DC SYNCHRONIZEACCESS DC EPSPRINTINGESCAPE DC TEMPINFODC DC FULLSCREEN DC IN CLONEPDEV DC REDIRECTION - 0x0001. = 0x0002. - 0x0004. = 0x0008. = 0x0010. - 0x0020. - 0x0040. - 0x0080. = 0x0100. - 0x0200. - 0x0400. • 0x0800. - 0x1000. = 0x2000 } DCFLA6S; Следующее поле DCOBJ выводится расширением GDI под именем ppdev. Вполне естественно предположить, что это сокращение означает «Pointer to Physical DEVice», то есть «указатель на физическое устройство». В расширении GDI даже предусмотрена команда dpdev для расшифровки указателя на PDEV. Но согласно DDK, структура данных физического устройства находится под управлением драйвера устройства, и механизму GDI о ней знать ничего не положено. Функция драйвера DrvEnablePDEV возвращает манипулятор физического устройства вместо указателя на него. Одно из возможных объяснений заключается в том, что механизм GDI создает для физического устройства свою собственную структуру данных, которую мы назовем PDEVWIN32K, чтобы избежать путаницы со структурой PDEV драйвера. Структура PDEVWIN32K устроена чрезвычайно сложно. Мы поближе познакомимся с ней в следующем подразделе. Поле hsem ссылается на структуру семафора. Очевидно, семафор предназначен для синхронизации обращений к полям. В полях flGraphics и flGraphics2 хранятся флаги возможностей устройства. Состав этих флагов документируется в DDK; к их числу принадлежат флаги GCAPS_ALTERNATEFILL, GCAPS_WINDINGFILL, GCAPS JX)LORJ)ITHER и т. д. Флаги flGraphics2 и flGraphics2 берутся из структуры DEVINF0, заполняемой функцией DrvEnablePDEV драйвера устройства. Поле pdcattr ссылается на структуру DCATTR данного контекста устройства в адресном пространстве пользовательского режима, содержащую большую часть атрибутов контекста. Структура DC0BJ содержит копию этой структуры в поле dcAttr. Вероятно, разработчики GDI хотели оптимизировать процесс присваивания значений атрибутам DC, сведя к минимуму использование кода режима ядра; для этого структура DCATTR должна размещаться в адресном пространстве пользовательского режима. Однако разработчики также хотели упростить дос-
202 Глава 3. Внутренние структуры данных GDI/DirectDraw туп к атрибутам в режиме ядра, для чего копия DC_ATTR должна находиться и в режиме ядра. Синхронизация двух копий DC_ATTR осуществляется с помощью специальных флагов. В процессе анализа структуры DCATTR выяснилось, что выполнение некоторых функций с манипулятором контекста устройства (например, выбор HBITMAP в совместимом контексте устройства или выбор палитры в DC) никак не влияет на содержимое таблицы объектов. Если вас интересует, эти атрибуты хранятся в структуре DCLEVEL, содержащейся в DC0BJ. Структура DCLEVEL содержит информацию о палитре, цветовой глубине, регулировке цвета, атрибутах линий, области отсечения, преобразованиях, траекториях и т. д. Структура PDEV в механизме GDI Все графические драйверы поддерживают базовую точку входа DrvEnableDriver. При загрузке драйвера механизм GDI вызывает функцию DrvEnableDriver, которая заполняет структуру DRVENABLEDATA. DrvEnableDriver передает механизму GDI таблицу реализованных функций, тем самым сообщая ему, какие функции поддерживаются драйвером. В DirectDraw также создаются некоторые таблицы функций косвенного вызова. Конечно, механизм GDI должен хранить полученную информацию, относящуюся к конкретному драйверу, в некоторой структуре данных. Ниже приведено описание структуры PDEV механизма GDI. // Windows 20000 3304 (0хСЕ8) байт typedef struct { unsigned void * int int void * unsigned unsigned void * void * POINT. unsigned SPRITESTATE HFONT HF0NT HFONT HGDIOBJ unsigned void * void * unsigned unsigned void * void * void * void * header[4]; ppdevNext; cPdevRefs; cPdevOpenRefs; ppdevParent; flags; fl Accelerated; hsemDevLock; hsemPointer; ptlPointer; unk_0038[2]; SpriteState; hlfntDefault; hifntAnsiVariable; hifntAnsiFixed; ahsurf[6]; unk_0240[2]: prfntActive; prfntlnactive; clnactive; unk_0254[27]; pfnDrvSetPoi nterShape pfnDrvMovePointer; pfnMovePointer; pfnSync; // 0010 // 0014 // 0018 // 001c // 0020 // 0024 // 0028 // 002c // 0030 // 0038 // 0040. 476(ldc) байт // 021c // 0220 // 0224 // 0228 // 0240 // 0248 // 024c // 0250 // 0254 // 02c0 // 02c4 // 02c8 // 02cc
Структуры данных режима ядра 203 unsigned void * unsigned void * DHPDEV void * DEVINFO GDI INFO void * void * unsigned unsigned unk 02d0; pfnDrvSetPalette; unk_02d8[2]; pldev; dhpdev; ppalSurf; devinfo; gdiinfo; pSurface; hSpooler; pDesktopId: unk 0054; EDD_DIRECTDRAW_GLOBAL eDirectOrawGlobal; void * POINT DEVMODEW * unsigned void * PDEV WIN32K; pGraphicsDevice; ptlOrigin; pdevmode; unk 0b78[3]; apfn[89]; // // // // // // // // // // // // // // // // // // 02d0 02d4 02d8 02e0 02e4 02e8 02ec-417 0418-547 0548 054c 0550 0554 1552 (Oxi 0b68 0b6c 0b74 0b78 0b84 Структура PDEV_WIN32K имеет довольно большой размер (3304 байта) и содержит большое количество информации, относящейся к драйверу устройства. PDEVWIN32K в первую очередь используется механизмом GDI при обращениях к драйверу графического устройства для выполнения различных запросов пользователя. Структура начинается с неизвестного заголовка, состоящего из 16 байт. Разные структуры PDEVWIN32K, существующие в системе, объединяются в иерархическое дерево. Поле ppdevNext содержит ссылку на следующую структуру, а поле ppdevParent указывает на родительскую структуру. В расширении отладчика GDI поддерживается команда dpdev для расшифровки структуры PDEV_ WIN32K. У этой команды имеется параметр -R, предназначенный для рекурсивного вывода всех структур, на которые ссылается родительская структура. Если воспользоваться параметром -R для структуры PDEV_WIN32K, соответствующей экранному контексту устройства, вы увидите, что поле ppdevNext связывается со структурами PDEVWIN32K нескольких шрифтовых драйверов. В Windows GDI существует несколько типов графических драйверов, каждый из которых обладает специфическими особенностями. Классификация драйверов осуществляется на основании поля флагов flags. В табл. 3.7 перечислены некоторые флаги, поддерживаемые расширением GDI. Таблица 3.7. Флаги структуры PDEV_WIN32K Флаг Интерпретация PDEVDISPLAY Экранный вывод PDE VHARDWAREPOINTER Аппаратная поддержка курсора PDEV_G0TF0NTS Наличие шрифтового драйвера PDEV_DRIVER_PUNTED_CALL Драйвер возвращает запросы механизму GDI PDEVFONTDRIVER Шрифтовой драйвер
204 Глава 3. Внутренние структуры данных GDI/DirectDraw Следующие несколько полей предназначены для управления курсором мыши в драйверах экрана. Поле hsemPointer представляет собой семафор, синхронизирующий операции с курсором мыши. Драйвер устройства обеспечивает несколько функций косвенного вызова для вывода курсора мыши; адреса этих функций хранятся в полях pfnDrvSetPointerShape и pfnDrvMovePointer. В системе автора эти поля ссылаются на mga64!DrvSetPointerShape и mga64!DrvMovePointer. Структуры SPRITESTATE и DIRECTDRAWGLOBAL, внедренные в PDEVWIN32K, относятся к реализации DirectDraw. Мы рассмотрим эти структуры в следующем разделе. В PDEVWIN32K хранятся манипуляторы трех шрифтов. В системе автора поле hlfntDefault ссылается на гарнитуру «System», поле hifntAnsiVariable — на гарнитуру «MS Sans Serif», а поле hi fntAnsi Fixed — на гарнитуру «Courier». Хотя Windows GDI старается соответствовать принципу WYSIWYG, со штриховыми кистями возникают проблемы. В GDI штриховая кисть определяется монохромным растром размером 8 х 8. На экранах с разрешением от 72 dpi до 120 dpi горизонтальные, вертикальные, диагональные или решетчатые узоры выглядят вполне нормально. Однако на принтерах с разрешением от 180 до 2400 dpi и даже выше узор из растров, определяемых матрицами 8x8 пикселов, превращается в сплошную серую рябь. Чтобы штриховые кисти были лучше видны на устройствах высокого разрешения, механизм GDI позволяет драйверу устройства передать свои собственные растры для реализации шести стандартных типов штриховых кистей Windows GDI. Функция EnablePDEV драйвера устройства может передать массив из шести указателей на поверхности (растры), а манипуляторы соответствующих объектов GDI сохраняются в массиве ahsurf. Хотя драйверам экрана рекомендуется передавать эти манипуляторы, в структуру PDEVWIN32K экранного DC включается шесть манипуляторов стандартных растров 8x8, передаваемых GDI по умолчанию. Структуры GDI обычно существуют в виде пар; одна структура относится к логическому описанию, а другая — к физической реализации. Следовательно, для структуры физического устройства PDEVWIN32K следует поискать парную структуру с логическим описанием. Указатель йа такую структуру хранится в поле pldev, а сама структура расшифровывается командой расширения GDI dldev. Структуры LDEVWIN32K образуют двусвязный список. Начиная с экранного контекста устройства, список открывается драйвером экрана (например, «\SystemRoot \System32\mga64.dll»), за которым следует несколько шрифтовых драйверов. Последовательность завершается шрифтовым драйвером ATM («\SystemRoot\ System32\atmfd.dll»). // Windows 2000, 384 (0x180) байт typedef struct { LDEV_WIN32K * nextldev; LDEV_WIN32K * prevldev; UL0NG Tevtype; UL0NG cRefs; UL0NG unkJIO; void * pGdiFriverlnfo; UL0NG ulDriverVersion; PFN apfn[89]: } LDEV_WIN32K;
Структуры данных режима ядра 205 По данным протокола, сгенерированного программой Fosterer, для получения первой логической структуры графического устройства расширение отладчика GDI читает значение глобальной переменной win32k!gpldevDrivers. Структура PDEVWIN32K содержит копию структуры DEVINF0, заполняемой точкой входа DrvEnablePDEV графического драйвера. Структура DEVINF0 документирована в DDK. В основном она описывает возможности драйвера устройства по обработке кривых, шрифтов, графических форматов, работе с цветом и т. д. Еще структура PDEVWIN32K содержит копию структуры GDI INFO, также заполняемой точкой входа DrvEnablePDEV и документированной в DDK. Структура GDI INFO в основном содержит информацию о размере, формате и разрешении графической поверхности. Многие поля структуры GDI INFO можно получить при помощи функции Win32 API GetDeviceCaps. Например, вызов GetDeviceCaps(hDC, TECHNOLOGY) связан с полем ulTechnology структуры GDIINF0, а значение GetDeviceCaps(hDC, RASTER- CAPS) берется из поля flRaster структуры GDIINF0. Поле pSurface ссылается на структуру поверхности SURFACE, где фактически выполняются все графические операции. Структура поверхности рассматривается ниже в этом разделе. Поле pdevmode ссылается на структуру DEVM0DEW, Unicode-версию DEVMODE. Структура DEVMODE обычно инициализируется графическим драйвером и модифицируется пользовательским приложением, что позволяет не только получать информацию от драйвера устройства, но и менять значения параметров, настройка которых допускается драйвером. При выводе на экран структура DEVMODE особой пользы не приносит, однако драйвер принтера получает из нее важную информацию о качестве печати, размере бумаги, типе носителя, разрешении и т. д. Последнее и самое важное поле структуры PDEVWIN32K, apfn, представляет собой таблицу из 89 указателей на функции. В Windows 2000 интерфейс DDI определяет 89 функций, которые могут реализовываться драйвером графического устройства; каждой функции соответствует заранее определенный индекс. Например, индекс INDEX DrvEnablePDEV равен 0, а индекс INDEX_DrvSynchronizeSurface равен 88. Одни из этих 89 индексов не используются, другие зарезервированы, третьи предназначены только для драйверов экрана, а четвертые — только для драйверов принтеров. Лишь небольшая часть этих функций обязательно должна реализовываться драйверами устройств; остальные функции необязательны. При загрузке драйвера устройства система вызывает функцию DrvEnableDriver, которая заполняет структуру DRVENABLEDATA. В сущности, структура DRVENABLEDATA представляет собой сжатую таблицу с 89 указателями на функции. Присваивание значений 89 указателям на функции — утомительная работа, чреватая ошибками и плохо расширяемая. По этой причине механизм GDI позволяет драйверу передать список поддерживаемых им функций вместе с индексами, по которому механизм GDI строит расширенную таблицу. Таблица функций хранится в двух местах. Структура логического устройства LDEVWIN32K содержит исходную таблицу функций, сконструированную по данным DRVENABLEDATA и полученную от драйвера устройства. Структура физического устройства PDEVWIN32K содержит таблицу, фактически используемую механизмом GDI; эта таблица содержит функции из LDEVWIN32K, а также точки входа механизма GDI для реализации функций, не поддерживаемых драйвером устройства. Например, если драйвер устройства не поддерживает DrvBitBlt, он фактически обращается к механизму GDI с
206 Глава 3. Внутренние структуры данных GDI/DirectDraw просьбой предоставить реализацию этой функции. По этой причине таблица функций PDEVJJIN32K вместо указателя NULL содержит указатель на функцию win32k.sys — Win32ISpBitBlt. В табл. 3.8 приведено содержимое таблицы функций DDI на компьютере автора. Таблица 3.8. Пример таблицы функций PDEV_WIN32K Индекс 00 01 02 03 04 05 06 07 10 11 12 13 14 15 17 18 19 20 22 23 24 29 30 31 40 Адрес fdd691f0 fdd69310 fdd69350 fdd693b0 fdd69640 fdd69760 fdd69710 fdd68fa0 fdd4fc00 fdd4fd00 fdd50fb0 fdd50cc0 a00a8fe3 aOOaaafc fdd68890 aOO1834b a001d26d a0064500 fdd68cl0 a001d72e fdd70fcc fdd5del0 fdd5df90 аООаабЗЬ a003c327 Имя функции mga64!DrvEnablePDEV mga64!DrvCompletePDEV mga64!DrvDisablePDEV mga64!DrvEnableSurface mga64!DrvDisablePDEV mga64!DrvAssertMode mga64!Drv0ffset mga64!DrvResetPDEV mga64!DrvCreateDevi ceBi tmap mga64!DrvDeleteDevi ceBi tmap mga64!DrvReali zeBrush mga64!DrvDi therColor win32k!SpStrokePath win32k!SpFil!Path mga64!DrvPaint win32kISpBitBlt win32k!SpCopyBits win32k!SpStretchBlt mga64!DrvSetPalette win32k!SpText0ut mga64!DrvEscape mga64!DevSetPoi nterShape mga64!DrvMovePoi nter win32k!SpLineTo wi n32k!SpSaveScreenBlt
Структуры данных режима ядра 207 Индекс 41 43 59 60 61 67 68 69 70 71 74 Адрес fdd69950 fdd5bf60 fdd6efl0 fdd6fl90 fdda0410 fdd68dc0 a0036184 a0073180 a010dl93 aOlOdOfl a010d049 Имя функции mga64!DrvGetModes mga64!DrvDestroyFont mga64!DrvGetDi rectDrawInfо mga64!DrvEnableDi rectDraw mga64!DrvDi sableDi rectDraw mga64!DrvIcmSetDevi ceGammRamp win32k!SpGradientFill win32k!SpStretchBUR0P win32k!SpPlgBlt win32k!SpALphaBlend wi n32k!SpTransparentBlt Как видно из таблицы, в случае с драйвером экрана механизм GDI выполняет основную работу по выводу кривых, заливок, текста и растров, а драйвер экрана выполняет инициализацию, операции с курсором мыши, реализацию объектов и т. д. Поверхности в механизме GDI На уровне механизма GDI графические функции работают с поверхностями, связанными с драйвером устройства, на котором осуществляется вывод. При работе с поверхностями устройств используется координатная система, напоминающая режим отображения ММТЕХТ GDI API. Пикселы поверхности адресуются парами 28-разрядных целых чисел со знаком; в левом верхнем углу расположено начало координат — точка (0, 0). Поверхность устройства лежит в правом нижнем квадранте этой системы координат, а обе координаты принимают только неотрицательные значения. Хотя координаты в Win32 API хранятся и передаются в виде 32-разрядных целых чисел со знаком, в некоторых графических операциях механизм GDI использует младшие 4 бита 32-разрядного целого для представления дополнительных координат (субпикселов), повышающих точность вычислений. В механизме GDI определены два основных типа поверхностей. Поверхности первого типа, управляемые механизмом GDI, в документации DDK обычно именуются аппаратно-независимыми растрами (Device-Independent Bitmap, DIB). Поверхности, управляемые GDI, состоят из одной цветовой плоскости с упакованными пикселами и выравниванием строк развертки по границам двойных слов. Если драйвер устройства работает с поверхностью, управляемой графическим механизмом, весь вывод на этой поверхности может быть выполнен средствами GDI. Поддержка со стороны механизма GDI в несложных драйверах экрана или драйверах растровых принтеров заметно упрощает сами драйверы
208 Глава 3. Внутренние структуры данных GDI/DirectDraw и их сопровождение. Пример драйвера кадрового буфера, входящий в Windows 2000 DDK, создает поверхность, управляемую графическим механизмом, в качестве основной поверхности и поручает выполнение вывода GDI. Драйвер принтера UniDrv в Windows 2000 также использует поверхности, управляемые графическим механизмом, после деления физической страницы на серию прямоугольных полос. Ко второму типу относятся поверхности, управляемые устройством; то есть драйверам устройств дозволяется организовать самостоятельное управление своими поверхностями. Во внутреннем представлении формат поверхности, управляемой устройством, может совпадать с форматом поверхности, управляемой графическим механизмом, или отличаться от него. Если форматы совпадают, драйвер устройства все равно может выполнять графические операции средствами GDI. Растры в формате устройства (device-format bitmap) составляют особую категорию специализированных форматов поверхностей, управляемых устройствами. Данная возможность поддерживается для того, чтобы некоторые драйверы экрана могли реализовать ускоренное копирование растров на экран. Кроме того, это позволяет драйверам осуществлять вывод в видеопамяти, поделенной на банки, или работать с растрами в нестандартных форматах. Главной структурой данных, предназначенной для представления различных поверхностей GDI, является структура SURF0BJ. Структура SURF0BJ документирована в Windows NT/2000 DDK. Она занимает одно из центральных мест в интерфейсе DDI и используется для представления как растров, так и графических поверхностей. Поскольку структура SURF0BJ очень важна для работы механизма GDI, ниже приведено ее определение, позаимствованное из документации DDK. typedef struct JURFOBJ { DHSURF dhsurf; HSURF hsurf; DHPDEV dhpdev; HDEV hdev; SIZEL sizlBitmap; UL0NG cjBits; PV0ID pvBits: PVOID pvScanO; LONG 1 Delta; UL0NG iUniq; UL0NG iBitmapFormat; USH0RT iType; USH0RT fjBitmap; } SURFOBJ; В первом поле, dhsurf, хранится манипулятор, предназначенный для идентификации поверхностей, управляемых устройством; он может представлять собой указатель, индекс или любое другое значение, с которым сможет работать драйвер устройства. Поле hsurf содержит манипулятор GDI для поверхности — обычно это манипулятор аппаратно-зависимого растра или DIB-секции. Поле dhpdev содержит манипулятор структуры PDEV драйвера устройства, возвращаемый функцией DrvEnablePDEV. В поле hdev хранится логический манипулятор GDI для физического устройства.
Структуры данных режима ядра 209 Размер пиксела поверхности определяется полем sizlBitmap структуры SURFOBJ. Для поверхностей, управляемых механизмом GDI, поле pvBits указывает на графические данные растра поверхности; в поле cjBits задается его размер, а поле pvScanO указывает на первую строку развертки растра. Не забывайте о том, что поверхности DIB могут храниться в памяти как в прямом, так и в перевернутом виде. В последнем случае значение pvBits не совпадает с pvScanO. В поле 1 Delta хранится смещение соседних строк развертки в байтах; при помощи этой величины механизм GDI может быстро перемещаться между строками развертки. Для нормальных растров значение поля 1 Delta положительно, а для перевернутых — отрицательно. Поле illniq предназначено для целей оптимизации. Оно содержит текущее состояние поверхности, управляемой графическим механизмом, и обновляется при каждом изменении поверхности. Это позволяет драйверу устройства организовать кэширование поверхностей. Например, если драйвер принтера PostScript получает два запроса на вывод растра с одним исходным растром и одинаковыми значениями iUniq, драйверу достаточно сохранить исходный растр при обработке первого запроса и воспользоваться им при получении второго запроса. В поле iBitmapFormat структуры SURFOBJ задается стандартный формат поверхности, управляемой графическим механизмом, наиболее близко подходящий к формату данной поверхности. Это может быть изображение с 1, 4, 8, 16, 24 и 32 битами на пиксел, несжатое или сжатое по алгоритму RLE. В Windows 2000 GDI драйвер устройства также может поддерживать сжатые изображения в формате JPEG и PNG, для чего полю iBitmapFormat присваиваются соответственно значения BMFJPEG и BMFPNG. Однако ни Windows GDI, ни графический механизм не поддерживают работу с изображениями в формате JPEG или PNG; эти изображения просто передаются драйверу устройства, если последний заявляет о своей поддержке этих форматов. В поле iType задается тип поверхности. Допустимые значения перечислены в табл. 3.9. Таблица 3.9. Типы поверхностей SURFOBJ.iType STYPE_BITMAP STYPE_DEVICE STYPE_DEVBITMAP Описание Растр, управляемый механизмом GDI Поверхность, управляемая драйвером Растр, управляемый драйвером, в формате устройства В последнем поле f jBitmap хранятся некоторые флаги поверхностей, управляемых графическим механизмом. Эти флаги сообщают, хранится ли растр в прямом или перевернутом виде, инициализируется ли он нулями, является ли он транзитивным или отсутствующим в системной памяти. Если предполагается, что структура SURFOBJ представляет все графические поверхности механизма GDI, где же хранятся сведения о цветах — например, палитра? В механизме GDI управление цветом отделено от SURFOBJ. Для каждого графического вызова, использующего SURFOBJ, передается указатель на струк-
210 Глава 3. Внутренние структуры данных GDI/DirectDraw туру XLATE0BJ, которая при необходимости обеспечивает преобразование цветов между исходной и целевой поверхностью. Например, функции DrvStretchBlt и DrvPlgBlt используют параметр pxlo, содержащий указатель на объект XLATE0BJ. Аппаратно-зависимые растры в механизме GDI Аппаратно-зависимые растры (Device-Dependent Bitmaps, DDB) управляются драйверами графических устройств с поддержкой со стороны Windows GDI. Прежде чем использовать поверхность DDB, необходимо создать для нее объект GDI, при этом возвращается манипулятор типа HBITMAP. Хотя предполагается, что аппаратно-зависимые растры поддерживаются драйвером устройства в собственном формате, все большее количество драйверов устройств Windows NT/ 2000 поручает выполнение большинства графических операций механизму GDI. Для этого формат их растров должен соответствовать формату, поддерживаемому механизмом GDI. Манипуляторы HBITMAP также находятся под управлением диспетчера манипуляторов GDI. Следовательно, с каждым манипулятором в таблице объектов GDI связано 16 байт информации, включая указатель на структуру в адресном пространстве ядра. В расширении отладчика GDI эта структура называется SURFACE. Главной частью структуры SURFACE является структура SURF0BJ. Определение структуры SURFACE выглядит следующим образом: // Windows 2000. 128 (0x80) байт typedef struct HGDI0BJ void * UL0NG UL0NG SURF0BJ XDC0BJ * FL0NG PPALETTE unsigned SIZEL HDC UL0NG HPALETTE unsigned SURFACE: hHmgr; pEntry; cExcLock; Tid; surfobj; pdcoAA; flags; ppal; unk_050[2]; sizlDim[2]; hdc: cRef: hpalHint; unk_06c[5]; // // // // // // // // // // // // // // 000 004 008 00c 010, 044, 048 04c 050 058 060 064 068 06c документируется i выводится gdikdx Структура SURFACE, как и структуры ядра других объектов GDI, начинается с 16-байтового заголовка. После заголовка следует структура SURFOBJ с информацией о формате, размере, графическими данными и т. д. Структура SURFACE должна полностью описывать растр GDI — либо DDB, либо DIB-секцию. Поэтому в структуре SURFACE после структуры SURFOBJ хранится манипулятор палитры и указатель на структуру PALETTE. PALETTE является структурой режима ядра для объекта логической палитры GDI. Мы рассмотрим структуру PALETTE в одном из следующих разделов этой главы.
Структуры данных режима ядра 211 Поле флагов flags в структуре SURFACE содержит флаги APIBITMAP (растр, созданный средствами Win32 API) и DDBSURFACE (аппаратно-зависимый растр Win32 API). Аппаратно-зависимые растры Win32 API и DIB-секции могут выбираться в контексте устройства. В этом случае поле hdc содержит манипулятор контекста устройства, а в поле cRef хранится счетчик выборов объекта в DC. Поле sizlDim обеспечивает поддержку функций Win32 API SetBitmapDimensionEx и GetBitmap- DimensionEx, предоставляя место для хранения физических размеров растра. Терминология Win32 GDI API и Windows NT/2000 DDK нередко приводит к недоразумениям; в обоих случаях используются термины DIB и DDB. В Win32 API существует три типа растров: аппаратно-зависимые растры (DDB), DIB-секции и аппаратно-независимые растры (DIB). Поверхности DDB и DIB-секции находятся под управлением GDI; это означает, что операции их создания, выбора, копирования данных, записи данных и итогового уничтожения должны выполняться средствами GDI API. Однако DIB не находятся в компетенции GDI. Вы можете самостоятельно создать DIB, не прибегая к помощи GDI. Чтение и запись графических данных осуществляются непосредственно по указателю, без использования манипулятора и GDI. В GDI предусмотрено несколько функций для вывода DIB в контекстах устройств GDI. На уровне механизма GDI все растры Win32 — DDB, DIB и DIB-секции — представляют собой поверхности. Очевидно, DIB и DIB-секции относятся к поверхностям, управляемым механизмом GDI (в документации DDK они объединяются термином DIB). Однако DDB могут храниться как в формате DIB, так и в формате устройства (DDB в документации DDK ) — все зависит от драйвера графического устройства. Каждому аппаратно-зависимому растру (DDB) соответствует манипулятор GDI (HBITMAP). Полная информация о растре хранится в структуре SURFACE адресного пространства ядра. У типичных драйверов экрана поле iType структуры SURFOBJ, находящейся внутри SURFACE, обычно равно STYPEBITMAP; поле f jBitmap обычно равно BMFJTOPDOWN; поле flags обычно равно APIBITMAP | DDB_SURFACE, а поле pvBits указывает на адресное пространство ядра. Таким образом, память для графических данных DDB выделяется в общем адресном пространстве ядра из выгружаемого пула. DIB-секции в механизме GDI В терминологии Win32 API DIB-секцией (DIB section) называется растр, который находится под управлением GDI, но доступен для пользовательских программ непосредственно через указатель. DIB-секции создаются функцией CreateDIB- Section с передачей описания в структуре BITMAPINFO. GDI возвращает манипулятор HBITMAP, с которым можно выполнять те же операции, что и с манипуляторами DDB, а также указатель на графические данные, которые можно читать и записывать через указатель, как содержимое обычного блока памяти. В таблице объектов GDI DIB-секция почти эквивалентна DDB. У нее тоже имеется манипулятор и структура SURFACE в адресном пространстве ядра. Главное отличие заключается в том, что память для графических данных DIB-секции выделяется в адресном пространстве пользовательского режима вместо
212 Глава 3. Внутренние структуры данных GDI/DirectDraw адресного пространства режима ядра. Благодаря этому обстоятельству графические данные становятся доступными для пользовательских программ; кроме того, вывод средствами механизма GDI может происходить лишь в том случае, если процесс-владелец является текущим процессом. Поле f jBitmap структуры SURF0BJ для DIB-секций равно BMF_DONTCACHE. Это означает, что графический драйвер не должен кэшировать графические данные на основании содержимого поля iUniq, поскольку графические данные могут быть изменены пользовательской программой без ведома GDI через указатель, полученный при вызове Create- DIBSection. Другое, второстепенное отличие заключается в том, что DIB-секции, как и DIB, обычно хранятся в памяти в перевернутом виде, если только их высота не задается отрицательной величиной. Мы знаем, что аппаратно-независимые растры (DIB) не находятся под управлением GDI. В частности, для них нельзя создать манипуляторы GDI. Однако при передаче DIB драйверу устройства в интерфейсе DDI применяется все та же структура SURF0BJ вместо структуры BITMAPINFO, используемой для представления DIB в Win32 API. Видимо, механизм GDI создает временную структуру SURF0BJ для представления DIB перед обращением к точкам входа механизма GDI или драйвера устройства. Кисти в механизме GDI Кисти задают цвет и узор заполнения некоторой области. Средства Win32 API позволяют создавать однородные (solid) кисти, штриховые (hatched) кисти, узорные (pattern) кисти DDB, а также узорные кисти DIB. Из раздела «Структуры данных пользовательского режима» мы знаем, что для однородных кистей в адресном пространстве пользовательского режима создается небольшая структура для хранения цвета кисти, что повышает эффективность использования однородных кистей. Для всех остальных типов кистей GDI хранит всю информацию в структуре BRUSH ядра. typedef struct { unsigned AttrFlags; COLORREF IbColor; } BRUSHHATTR; // Windows 2000. 112 (0x70) typedef struct { HGDIOBJ void * ULONG ULONG ULONG HBITMAP HANDLE ULONG hHmgr; pentry; cExcLock; Tid; ulStyle; hbmPattern hbmClient; flAttrs: байт (?) // 000, заголовок объектов GDI режима ядра // 004 // 008 // 00с // 010 // 014 // 018 // 01с ULONG ulBrushUnique: // 020 BRUSHATTR * pbrushhttr; // 024
Структуры данных режима ядра 213 BRUSHATTR unsigned unsigned COLORREF COLORREF ULONG ULONG ULONG unsigned ULONG unsigned ULONG DWORD * ULONG unsigned BRUSH; * pbrushattr; unk 030; bCacheGrabbed; crBack; crFore; ulPal Time; ulSurfTime; ulRealization; unk 04c[3]; ulPenWidth; unk 05c; ulPenStyle; pStyle; dwStyleCount; unk 06c; // 028 // 030 // 034 // 038 // 03c // 040 // 044 // 048 II 04c // 058 // 05c // 060 // 064 // 068 Структура BRUSH начинается со стандартного 16-байтового заголовка объектов GDI ядра. За ним следует поле ul Style стиля кисти, значение которого отличается от значения аналогичного поля структуры L0GBRUSH. В расширении отладчика GDI оно кодируется константами HS_CR0SS, HSPAT, HSDITHEREDCLR и т. д. В полях crBack и crFore хранится основной и фоновый цвет контекста устройства, а в поле brushAttr.lbColor — настоящий цвет кисти. В поле flAttrs хранятся дополнительные флаги (табл. 3.10). Таблица 3.10. Атрибуты кисти в структуре BRUSH BRUSH.flAttrs Описание BRJIEED_BK_CLR (0x0002) BR_DITHER_OK (0x0004) BR_IS_SOLID (0x0010) BR_IS_HATCH (0x0020) BR_IS_BITMAP (0x0040) BR_IS_DIB (0x0080) BR_IS_NULL (0x0100) BR_IS_GL0BAL (0x0200) BR_IS_PEN (0x0400) BR_IS_0LDSTYLEPEN (0x0800) BRJSJ1ASKING (0x8000) BR_CACHED_IS_S0LID (0x80000000) Необходим фоновый цвет Разрешить смешивание цветов Однородная кисть Штриховая кисть Узорная кисть DDB Узорная кисть DIB Пустая кисть Стандартные объекты Перо Геометрическое перо Растр узора используется как маска прозрачности При работе с узорными кистями DIB механизм GDI создает объект для растра кисти, манипулятор которого хранится в поле hbmPattern, при этом в поле
214 Глава 3. Внутренние структуры данных GDI/DirectDraw hbmClient остается манипулятор HGL0BAL, передаваемый при вызове CreateDIB- PatternBrush. Для узорных кистей DDB механизм GDI копирует исходную поверхность DDB, сохраняя манипулятор копии в поле hbmPattern, а манипулятор исходной поверхности — в поле hbmClient. Копирование исходного растра позволяет программисту удалить его после создания объекта кисти. Объект узорной кисти никогда не существует в одиночку; для него всегда создается парный объект растра узора. К этому моменту вы должны уже достаточно хорошо понимать, как различные типы кистей представляются в механизме GDI. Перья в механизме GDI Перо определяет цвет и стиль линий, дуг и кривых. Win32 API позволяет создавать косметические и геометрические перья с разными стилями, разной толщиной и атрибутами. Как ни странно, механизм GDI не определяет специальной структуры данных для представления перьев — для них используется та же структура BRUSH, что и для кистей. Впрочем, это выглядит вполне логично, если заметить, что расширенные перья, создаваемые функцией ExtCreatePen, определяются с помощью структуры L0GBRUSH. Механизм GDI различает перья и кисти по флагу BR_IS_PEN в поле flAttrs. Другой флаг, BRISOLDSTYLEPEN, указывает, было ли перо создано при помощи «старомодной» функции CreatePen (или CreatePenlndirect) вместо «новой» функции ExtCreatePen. Поля ulPenWidth, ulPenStyle, pStyle и dwStyleCount имеют тот же смысл, что и аналогичные поля структуры EXTLOGPEN, определяемой в Win32 API. В расширении отладчика GDI существует команда dpbrush для расшифровки структуры BRUSH, однако эта команда работает лишь с полями, относящимися к «настоящим» кистям. Для перьев, созданных функцией ExtCreatePen, эта команда возвращает неполную информацию. Палитры в механизме GDI Палитра представляет собой цветовую таблицу, по которой цветовые индексы преобразуются в значения RGB или, наоборот, значения RGB преобразуются в исходный цветовой индекс. Чтобы работать с палитрой в контексте устройства, необходимо создать логическую палитру функцией CreatePalette или CreateHalf- tonePalette. Эти функции возвращают манипулятор логической палитры (тип HPALETTE). Кроме палитр, обычно описываемых структурой LOGPALETTE, в Win32 используется и другая форма таблиц преобразования цветов — структура BITMAPINFO, являющаяся частью DIB и DIB-секций. Количество индексов в цветовой таблице вычисляется по информации поля bmiHeader структуры BITMAPINFO, а сами данные таблицы хранятся в массиве bmiColors. Структура BITMAPINFO позволяет определять цвет по индексу для растров, содержащих не более 256 цветов. При работе с 16-, 24- и 32-разрядными DIB-растрами также имеется возможность определения масок для выделения красной, зеленой и синей составляющей из 16-, 24- и 32-разрядных цветовых данных.
Структуры данных режима ядра 215 Механизм GDI должен поддерживать единую реализацию для обоих вариантов трансляции цветов. Задача решается при помощи структуры EPALOBJ (имя структуры позаимствовано из gdikdx.dll). typedef unsigned long HDEVPPAL: typedef void * PTRANSLATE; typedef void * PRGB555XL; typedef unsigned PALJJLONG; // Windows 200( typedef struct ; ( HGDIOBJ void * ULONG ULONG FLONG ULONG ULONG HOC HDEVPPAL ULONG ULONG PTRANSLATE PTRANSLATE PTRANSLATE unsigned PFN PFN ULONG PRGB555XL EPALOBJ * PAL ULONG * PAL ULONG } EPALOBJ; ). 84+4n байт _EPAL0BJ hHmgr; pentry; cExcLock; Tid; flPal; cEntries; ulTime; hdcHead; hSelected; cRefhpal; cRefRegular; ptransFore; ptransCurrent ptransOld; unk_038; pGetNearer; pGetMatch; ulRGBTime; pRGBClate; pPalette; papal Col or; apalColor[l]; // // // // // // // // // // // // // // // // // // // // // // 000. 004 008 00c 010 014 018 01c 020 024 028 02c 030 034 038 03c 040 044 048 04c, 050, 054 заголовок объек- this this->apa!Color Структура EPALOBJ представляет объект логической палитры в режиме ядра, поэтому она, как и структуры всех объектов GDI, начинается со стандартного заголовка. Тип таблицы трансляции цветов определяется содержимым поля Л Pal. В табл. 3.11 приведены значения, полученные из выходных данных расширения отладчика GDI и частично — из заголовочного файла winddi.h. Таблица 3.11. Флаги EPALOBJ EPALOBJ.flPal Значение Описание PALJNDEXED PALJITFIELDS PAL_RGB PAL BGR 0x0001 0x0002 0x0004 0x0008 Индексируемая палитра Используются битовые маски Красный, зеленый, синий Синий, зеленый, красный Продолжение &
216 Глава 3. Внутренние структуры данных GDI/DirectDraw Таблица 3.11. Продолжение EPALOBJ.flPal Значение Описание PAL_CMYK PALDC PALFIXED PALFREE PALM0N0CHR0ME PAL_DIBSECTION PALHT PAL_PGB16_555 PAL RGB16 565 0x0010 0x0100 0x0200 0x0400 0x2000 0x8000 0x100000 0x200000 0x400000 Голубой, малиновый, желтый, черный Не может изменяться Только два цвета Используется для DIB-секции Полутоновая палитра 16-битный RGB-цвет в формате 555 16-битный RGB-цвет в формате 565 В поле cEntries хранится количество элементов в цветовой таблице ара!Color. Эти два поля аналогичны полям структуры PAL0BJ. Механизм GDI сохраняет в структуре EPAL0BJ адреса двух функций, pGetNearest и pGetMatch. На компьютере автора поле pGetNearest ссылается на win32k!ulIndexedGetNearestFromPal Entry, а поле pGetMarch — на ulIndexedGetMatchFromPalEntry (хотя в других системах они могут ссылаться на что-нибудь другое). Драйверы устройств не работают со структурой EPAL0BJ напрямую. В файле winddi.h определяется структура PAL0BJ, содержащая единственное поле ulReserved. Чтобы обратиться к цветовой таблице, драйвер устройства должен вызвать функцию графического механизма PAL0BJ_cGetColors. Прослеживается аналогия со структурой XLATEOBJ, для обращения к которой также определяется специальная функция XLATE0BJ_cGetPalette. Регионы в механизме GDI Регион (region) определяется как совокупность точек на поверхности графического устройства. Он может иметь форму прямоугольника, многоугольника, эллипса или произвольной комбинации этих фигур. Для регионов определены операции заливки, инвертирования и обводки; кроме того, они используются при отсечении или проверке принадлежности (hit testing). Вероятно, чаще всего регионы применяются при отсечении. Регионы принадлежат к числу объектов, управляемых GDI. Новые регионы создаются такими функциями, как CreateRectRgn, CreateRoundRgn и CreateEllip- ticRgn. Объединение существующих регионов осуществляется посредством логических операций. Все эти функции возвращают манипулятор объекта GDI, HRGN, который используется при последующем вызове функций GDI. Как было показано в разделе «Структуры данных пользовательского режима», координаты прямоугольных регионов GDI хранит в структурах данных пользовательского режима. Для других регионов информация хранится в адресном пространстве ядра.
Структуры данных режима ядра 217 В расширении отладчика GDI предусмотрена команда dr, предназначенная для расшифровки HRGN или указателя на структуру данных REGION режима ядра. Команда даже перечисляет все прямоугольники, из которых состоит заданный регион. Ниже приведена информация о структуре REGION, полученная при помощи этой команды. // Windows 2000, переменный размер // Не используйте непосредственные ссылки на scnPntCntToo! typedef struct LONG scnPntCnt; LONG scnPntTop; LONG scnPntBottom; LONG scnPntX[2]; LONG scnPntCntToo; } SCAN; // Количество координат х // Верхняя граница (включается) // Нижняя граница (не включается) // Массив переменной длины, содержащий х пар // То же. что и scnPntCnt; // Windows 2000. переменный размер struct REGION / l HGDIOBJ hHmgr: void * pentry; ULONG cExcLock; ULONG Tid: unsigned sizeObj; unsigned unk_014[2] SCAN * pscnTail; unsigned sizeRgn; unsigned cScans; RECTL rcl; SCAN scnHead[l] // 000. заголовок объектов GDI режима ядра // 004 // 008 // 00с // 010 ; // 014 // 01с // 020 // 024 // 028 ; // 038 Структура REGION начинается со стандартного 16-байтового заголовка. Как упоминалось в разделе «Структуры данных пользовательского режима», GDI оптимизирует процедуру создания регионов, состоящих из одного прямоугольника, за счет связывания с манипулятором GDI структуры RECT пользовательского режима. Тем самым GDI привязывает объект региона к процессу-создателю. Для поддержания этой связи механизм GDI сохраняет в заголовке идентификатор программного потока, создавшего объект. Структура REGION имеет переменный размер. Она содержит всю информацию о регионе, объем которой может увеличиваться или уменьшаться в результате применения операций к региону. Например, если регион объединяется с другим регионом операцией RGNJ3R, размер структуры обычно увеличивается, а при использовании операции RGN_AND он обычно уменьшается. Чтобы уменьшить количество операций выделения/освобождения, механизм GDI не выделяет блок памяти именно того размера, который необходим для представления региона; вместо этого он выделяет несколько больший блок, позволяющий увеличивать размеры региона без повторного выделения памяти. Вероятно, размер структуры REGION при выделении памяти хранится в поле sizeObj, а фактически используемый размер — в поле sizeRgn.
218 Глава 3. Внутренние структуры данных GDI/DirectDraw В поле rcl хранятся данные прямоугольника, ограничивающего регион. Важнейшими данными в структуре REGION является массив структур SCAN. В поле cScans хранится количество структур в массиве, а поле pscn ссылается на адрес, следующий после конца последней структуры в массиве. Программисты обычно не хранят указатели подобного рода, поскольку они легко вычисляются по начальному адресу, количеству и размеру элементов. Однако здесь интересно заметить, что структура SCAN имеет переменный размер. Она не документирована в Windows NT/2000 DDK, хотя 16-разрядная версия этой структуры документируется в Windows 95 DDK. Структура SCAN содержит информацию об одной «строке развертки» региона, высота которой в системе координат может быть равна одному пикселу (а может быть и не равна). Выражаясь точнее, в SCAN хранится информация о пересечении региона с областью, ограниченной двумя горизонтальными линиями, при условии, что пересечение контура региона с этой областью состоит только из вертикальных отрезков. Механизм GDI делит регион на последовательность структур SCAN в направлении сверху вниз. Поскольку точки пересечения контура региона с верхней и нижней границами SCAN имеют одинаковые координаты х, механизм GDI хранит лишь одну из них. Итак, в структуре SCAN хранятся значения координат у верхней и нижней границы, пары значений координаты х для пересечений и две копии количества пересечений. Следовательно, для сложных регионов (например, имеющих внутренние отверстия) структура SCAN экономит память, необходимую для представления региона. В первом и последнем поле структуры SCAN хранятся две копии количества пересечений. Поскольку размер структуры SCAN переменный, ее последнее поле не имеет фиксированного смещения от начала структуры. Возможно, у вас возник вопрос — почему структуры REGION и SCAN так странно устроены? На это у механизма GDI есть веские причины. Регионы обычно передаются функциям графических драйверов в виде структур CLIP0BJ. Интерфейс DDI не предоставляет доступа к внутренней структуре данных CLIP0BJ; вместо этого он позволяет графическим драйверам перечислить все прямоугольники, образующие регион, при помощи функции CLIPOBJbEnum. Драйвер может указать порядок перечисления прямоугольников при помощи функции CLIPOBJ_cEnumStart. Механизм GDI позволяет производить перечисление слева направо, сверху вниз; справа налево, сверху вниз; слева направо, снизу вверх и т. д. — в любом порядке, удобном для GDI. Поле pscanTail структуры REGION позволяет механизму GDI быстро перейти к последней структуре SCAN. Поле scnPntCount позволяет быстро переходить слева направо или к следующей структуре SCAN при перечислении сверху вниз. Поле scnPntCountToo обеспечивает быстрый переход справа налево или к следующей структуре SCAN при перечислении снизу вверх. В следующем примере демонстрируется связь структуры REGION с регионами, знакомыми нам по Win32 API. При создании региона функцией CreateEllip- ticRgn(0,0,100,100) вы получаете манипулятор региона. Укажите его при вызове команды dr расширения GDI; в отладчике выводится адрес структуры REGION и список всех прямоугольников, образующих регион. Структура REGION содержит 63 структуры SCAN с ограничивающим прямоугольником [0, 0, 99, 99]. В табл. 3.12 приведен сокращенный список элементов массива структур SCAN.
Структуры данных режима ядра 219 Таблица 3.12. Cnt 0 2 2 2 2 2 2 2 0 Массив структур Тор -maxint - 0 1 39 47 52 97 98 99 SCAN - 1 в структуре REGION (для круга) Bottom 0 1 2 47 52 60 98 99 maxint Х[] 47,52 39,60 1,98 0,99 1,98 39,60 47,52 CntToo 0 2 2 2 2 2 2 2 0 Из приведенного примера видно, что структура REGION содержит аппроксимацию исходной фигуры в виде комбинации прямоугольников, задаваемых целочисленными координатами. Следовательно, если создать для региона манипулятор GDI и потом масштабировать его (при помощи функций GetRegionData и ExtCreateRegion с параметром XF0RM), результат будет отличаться от того, который получится при обратной процедуре (предварительном масштабировании математическими методами и последующем создании манипулятора GDI). Структура REGION описывает регион слева направо, сверху вниз. Верхние и левые координаты включаются в регион, а нижние и правые — не включаются. При создании структур REGION GDI старается действовать как можно точнее, поэтому многие структуры SCAN имеют высоту всего в один пиксел. Например, несколько первых и последних структур SCAN для круга соответствуют прямоугольникам высотой в 1 пиксел. Но там, где это возможно, GDI с целью экономии памяти увеличивает SCAN до максимально возможной высоты. Например, центральная часть круга аппроксимируется прямоугольником высоты 5, соответствующей средней структуре SCAN в массиве (координаты от 47 до 52). Для точного представления регионов, не имеющих ярко выраженного прямоугольного строения, размер структуры REGION обычно прямо пропорционален высоте региона и в меньшей степени зависит от ширины региона. Например, при удвоении высоты эллипса размер REGION может вырасти вдвое, а при удвоении ширины размер REGION может вообще не измениться. Количество структур SCAN и размеры REGION напрямую влияют на работу механизма GDI, на использование памяти драйверами устройств и на общее быстродействие, особенно в режимах печати с высоким разрешением на качественных принтерах. В примере из табл. 13.12 следует обратить внимание на первую и последнюю структуры SCAN. Они не соответствуют фрагментам региона, то есть не содержат
220 Глава 3. Внутренние структуры данных GDI/DirectDraw координат х. В сущности, эти структуры утверждают, что в интервалах у = = [maxint - 1,0] и [99, maxint] в системе координат отсутствуют участки, принадлежащие данному региону. Если эти структуры не описывают видимые части региона, зачем же они хранятся в драгоценном адресном пространстве ядра? Ответ — для упрощения реализации и унификации операций с регионами. Например, при инвертировании региона можно обойтись тем же количеством структур SCAN; достаточно включить в каждую структуру SCAN значения -maxint - 1 и maxint в качестве первой и последней координат х. Пустой регион представляется структурой REGION с ограничивающим прямоугольником {0, 0, 0, 0} и единственной структурой SCAN {0, -maxint - 1, maxint, 0}. Вы когда-нибудь замечали, что при вызове функции GDI для создания круглого региона с координатами 0, 0, 100, 100 вам возвращается регион с ограничивающим прямоугольником 0, 0, 99, 99, в который правая и нижняя граница все равно не включаются? Другими словами, CreateEllipticRgn создает фигуру меньших размеров, чем создала бы функция Ellipse. Да, такова суровая реальность Windows. Этот известный дефект, сохранившийся со времен Windows 3.0 до Windows 2000, документируется в MSDN Win32 SDK (статья Q83807). Структура REGION остается закрытой как для прикладных программистов в Win32 API, так и для программистов драйверов устройств в интерфейсе DDL Единственной низкоуровневой структурой региона, которую можно получить в Win32 API, является структура RGNDATA, используемая функциями GetRegionData и ExtCreateRegion. В RGNDATA вместо массива SCAN присутствует массив прямоугольников. В интерфейсе DDI используется абстрактная структура CLIP0BJ. Для получения прямоугольников, образующих регион, необходимо вызвать функцию CLIP0BJ_bEnum. Траектории в механизме GDI Траектория (path) представляет собой совокупность фигур (или геометрических форм), к которой применяются операции заливки, обводки или заливки с одновременной обводкой. Для создания траектории можно воспользоваться средствами Win32 API, однако вы даже не получите манипулятора созданного объекта. Любой нормальный программист понимает, что для представления траектории в процессе построения и при последующем использовании в GDI требуется какая-то внутренняя структура данных. Графический механизм Windows (win32k.sys) даже экспортирует довольно большую группу функций для выполнения операций с объектами траекторий в драйверах устройств. По данным расширения отладчика GDI, объекты траекторий присутствуют в таблице объектов GDI. Команда dumpobj PATH выводит информацию обо всех объектах траекторий в системе. Расширение отладчика GDI не содержит команд для расшифровки манипулятора объекта траектории или соответствующей структуры данных режима ядра (в этом отношении траектории также отличаются от других типов объектов GDI). Команда dpo расшифровывает только структуру PATH0BJ, передаваемую функциям механизма GDI или функциям драйверов устройств — например, EngStrokePath или DevStrokeAndFi 11 Path. Приведенная ниже информация о структурах данных, представляющих траектории в механизме GDI, была получена с использованием нескольких тесто-
Структуры данных режима ядра 221 вых объектов траекторий, а также документации Win32 API и DDK. Основной структуре было присвоено имя PATH. // Windows 2000. переменный размер typedef struct _PATHDT PATHDT * _PATHDT * unsigned unsigned POINTFIX } PATHDT; pNext; pLast; flags; pointno; point[l]; // 000 // 004 // 008 // 00c // 010 // Windows 2000, переменный размер typedef struct i unsigned void * unsigned PATHDT } PATHDEF; unk_00; pTail; nAllocSize; pathdt[l]; // Windows 2000. ? байт typedef struct i HGDIOBJ void * ULONG ULONG PATHDEF * SEGMENT * PATHDT * PATHDT * RECTFX POINTFX ULONG unsigned } PATH; hHmgr; pentry; cExcLock; Tid; ppachain; pFirst; ppfirst; pplast; rcfxBoundBox; ptfxSubPathStart: nCurves: unk_38[10]; // 000 // 004 // 008 // 010 // 000. заголовок объектов GDI режима // 004 // 008 // 00c // 010 // 014 // 014 // 018 // 01c // 02c // 034 // 038 ядра Структура PATH в отличие от структуры REGION имеет фиксированный размер. Она начинается со стандартного 16-байтового заголовка, за которым следует указатель (ppachain) на структуру PATHDEF с реальным определением траектории. Как говорилось выше, траектория представляет собой совокупность фигур; ее внутреннее представление PATHDEF представляет собой список структур PATHDT, каждая из которых описывает одну часть фигуры, образующей траекторию. В структуре PATH хранятся указатели на первую и последнюю структуры PATHDT в списке (поля pprfirst и pprlast). Кроме того, в структуру PATH включены данные ограничивающего прямоугольника и начальная точка траектории. Как уже упоминалось, координаты устройства хранятся в виде 32-разрядных значений с фиксированной точкой, в отличие от интерфейса Win32 API, использующего 32-разрядные числа со знаком. Примером служит структура PATH. И ограничивающий прямоугольник, и начальная точка представлены 32-разрядными числами в формате с фиксированной точкой. Старшие 28 бит из 32 обра-
222 Глава 3. Внутренние структуры данных GDI/DirectDraw зуют целую часть, а младшие 4 бита — дробную. Например, число 1 в этой записи представляется в виде 0x10, а число 1.125 — в виде 0x12. Microsoft называет этот формат «FIX-координатами» или дробными координатами (fractional coordinates). Система дробных координат позволяет задавать координаты на поверхности устройства с точностью до 1/16 пиксела. FIX-коор- динаты используются при определении линий и кривых Безье, являющихся базовыми компонентами траекторий. В результате точность вычислений повышается без затрат, связанных с применением операций с плавающих точкой. Структура PATHDEF имеет переменный размер и содержит все структуры PATHDT, входящие в траекторию. В поле nAllocSize сохраняется размер текущего блока, а поле pTail ссылается на первый свободный байт. По значениям этих полей можно легко узнать о том, что выделенная для траектории память подходит к концу. После этих полей следует серия структур PATHDT, образующих двусвяз- ный список. Структура PATHDT представляет группу точек на кривой, обладающих некоторыми общими атрибутами. Поле pNext каждой структуры указывает на следующую структуру PATHDT в списке или равно NULL для последней структуры в списке. Поле pStart указывает на предыдущую структуру PATHDT или равно NULL для первой структуры в списке. В поле f 1 ags хранятся общие атрибуты точек. Флаги, используемые в этом поле, документируются в Windows NT/2000 DDK при описании структуры PATHDATA (табл. 3.13). Таблица 3.13. Флаги PATHDT PATHDT.flags Значение Описание PDBEGINSUBPATH 0x0001 Первая точка начинает новую субтраекторию (фигуру) PDENDSUBPATH 0x0002 Последняя точка завершает субтраекторию (фигуру) Сбросить стиль в начале новой субтраектории Добавить линию, соединяющую последнюю точку субтраектории (фигуры) с первой точкой 0x0010 Группы из трех точек описывают кривую Безье, а не сегмент линии PD_RESETSTYLE 0x0004 PD CL0SEFIGURE 0x0008 PD BEZIERS Итак, траектория является объектом GDI, как регион или DDB. Перед использованием объектов GDI при вызове графических функций их необходимо выбрать в контексте устройства. Траектории, в отличие от других объектов GDI, не имеют специальной функции выбора — они неявно выбираются при создании. В момент создания новой траектории старая траектория в контексте устройства уничтожается. Впрочем, механизм GDI все равно должен хранить манипуляторы траекторий для разных контекстов, поэтому манипулятор объекта траектории для заданного контекста устройства хранится в поле hpath структуры DEVLEVEL. За этим полем также следует поле флагов, flPath, и структура LINEATTRS для описания атрибутов линии.
Структуры данных режима ядра 223 Рассмотрим пример — небольшой фрагмент кода Win32, в котором создается траектория: const POINT Points[3] - { {200.50}. {250. 150}. {300. 50} }; BeginPath(hDC); MoveToEx(hDC. 100. 100. NULL); LineTo(hDC. 150. 150); PolyBezierTo(hDC. & POINTSL0]. 3); EndPath(hDC); При помощи расширения отладчика GDI можно провести поиск всех объектов траекторий в системе. Воспользуйтесь командой dumpobj PATH, а затем введите команду dt <MaHunyjmmop_GDI>, чтобы вывести элемент таблицы объектов GDI, соответствующий конкретному манипулятору. Из выходных данных команды берется указатель на структуру PATH, содержащую указатель на структуру PATHDEF. Структура PATHDEF определяется следующим образом: // Пример структуры PATHDEF 0000: unkJO 0x00000000' 0004: pTail & pathdt[2] 0008: nAllocSize Oxfc 000c: pathdt[0] & pathdt[l]. NULL. 5. 2. 100.0. 100.0. 150.0. 150.0 0014: pathdt[l] NULL. & pathdt[0]. 0x12. 3 200.0. 50.0. 250.0. 150.0. 300.0. 50.0 0054: pathdt[2] Механизм GDI выделил для хранения траектории блок из 4032 байт (OxfcO), в котором в настоящий момент занято только 84 (0x54) байта. Для будущего роста этой траектории остается еще достаточно места. В структуре PATHDEF хранятся две структуры PATHDT, объединенные в двусвязный список. Первая структура PATHDT состоит из двух точек с флагами PDBEGINSUBPATH | PDRESETSTYLE. Итак, перед нами две точки, образующие отрезок. Вторая структура PATHDT состоит из трех точек с флагами PDENDSUBPATH | PDBEZIERS. Она описывает одну кривую Безье, которая продолжается из предыдущей точки и завершает субтраекторию. Структура PATHDEF точно воспроизводит все параметры, указанные в коде Win32. Теперь мы знаем, что структура PATH позволяет представить отрезки и кривые Безье, а также их произвольные комбинации. Например, вызовы функций CloseFigure, LineTo, MoveToEx, PolyBezier, PolyBezierTo, Polygon, PolylineTo, PolyPolygon и PolyPolyline легко преобразуются в последовательности отрезков и кривых Безье. С другой стороны, Windows 95/98 позволяет включать в построение траекторий вызовы TextOut и ExtTextOut. Как в структуре PATH представляется текст? Оказывается, при построении траекторий можно использовать только шрифты TrueType, и в траектории записываются только контуры текстовых строк, которые фактически представляют собой кривые Безье. Кроме перечисленных функций Windows NT/2000 позволяет включать в траекторию эллиптические кривые. Например, при построении траектории можно использовать функции AngleArc, Arc, АгсТо, Ellipse, Pie и т. д. Как механизм GDI решает эту задачу? Эллиптические кривые разбиваются на последовательности кривых Безье по аналогии с тем, как непрямоугольные регионы разбиваются на
224 Глава 3. Внутренние структуры данных GDI/DirectDraw группы строк развертки. Предположим, перед вызовом EndPathO в приведенный выше фрагмент включаются две дополнительные команды: CloseFigure(hDC); Ellipse(hDC. -100. -100. 100. 100); Функция CloseFigureO завершает вторую структуру PATHDT (см. выше). Функция EllipseO добавляет в список еще одну структуру PATHDT — группу кривых Безье из 13 точек. Первая точка начинает новую фигуру, а остальные 12 точек образуют 4 кривых Безье. Механизм GDI аппроксимирует эллипс при помощи 4 кривых Безье. Определения 13 контрольных точек выглядят следующим образом: { 99. -0.5 }. { 99. -55.4375 }. { 54.5. -100 }. { -0.5. -100 }. { -55.5. -100 }. { -100. -55.4375 }. { -100. -0.5 }. {-100. 54.4375 }. { -55.5. 99 }. { -0.5. 99 }. { 54.5. 99 }. { 99. 54.4375 }. { 99. -0.5 }. Становится понятно, почему в структуре PATH используются FIX-коорди- наты. Округление координат до целых чисел приведет к искажению формы эллипса. Структура PATH используется не только для хранения траекторий в Win32 GDI. Она также играет очень важную роль в DDI (интерфейсе между механизмом GDI и драйверами графических устройств). В частности, вызовы функций рисования линий (такие, как LineTo и PolyBezier) преобразуются в вызовы функции DrvStrokePath, которой передается указатель на структуру PATH0BJ. Функции с заливкой областей (например, Ellipse и Polygon) преобразуются в вызовы функции DrvStrokeAndFi 11 Path, которой также передается указатель на PATH0BJ. По сравнению с Windows NT 4.0 в Windows 2000 добавилась новая точка входа DrvLineTo, повышающая быстродействие для вызовов LineTo с целочисленными координатами конечных точек. Структура PATH0BJ также относится к числу «замаскированных» структур DDI и содержит только два открытых поля. Вы можете воспользоваться функциями GDI для получения информации о компонентах траектории, построения новых траекторий или расширения траектории посредством включения новых кривых. Например, функция EngCreatePath создает новый объект PATH0BJ; функция PATH0BJ_ bPolyBezier включает в траекторию кривые Безье; функция PATHOBJbEnum перечисляет записи компонентов траектории в структуре PATHDATA, очень похожей на описанную выше структуру PATHDT. Шрифты в механизме GDI То что в Win32 API обычно именуется шрифтами (fonts), правильнее было бы называть «логическими шрифтами». Логические шрифты создаются функциями CreateFont, CreateFontlndirect и CreateFontDirectEx. При вызове функции указываются характеристики, которыми должен обладать шрифт. GDI (а точнее — система подстановки шрифтов, font mapper) находит физический шрифт, в наибольшей степени соответствующий предъявленным требованиям.
Структуры данных режима ядра 225 Для ссылок на логические шрифты, создаваемые GDI, используются манипуляторы типа HF0NT. В расширении отладчика GDI объекты шрифтов обозначаются типом LF0NT. Например, команда dumpobj LF0NT выводит список манипуляторов всех логических шрифтов в системе. Передавая манипулятор логического шрифта команде he! f, вы получите информацию о структуре данных, ассоциированной с этим манипулятором в адресном пространстве ядра. Команда просто выводит дамп соответствующей структуры L0GF0NTW. // Windows 2000. ? байт typedef struct г i HGDIOBJ void * ULONG ULONG unsigned PDEV_WIN32K * unsigned HGDIOBJ unsigned WCHAR unsigned hHmgr; pentry; cExcLock; Tid; unk_010[3]; ppdev; unk 020[8]: hPFE; unk 020[39]: Face[32]; nSize; ENUMLOGFONTEXW enumlogfontex; // // // // // // // // // // // // } LFONT; На самом деле данные, хранимые в пространстве ядра для логических шрифтов, отнюдь не ограничиваются структурой L0GF0NTW, показываемой расширением GDI. Даже функция GetObject возвращает для манипулятора логического шрифта структуру из 356 байт, больше напоминающую структуру ENUMLOGFONTEXW. Ее первым полем действительно является структура L0GF0NTW. Другое поле, заслуживающее внимания, — указатель на структуру физического устройства механизма GDI. Следовательно, в механизме GDI структура LF0NT, поддерживаемая для логического шрифта, фактически представляет собой структуру L0GF0NTW с несколькими дополнительными полями, образующими структуру ENUMLOGFONTEXW, что вполне разумно. Но где же хранится информация о соответствии между логическими и физическими шрифтами? И как информация о шрифтах передается функциям драйверов графических устройств — например, DrvTextOut? Расширение отладчика GDI показывает еще одну недокументированную структуру данных GDI — PFE. Манипулятор структуры PFE хранится в поле hPFE каждой структуры LF0NT. Вы можете получить список всех манипуляторов PFE при помощи команды dumpobj PFE расширения отладчика GDI, а затем воспользоваться командой pfe для получения информации о структуре ядра PFE. Структура ядра PFE выглядит следующим образом: // Windows 2000, 108 (0x6с) байт struct PPF; typedef struct { HGDIOBJ hHmgr; // 000. заголовок объектов GDI режима ядра 000. заголовок объектов GDI 004 008 00с 010 01с 020 040 044 0d0 110 114
226 Глава 3. Внутренние структуры данных GDI/DirectDraw void * ULONG ULONG PFF * ULONG ULONG pentry; cExcLock: Tid; pFFF; i Font; ЛРРЕ; FD_GLYPHSET * pfdg; void * IFIMETRICS * unsigned void * unsigned unsigned unsigned unsigned void * unsigned unsigned unsigned unsigned unsigned unsigned void * unsigned unsigned unsigned PFE: unk__020; pifi: idifi; pkp; idkp; ckp; iOrientation; cjEfdwPFE; pgiset; ulTimeStamp; ufi: unk J)4c; pid; ql: unk_058; pFlEntry; cAlt: cPfdgRef; aiFamilyName; // // // // // // // // // // // // // // // // // // // // // // 004 008 00c 010. pff 014 018 01c. gs 020 f8dd( 024. ifi 028 02c 030 034 038 03c 040 044 048 04c 050 054 058 // 05c // // // 060 064 068 Структура PFE начинается со стандартного заголовка объектов GDI длиной 16 байт. Поле pPFF ссылается на структуру PFF, содержащую информацию о физическом файле шрифта. Структура PFF описывается ниже в этом разделе. В поле pfdg хранится указатель на структуру FDGLYPHSET, документированную в SDK. Структура FD_GLYPHSET определяет отображение символов Unicode на внутренние манипуляторы глифов. Символы Unicode представляются 16-разрядными значениями. Кодировка Unicode поддерживает тысячи разнообразных символов, а шрифты могут ограничиваться небольшим подмножеством этой кодировки. Шрифт представляет собой совокупность глифов, каждому из которых присвоен уникальный манипулятор. При помощи структуры FDGLYPHSET механизм GDI устанавливает соответствие между символами Unicode и манипуляторами глифов. В расширении отладчика GDI предусмотрена команда gs для расшифровки структуры FDGLYPHSET. Например, для шрифта Small Fonts (smallf.fon) эта команда показывает, что шрифт состоит из 224 глифов. Глифу символа «пробел» соответствует манипулятор 0, глифу символа «А» — манипулятор 0x21 и т. д. Структура FDGLYPHSET создается точкой входа шрифтового драйвера DrvQuery- FontTree, Когда параметр iMode равен QFTGLYPHSET. Также обратите внимание на поле pifi, в котором хранится указатель на структуру IFIMETRICS, также документированную в DDK. Структура IFIMETRICS содержит сведения о гарнитуре, используемые GDI. В частности, в ней хранятся имена семейства, стиля и гарнитуры, уникальное имя, возможности эмуляции, идентификатор внедрения и, наконец, 10-байтовый массив panose с описанием визуальных характеристик шрифта. Структура IFIMETRICS заполняется функци-
Структуры данных режима ядра 227 ей DrvQueryFont. В расширении отладчика GDI предусмотрена команда ifi, предназначенная для расшифровки структуры IFIMETRICS. Например, для шрифта Small Fonts команда возвращает информацию о растровом формате 1 бит/пиксел, о возможности масштабирования с целочисленным коэффициентом и поворотах на 90°, а также об эмуляции полужирного, курсивного и полужирного курсивного начертаний. Логический шрифт связывается с конкретным процессом Win32. При уничтожении процесса все его манипуляторы GDI уничтожаются, а элементы таблицы объектов освобождаются для повторного использования. Однако манипуляторы PFE существуют на уровне системы и не ассоциируются с конкретными процессами. С одной структурой PFE может быть связано несколько логических шрифтов. Структура PFF описывает файл физического шрифта. Как нетрудно предположить, в расширении GDI также имеется команда pff для расшифровки этой структуры. Определение структуры PFF выглядит так: struct RF0NT; typedef struct _PFF ULONG PFF * PFF * WCHAR * ULONG ULONG unsigned ULONG ULONG ULONG ULONG RFONT * void * void * unsigned void * void * void * void * ULONG unsigned ULONG void * void * unsigned PFE * WCHAR PFF; sizeofThis; pPFFNext: pPFFPrev; pwazPathName cwc; cFiles; unk_018[2]; flState; cLoaded; cNotEnum; cRFONT; prfntList; hff; hdev; dhpdev; pfhFace; pfhFamily; pfhUFI; pPFT; ulChecksum!; unk_054; cFonts; ppfv; pPvtDataHead; unk 064; pPFE; wszStrings[l]; // // // // // // // // // // // // // // // // // // // // // // // // // // // 000 004. 008. 00c 010 014 018 020 024 028 02c 030. 034 038 03c 040 044 048 04c. 050 054 058 05c 060 064 068. 06c pff pff fo pft pfe } Структуры PFF в механизме GDI объединяются в двусвязные списки. Ссылки на следующий и предыдущий элементы хранятся соответственно в полях pPFFNext и pPFFPrev. Следующее поле содержит указатель на имя файла шрифта на дис-
228 Глава 3. Внутренние структуры данных GDI/DirectDraw ке - например, «\??\C:\WIN2000\FONTS\SMALLF.FON», для которого в поле fl State установлен флаг PFFSTATEPERMANENTFONT. В поле cLoaded хранится признак, который показывает, был ли файл загружен в память; в поле cRFONT хранится количество реализованных шрифтов, созданных на основании физического шрифта, а поле prfntList ссылается на первый элемент списка реализованных шрифтов. Поле pPFT содержит указатель на структуру PFT, которая представляет собой таблицу структур PFF. Структура PFT расшифровывается командой pft и выглядит следующим образом: typedef struct { void * pfhFamily; void * pfhFace; void * pfhUFI; ULONG cBuckets; ULONG cFiles; PFF * apPFF[l]: // 000 // 004 // 008 // 00c // 010 // 014 } PFT: В первых трех полях структуры PFT хранятся указатели на три хэш-таблицы, расшифровываемые командой f h. Хэш-таблицы предназначены для быстрого установления соответствия между логическими и физическими шрифтами. В структуре PFT данные шрифтов сохраняются в хэш-таблице, рассчитанной, как показывают эксперименты, на 100 элементов. В структуре PFT сохраняется указатель на первую структуру PFF в двусвязном списке, создаваемом при помощи двух ссылочных полей структуры PFF. В поле cFiles хранится общее количество шрифтовых файлов, объединенных в структуре PFT. Механизм GDI создает три таблицы структур PFF — для открытых шрифтов, для закрытых шрифтов и для шрифтов устройств. Указатели на эти таблицы хранятся ^ трех глобальных переменных — win32k!gpPFTPublic (открытые шрифты), win32k!gpPFTPrivate (закрытые шрифты) и win32k!gpPFTDevice (шрифты устройств). В расширении отладчика GDI эти переменные используются в работе трех команд, отображающих содержимое трех таблиц: pubft, pvtft и devft. Список шрифтов, выводимый по команде pubft, выглядит примерно так: apPFF[2] "\??\C:\WIN2000\FONTS\TREUCBD.TTF" "\??\C:\WIN2000\FONTS\CGA80W0A.FON" apPFF[3] "\??\C:\WIN2000\FONTS\MICROSS.TTF" apPFF[5] ,,\??\C:\WIN2000\FONTS\PALA.TTF" apPFF[98] "\??\C:\WIN2000\FONTS\TIMES1.TTF" Настало время описать самую важную шрифтовую структуру графического драйвера, FONTOBJ, и ее расширенную версию RF0NT. Выше говорилось о fOM, что структура LF0NT описывает логический шрифт, то есть запрос на получение шрифта с заданным размером и углом поворота, особыми характеристиками (например, насыщенностью) и т. д. С другой стороны, шрифтовой файл, описываемый структурой PFF, представляет собой общий шаблон, который может масштабироваться для разных размеров, поворачиваться на разные углы и дополняться другими специфическими возможностями. В простейшем варианте для каждого символа текстовой строки механизм GDI обращается к шрифтовому драйверу за описа-
Структуры данных режима ядра 229 нием общего контура символа, масштабирует его до нужного размера, поворачивает на нужный угол, преобразует в растр, использует и забывает о его существовании. Однако в общем случае такая схема крайне неэффективна, особенно если учесть, что для однобайтовых шрифтов с небольшим количеством символов легко организуется кэширование, экономящее массу времени по многократному построению растров для каждого шрифта. Для этого в механизме GDI используется структура RF0NT. Структура RFONT описывает конкретную реализацию или, если хотите, — конкретный экземпляр шрифта. Это не логический и не физический шрифт, а набор глифов, созданных в соответствии с требованиями логического шрифта на основании общего описания, взятого из шрифтового файла. Первая часть структуры RF0NT документируется в DDL как структура FONTOBJ, это сделано для ускорения обращений со стороны графических драйверов. К остальным полям структуры RF0NT можно обращаться только посредством специальных методов структуры FONTOBJ - таких, как F0NT0BJ_cGetG1yphHandles и FONTOBJ_cGetGlyphs. В расширении отладчика GDI расшифровка структуры RF0NT выполняется при помощи команды fo. Ниже приведено объемистое определение структуры RF0NT. typedef struct i void * void * void * void * ULONG ULONG ULONG ULONG ULONG ULONG void * void * void * void * void * void * void * ULONG ULONG ULONG } CACHE; pgdNext; pgdThreshold; pjFirstBlockEnd pdblBase; cMetrics; cjbbl; cBlocksMax; cBlocks; cGlyphs; cjTotal; pbblBase; pbblCur; pgbNext; pgbThreshold; pjAuxCacheMem; cjGlyphMax; bSmal1 Metrics; iMax; iFirst; cBits; struct RFONT { FONTOBJ ULONG ULONG ULONG PVOID ULONG PVOID DHPDEV PFE * f Ob j ; iUnique; Л Type; ulContent; hdevProducer; hDeviceFont; hdevConsumer; dhpdev; ppfe: // 000 // 02c // 030 // 034 // 038 // 03c // 040 // 044 // 048
230 Глава 3. Внутренние структуры данных GDI/DirectDraw PFF * FD XF0RM ULONG MATRIX ULONG FLOATOBJ FLOATOBJ ULONG MATRIX ULONG unsigned MATRIX ULONG POINT POINT POINT POINT ULONG FIX FIX FIX pointFX pointFX ULONG LONG LONG ULONG ULONG FD XFORM LONG LONG LONG LONG ULONG FLOATOBJ FLOATOBJ FLOATOBJ LONG FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ FLOATOBJ ULONG ULONG ULONG void * void * ULONG RFONT * RFONT * RFONT * ppff; fdx; cBitsPerPel; mxWorldToDevice; iGraphicsMode; eptflNtoWScale_x_i; eptflNtoWScale у i; bNtoWIdent: xoForDDI__pmx; xoForDDI_ulMode; unk_000: mxForDDI; flRealizedType: pt1 Underlined ptlStrikeOut; ptIULThickness; ptlSOThickness; ICharlnc; fxMaxAscent; fxMaxDescent; fxMaxExtent: ptfxMaxAscent; ptfxMaxDescent; cxMax; IMaxAscent; IMaxHeight; cyMax; cjGlyphMax; fdxQuantized; // 04c // 050 // 060 // 064 // OaO // 0a4 // Oac // 0b4 // 0b8 // Obc // OcO // 0c4 // 100 // 104 // 10c // 104 // 10c INonLinearExtLeading; INonLinearlntLeading; 1NonLi nearMaxCharWi dth; 1NonLi nea rAvgCha rWi dth; ulOrientation; pteUnitBase_x; pteUnitBasely; efWtoBase; 1 Ascent; pteUnitAscent_x; pteUnitAscent_y; efWtoDAscent; efDtoWAscent; efWtoDEsc: efDtoWEsc; efEscToBase; ef EscToAscent; Л Info; hgBreak; fxBreak; pfdg; wcgp; cSelected; rflPDEV prfntPrev; rflPDEV_prfntNext; rflPFF_prfntPrev;
Структуры данных DirectDraw 231 RFONT * void * CACHE POINT ULONG FLOATOBJ FLOATOBJ TEXTMETRICW LONG LONG LONG ULONG ULONG RFONT * RFONT * RFONT * void * void * ULONG ULONG ULONG ULONG ULONG ULONG rflPFF_prfntNext; hsemCache; cache; ptlSim; bNeededPaths; efDtoWBaseJl: efDtoWAscent_31; * ptmw; IMaxNegA; IMaxNegC; IMinWidthD; blsSystemFont; flEUDCState: prfntSystemTT; prfntSysEUDC; prfntDefEUDC; paprfntFaceName; aprfntQuickBuff[8]: bFilledEudcArray; ulTimeStamp; uiNumLinks; bVertical; pchKernelBase; iKernel Base; }: При виде такой сложной структуры данных можно не сомневаться в том, что \ механизм GDI делает все возможное для оптимизации вывода текста. Другие объекты GDI в механизме GDI Итак, мы рассмотрели структуры данных, представляющие основные объекты GDI в адресном пространстве ядра. В частности, были описаны структуры данных для контекста устройства, аппаратно-независимого растра, DIB-сек- ции, кисти, пера, палитры, региона, траектории, логического шрифта, физического и реализованного шрифтов. В выходных данных команды dumphmgr расширения отладчика GDI упоминаются и другие типы объектов — например, DD_DRAWJYPE, CLIOBJJTYPE и SP00LJYPE. Объекты, относящиеся к DirectDraw, описаны в следующем разделе. Другие объекты в этой главе не рассматриваются, поскольку они либо не играют особой роли для программирования Win32, либо устарели с развитием ОС Windows, либо мы не располагаем средствами для создания их экземпляров. Вскоре вы убедитесь, что знание внутренних структур данных GDI помогает глубже понять программирование для Win32 GDI API. Структуры данных DirectDraw «Дайте мне манипулятор, и я покажу вам структуру данных». Собственно, именно эта задача и решалась в данной главе применительно к объектам GDI. Мы выяснили, что в системе существует глобальная таблица объектов GDI, что GDI
232 Глава 3. Внутренние структуры данных GDI/DirectDraw создает для некоторых объектов структуры данных в адресном пространстве пользовательского режима, и для всех объектов создаются структуры данных, которые механизм GDI хранит в адресном пространстве режима ядра. При помощи расширения отладчика GDI мы постепенно исследуем недокументированные связи между GDI и DDI. А теперь перейдем к DirectDraw — API эпохи COM (Component Object Model). При создании объекта DirectDraw или поверхности DirectDraw вместо манипуляторов (скажем, HDIRECTDRAW или HDIRECTSURFACE) вам предоставляются интерфейсные указатели LPDIRECTDRAW и LPDIRECTDRAWSURFACE. Что с ними делать? С концептуальной точки зрения СОМ-интерфейс представляет собой группу семантически связанных функций, обеспечивающих доступ к объекту СОМ. На уровне реализации СОМ-интерфейс представляется таблицей виртуальных функций, содержащей адреса семантически связанных функций. Интерфейсный указатель СОМ обычно определяется как указатель на СОМ-интерфейс. На самом деле интерфейсный указатель СОМ ссылается на объект (то есть на экземпляр класса) СОМ. Рассмотрим пример создания объекта СОМ для DirectDraw: HRESULT DirectDrawTest (HWND hWnd) { LPDIRECTDRAW Ipdd; HRESULT hr = DirectDrawCreate(NULL. & Ipdd. NULL); if ( hr — DD_0K) { lpdd->SetCooperativeLevel(hWnd. DDSCL_NORMAL); DDSURFACEDESC ddsd; ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps - DDSCAPS_PRIMARYSURFACE; LPDIRECTDRAWSURFACE Ipddsprimary; hr = lpdd->CreateSurface(&ddsd. &lpddsprimary. NULL); if ( hr — DD_0K) { char mess[MAX_PATH]; wsprintf(mess. "DirectDraw object at %x. vtable at JHx\n". "DirectDraw surface object at %x. vtable at %x", Ipdd. * (unsigned *) Ipdd. Ipddsprimary. * (unsigned *) Ipddsprimary); MessageBox(NULL. mess. "DirectDrawTest". MB_0K); lpddsprimary->Release(); } lpdd->Release(); } return hr; }
Структуры данных DirectDraw 233 Приведенный фрагмент создает объект DirectDraw и объект поверхности DirectDraw, а затем выводит их адреса и указатели на таблицы виртуальных функций. Если вставить фрагмент в программу и выполнить его, на экране появляется окно сообщения с текстом следующего вида: DirectDraw object at 7e2al0. vtable at 728405a0 DirectDraw surface object at 7e3b58. vtable at 72840940 Если программа была запущена в отладчике, можно убедиться в том, что объекты создаются из кучи в пользовательском адресном пространстве, а указатели на таблицы виртуальных функций относятся к модулю реализации DirectDraw ddraw.dll. После нескольких минут поисков можно найти адреса функций в виртуальных таблицах и их символические имена. Например, фрагмент таблицы виртуальных функций объекта DirectDraw выглядит так: 7298Е8А4: ddraw.dll!DD_QueryInterface 7298ЕВ48: ddraw.dll!DD_AddRef 7298EC16: ddraw.dll!DD_Release 72980C5A: ddraw.dll!DD_Compact 7297C82B: ddraw.dll!DD_CreateClipper Уловили? Принцип использования адресов и таблиц функций в СОМ очень похож на интерфейс DDI между механизмом GDI и графическими драйверами, хотя он в значительно большей степени формализован. Теперь давайте посмотрим, как DirectDraw отражается в таблице объектов GDI. Для этого мы воспользуемся верным расширением отладчика GDI под управлением нашей собственной программы Fosterer. Дважды выполните команду dumpdd — перед выполнением приведенного выше фрагмента и когда окно сообщения находится на экране (то есть когда объекты DirectDraw еще не освобождены). Результат предугадать нетрудно — мы обнаруживаем два новых типа объектов, DDDIRECTDRAWJTYPE и DD_SURFACE_TYPE. При реализации DirectDraw в GDI все равно используются манипуляторы, хотя и скрытые интерфейсными указателями. Очевидно, DDDIRECTDRAWTYPE соответствует объекту DirectDraw, a DD_SURFACE_ TYPE — объекту поверхности DirectDraw. Начнем с рассмотрения объекта DirectDraw. Список всех объектов DirectDraw выводится командой dumpddobj DDRAW. Структура данных режима ядра расшифровывается командой dddlocal, которая выводит имя структуры — EDDDIRECTDRAWLOCAL. Механизм GDI различает глобальную структуру данных DirectDraw и структуру данных DirectDraw, существующую на уровне процесса. Ниже приведено определение структуры EDDDIRECTDRAWLOCAL. // Windows 2000. 72 байта typedef struct { HGDIOBJ hHmgr; // 000, заголовок GDI void * pentry; // 004 ULONG cExcLock; // 008 ULONG Tid; // 00c EDD_DIRECTDRAW_GLOBAL * peDirectDrawGlobal; // 010 EDDJHRECTDRAWJ3L0BAL * peDirectDrawGlobal2: // 014
234 Глава 3. Внутренние структуры данных GDI/DirectDraw EDD_SURFACE * unsigned EDD DIRECTDRAW LOCAL * FLATPTR FLONG HANDLE PEPROCESS unsigned void * unsigned peSurface Ddlist: unk_01c[2]; peDi rectDrawLocalNext; fpProcess; fl: UniqueProcess; Process; unk_038[2]; unk_040: unk_044; // 018 // 01c // 024 // 028 // 02c // 030 // 034 // 038 // 040 // 044 } EDD_DIRECTDRAW_LOCAL; В поле UniqueProcess структуры EDD_DIRECTDRAW_LOCAL хранится идентификатор процесса. Поле Process содержит указатель на объект ядра, связанный с процессом. Более того, объект DirectDraw связывается с создавшим его потоком через поле Tid (в отличие от большинства объектов GDI, у которых поле Tid обычно равно 0). Механизм GDI также поддерживает один экземпляр глобальной структуры данных EDD_DIRECTDRAW_GLOBAL, управляющей глобальной информацией состояния DirectDraw. В EDDDI RECTDRAWLOCAL указатели на эту структуру встречаются дважды. Как правило, один процесс DirectDraw создает несколько поверхностей DirectDraw. Объекты ядра этих поверхностей объединяются в односвязный список, начинающийся с поля peSurface_DdList. Все объекты DirectDraw, в данный момент существующие в системе, также связываются в список при помощи поля peDi rectDrawLocal Next. Структура EDD_DIRECTDRAW_LOCAL стоит во главе иерархии всех объектов процесса, относящихся к DirectDraw, а также содержит ссылки на другие глобальные объекты из семейства DirectDraw. Сетевая иерархия структур DirectDraw позволяет координировать их работу. Структура EDDD IRECTDRAWGLOBAL расшифровывается командой dddglobal. Ее определение выглядит следующим образом: // Windows 2000. 476 (OxlDC) байт typedef struct { HDEV unsigned SPRITE * SPRITE * SURFOBJ * unsigned FLONG ULONG unsigned SPRITESCAN void * SURFOBJ unsigned REGION * unsigned } SPRITESTATE: hdev; unk_004; pListZ; pListY; psoScreen: unk_014[9]; flOriginalSurfFlags; iOriginalType; unk_040[5]; * pRange: pRangeLimit; psoComposite; unk_060[66]; prgnUnlocked: unk_16c[28]: // 0x000 // 0x004 // 0x008 // 0x00c // 0x010 // 0x014 // 0x038 // 0x03c // 0x040 // 0x054 // 0x058 // 0x05c // 0x060 // 0x168 // 0x16c // Windows 2000. 1552 (0x610) байт
Структуры данных DirectDraw 235 typedef struct { void * DWORD DWORD unsigned LONG unsigned LONGLONG DWORD VIDEOMEMORY * DWORD DWORD * DD_HALINFO unsigned DD CALLBACKS DD SURFACECALLBACKS DD_PALETTECALLBACKS unsigned D3DNTHAL_CALLBACKS unsigned D3DNTHAL_CALLBACKS2 unsigned dhpdev; dwReservedl; dwReserved2; unk_00c[3]; cDriverReferences; unk_01c[3]; 11 AssertModeTimeout; dwNumHeaps; pvmList: dwNumFourCC; pwdFourCC; ddhalinfo; unkje0[44]; ddcallbacks: ddsurfacecallbacks; ddpalettecall backs: unk_314[48]; d3dnthalcall backs; unk_460[7]; d3dnthalcallbacks2; unk 498[18]; DD_MISCELLANEOUSCALLBACKS ddmiseel 1aneouscal1 backs unsigned D3DNTHAL_CALLBACKS3 unsigned EDD DIRECTDRAWLOCAL * EDD SURFACE * FLONG ULONG PKEVENT EDD SURFACE * EDD SURFACE * BOOL unsigned RECTL HDEV unsigned unk_4ec[18]; d3dnthalcallbacks3; unk_54c[23]; peDi rectDrawLocalLi st; peSurface LockList; fl; cSurfaceLocks; pAssertModeEvent; peSurfaceCurrent; peSurfacePrimary; bSuspended; unk_5c8[12]; rcBounds; hdev; unk_60c; // II II II II 0x000 0x004 0x008 0x00c 0x018 II 0x01c II II II II 0x028 0x030 0x034 0x038 II 0x03c II II II II II II II II II II II II II II II II II II II II II II II II II II 0x040 OxleO 0x290 0x2c4 0x304 ? 0x314 0x3d4 0x460 0x47c 0x498 0x4e0 0x4ec 0x534 0x54c 0x5a8 0x5ac 0x5b0 0x5b4 0x5b8 0x5bc 0x5c0 0x5c4 0x5c8 0x5f8 0x608 0x60c } EDD_DIRECTDRAW_GLOBAL; Структура EDDDIRECTDRAWGLOBAL содержит практически всю информацию о поддержке DirectDraw, которую должен знать механизм GDI. В поле dhpdev хранится манипулятор структуры PDEV драйвера устройства, возвращаемый при вызове DrvEnablePDEV. Обычно он представляет собой указатель на закрытую структуру данных физического устройства. В структуру EDD_DIRECTDRAW_GLOBAL включается несколько других структур, полученных механизмом GDI от драйвера экрана. Поле ddhalinfo содержит структуру DD_HALINFO, возвращаемую функцией DrvGetDirectDrawInfo и описывающую возможности оборудования и драйвера. В полях ddcall backs, ddsurfacecall- backs и ddpalettecall backs хранятся структуры DD_CALLBACKS, DD_SURFACECALLBACKS и DD_PALETTECALLBACKS, возвращаемые функцией DrvEnableDirectDraw. Другая группа
236 Глава 3. Внутренние структуры данных GDI/DirectDraw структур относится к функциям трехмерной графики DirectDraw. Они передают механизму GDI информацию о точках входа DirectDraw, поддерживаемых драйвером. Таким образом, механизм GDI знает, какие функции следует вызывать при создании поверхности, назначении цветовых ключей, отображении адресов видеопамяти, переключении поверхностей и т. д. В структуре EDDDIRECTDRAWGLOBAL хранится немало другой интересной информации — например, список объектов DirectDraw, список заблокированных поверхностей, указатель на текущую поверхность и т. д. Функция EDDDIRECTDRAWGLOBAL является частью структуры PDEVWIN32K, описанной в разделе «WinDbg и расширение отладчика GDI». Структура PDEVWIN32K также включает структуру SPRITESTATE. Разобравшись с тем, как в механизме GDI организовано хранение общих данных DirectDraw (как глобальных, так и данных уровня процесса), давайте посмотрим, что же скрывается за поверхностями DirectDraw. С каждым объектом поверхности DirectDraw связывается соответствующая структура данных, скрытая от пользователя. В выходных данных команды dumpddobj эти структуры обозначаются типом DDSURFTYPE. Команда dumpddobj SURF расширения GDI выводит все манипуляторы поверхностей DirectDraw. При вызове команды dddsurface для конкретного манипулятора поверхности выводится структура данных режима ядра EDDSURFACE. typedef struct { HGDIOBJ void * ULONG ULONG DD SURFACE LOCAL DD SURFACE MORE DD SURFACE GLOBAL DD_SURFACE_INT EDD SURFACE * EDD_SURFACE * unsigned EDD DIRECTDRAWGLOBAL * EDD DIRECTDRAWLOCAL * FLONG unsigned ULONG unsigned HANDLE unsigned HBITMAP unsigned ERECTL unsigned } EDD_SURFACE; hHmgr; pentry; cExcLock; Tid; ddsurfacelocal; ddsurfacemore; ddsurfaceglobal; ddsurfaceint; peSurface_DdNext; peSurface_LockNext; unk_0c0: r peDirectDrawGlobal; peDirectDrawLocal; fl; unkJdO: iVisRgnUniqueness; unk_0d8; hSecure; unk_0e0; hbmGdi; unk_0e8; rclLock; unk_0fc[3]; За стандартным заголовком объектов GDI // // // // // // // // // // // // // // 000. заголовок GDI 004 008 00с 010 04с 068 0Ь4 0Ь8 ОсО 0d0 0е4 Оес; Ofc режима ядра в структуре EDD_ FACE следуют четыре структуры, документированные в Windows 2000 DDK
Структуры данных DirectDraw 237 DD_SURFACE_LOCAL, DD_SURFACE_MORE, DD_SURFACE_GLOBAL и DD_SURFACE_INT. Структура DD_ SURFACE_GLOBAL содержит информацию, общую для нескольких поверхностей — шаг (pitch), высота, ширина и координаты х/у. Структура DDSURFACELOCAL содержит данные, относящиеся к конкретному объекту поверхности — первичный и вторичный буферы, цветовые ключи, формат пикселов, присоединенные поверхности и т. д. Структура DDSURFACEMORE содержит дополнительные данные уровня поверхности — такие, как сведения о видеопорте и флаги оверлеев. Последняя структура, DD_SURFACE_INT, содержит указатель на структуру DDSURFACELOCAL. За документированными структурами поверхностей DirectDraw следуют указатели на следующую поверхность в списке, глобальные и локальные данные DirectDraw. В поле hbmGdi иногда хранится манипулятор DDB. Мы знаем, как устроены некоторые структуры данных DirectDraw режима ядра; но как они используются? Обработка графических команд DirectDraw (например, переключения поверхностей) обычно начинается с интерфейсного указателя на поверхность DirectDraw. По интерфейсному указателю на поверхность определяется манипулятор DD_SURF_TYPE объекта GDI и передается механизму GDI. Механизм находит структуру EDD_SURFACE и получает указатель на структуру EDD_DIRECTDRAW_GLOBAL, в которую входит структура DDSURFACECALLBACKS. В структуре DDSURFACECALLBACKS хранится указатель на точку входа драйвера экрана, обрабатывающую переключение поверхностей и вызываемую механизмом DirectDraw. Функции переключения передается структура DDFLIPDATA, которая собирается по данным из исходной и целевой структур EDDSURFACE. За подробностями обращайтесь к описанию DdFlip в DDK. До выхода окончательной версии Windows 2000 (сборка 2195) в DirectX использовалась общая таблица объектов с GDI. Команда dumphmgr расширения отладчика GDI наряду с обычными объектами GDI перечисляет и объекты DirectX. Объектам DirectDraw соответствует внутренний идентификатор типа 0x02, а объектам поверхностей DirectDraw — 0x03. Однако в официальной версии Windows 2000 разработчики Microsoft вывели объекты DirectX «из-под ведома» диспетчера манипуляторов GDI и передали их диспетчеру манипуляторов DirectX. В расширение отладчика GDI были добавлены новые команды dumpdd и dumpdobj. Диспетчер манипуляторов DirectX управляет шестью типами объектов: удаленные объекты, объекты DirectDraw, объекты поверхностей DirectDraw, объекты устройств Direct34D, объекты видеопорта DirectDraw и объект компенсации перемещений (motion compensation) DirectDraw. Согласно данным этих новых команд, диспетчер манипуляторов DirectX поддерживает 16-килобайтную таблицу с 1024 манипуляторами DirectX — сокращенную версию 256-килобайтной таблицы, рассчитанной на 16 384 манипуляторов. Мы пока не знаем, возможно ли увеличение размеров таблицы объектов DirectX. Также в настоящее время неизвестно, отображается ли таблица объектов DirectX на адресное пространство пользовательского режима, по аналогии с таблицей объектов GDI. Несомненно, отделение объектов DirectX от объектов GDI следует считать удачным шагом, который гарантирует, что приложения DirectX не будут конфликтовать с приложениями GDI за ограниченный набор манипуляторов GDI.
238 Глава 3. Внутренние структуры данных GDI/DirectDraw Итоги В этой главе исследуются внутренние структуры данных, лежащие в основе GDI и DirectDraw. В ней досконально разобрана организация внутреннего представления служебных данных GDI и графического механизма Windows. Глава начинается с простой задачи — мы выясняем, что же представляет собой манипулятор объекта GDI. Затем мы находим в памяти таблицу объектов GDI, расшифровываем ее структуру и некоторые структуры данных пользовательского режима, поддерживаемые для конкретных типов объектов GDI. Самые важные структуры данных GDI хранятся в адресном пространстве режима ядра. Чтобы иметь возможность прочитать содержимое этих структур, мы разработали простой драйвер режима ядра, Periscope, и запустили расширение отладчика GDI под управлением нашей собственной программы. Поскольку расширение отладчика располагает информацией о внутреннем устройстве GDI, это позволяет использовать его для расшифровки структур данных GDI режима ядра. Расширение отладчика GDI помогает получить доступ к структурам данных GDI режима ядра, обычно полностью скрытых от посторонних. После прочтения этой главы вы должны гораздо нагляднее представлять, как организовано внутреннее хранение данных в GDI, какие ресурсы при этом задействованы и как выполняется аппроксимация. Кроме того, вы должны получить общее представление о том, как данные преобразуются механизмом GDI и в конечном счете передаются драйверам графических устройств (таких, как драйверы экрана и принтеров). В главе 7 описана простая утилита, разработанная на основе материала этой главы и предназначенная для получения сводной информации об использовании объектов GDI разными процессами. «Дайте мне манипулятор GDI, и я покажу вам структуру данных GDI». «Дайте мне интерфейсный указатель DirectDraw, и я покажу вам структуру данных DirectDraw». Теперь вы можете с полным правом делать подобные заявления. Примеры программ Программы главы 3 (табл. 3.14) не принадлежат к числу обычных примеров графического программирования и даже не являются обычными Windows-программами. Скорее, это системные утилиты, которые помогают анализировать внутренние структуры данных операционной системы Windows. Конечно, вы можете пользоваться ими для своих собственных целей. Таблица 3.14. Программы главы 3 Каталог проекта Описание Samples\Chapt_03\Handles Расшифровка манипуляторов GDI, поиск таблицы объектов GDI и расшифровка таблицы объектов GDI Samples\Chapt_03\QueryTab Пример обращения к таблице объектов GDI из приложения
Итоги 239 Каталог проекта Описание Samples\Chapt_03\Periscope Драйвер устройства режима ядра, позволяющий работать с данными, находящимися в адресном пространстве режима ядра, из пользовательского адресного пространства с применением файловых операций Samples\Chapt_03\TestPeriscope Пример обращения к адресному пространству ядра из приложения Samples\Chapt_03\Fosterer Программа, управляющая работой DLL расширения отладчика GDI режима ядра, — отправная точка для исследования структур данных GDI/DirectDraw режима ядра
Глава 4 Мониторинг графической системы Windows Говорят, лучше один раз увидеть, чем сто раз услышать. Если вы видите происходящее своими глазами, вам гораздо проще разобраться в сути явления. Конечно, для этого желательно выбрать подходящий инструмент. Скажем, микроскоп помогает рассмотреть мельчайших живых существ, в телескоп видны далекие светила, а телевизор сближает людей, живущих в разных частях света. Программистов, работающих в системе Windows, в первую очередь интересует, что же на самом деле происходит между их программами и операционной системой. В главе 2 была описана общая архитектура графической системы Windows, а в главе 3 основное внимание уделялось структурам данных. Но при этом осталась совершенно проигнорированной динамика миллионов вызовов, происходящих в системе. С чего начинается работа программы? Чем она заканчивается? Всегда ли все идет гладко, или в системе случаются аварии, нарушения, пробки и утечки, которые вы попросту не замечаете? В этой главе вы овладеете навыками мониторинга функций API и некоторыми инструментами, необходимыми для понимания динамики вызова функций Win32 API, особенно функций Win32 GDI/DirectDraw, служебных функций графической системы и интерфейса DDL В разделе «Отслеживание вызовов функций Win32 API» разрабатывается общая система мониторинга Win32 API, которая состоит из DLL, внедряемой в целевой процесс, и управляющей программы. В разделе «Отслеживание вызовов Win32 GDI» эта общая система расширяется для мониторинга всех вызовов GDI в процессе. Раздел «Отслеживание СОМ-интерфейсов DirectDraw» посвящен СОМ-интерфейсам, используемым в DirectDraw, а раздел «Отслеживание системных вызовов GDI» иллюстрирует методику перехвата вызовов системных функций GDI. Наконец, в разделе «Отслеживание интерфейса DDI» мы снова «погрузимся» в режим ядра и рассмотрим процесс мониторинга функций интерфейса DDL
Отслеживание вызовов функций Win32 API 241 Отслеживание вызовов функций Win32 API Методика перехвата и отслеживания не так уж редко встречается в Windows- программировании. Существует немало профессиональных и любительских программ, в которых эти приемы используются для наблюдения за мельчайшими подробностями работы системы. Самым известным инструментом, использующим методику перехвата и отслеживания API, является BoundsChecker компании Numega — профессиональный пакет для обнаружения ошибок в среде Windows. BoundsChecker позволяет находить ошибки Windows API, ошибки интерфейсов COM/OLE, ошибки памяти, ошибки указателей, утечки ресурсов и сбои программы. В частности, BoundsChecker обнаруживает неудачные вызовы функций, недопустимые значения параметров, нереализованные функции, выходы за границы блоков памяти, переполнение стека, использование неинициализированной памяти, выход индексов за границы массива, утечки памяти, утечки ресурсов и т. д. Одним из базовых приемов, используемых в работе BoundsChecker, является отслеживание вызовов тысяч функций Windows API. BoundsChecker перехватывает вызовы функций Windows API, чтобы перед вызовом функций проверить параметры и сохранить информацию о содержимом стека, а после вызова — проверить возвращаемую величину, прежде чем передать ее приложению. При запуске программы система BoundsChecker выполняет функции отладчика, что позволяет внедрять DLL этой системы в адресное пространство процесса приложения и передавать им управление. Если BoundsChecker интегрируется с компилятором, обращения к DLL BoundsChecker включаются непосредственно в программный код. Так или иначе, все вызовы функций Win32 API проходят предварительную обработку в BoundsChecker. В «Microsoft System Journal» часто публикуются статьи о применении методики перехвата и отслеживания для обеспечения функционирования колеса мыши, обнаружения операций с памятью в программах СОМ или поиска причин взаимной блокировки (deadlock) в многопоточных программах. Microsoft даже включает в Platform SDK и Windows Resource Kits специальную утилиту для отслеживания API — apimon. Перехват и отслеживание проще всего организуется в коде пользовательского режима, однако такая возможность существует и в коде режима ядра. На web- сайте www.sysinternals.com имеется несколько утилит, работа которых основана на вмешательстве в иерархию файловой системы режима ядра Windows NT или цепочки драйверов устройств для отслеживания операций с файловой системой, реестром и обращений к портам. В Windows 2000 даже компания Microsoft признала пользу перехвата функций драйверов экрана, организовав поддержку зеркальных драйверов (mirroring driver) для драйверов экрана. Вероятно, в Microsoft постоянно поступали жалобы и вопросы, почему пользователь не может легко воспроизвести экран Windows на удаленном компьютере. Теперь при помощи зеркального драйвера можно передать поток данных по сети, не вмешиваясь в работу драйвера экрана. Коммерческие утилиты, инструментарий Microsoft и примеры программ, полученные из других источников, вряд ли удовлетворят все ваши потребности по отслеживанию и перехвату API — во всяком случае, если вас интересует дейст-
242 Глава 4. Мониторинг графической системы Windows вительно удобный, настраиваемый, модульный и достаточно универсальный инструмент. Ниже перечислены лишь некоторые ограничения, с которыми вы столкнетесь. О Настройка типов данных. Готовые инструменты работают с ограниченным набором типов данных, тогда как в Windows-программировании типы данных обновляются очень часто. Желательно, чтобы утилита отслеживания умела преобразовывать коды бинарных растровых операций в имена типа SCRC0PY, сохранять растры в файлах или, скажем, сообщать о том, что манипулятор GDI соответствует объекту логического пера. О Хронометраж. Возможность измерения времени, потраченного на обработку вызова Win32 API, поможет оптимизировать программу и исключить из нее нежелательные вызовы. О Недокументированные функции API, внутримодульные вызовы, вызовы системных функций, вызовы кода режима ядра. Отсутствие поддержки этих возможностей является одной из слабостей готовых программ. Если вы хотите действительно глубоко разобраться в какой-либо области Windows-программирования (например, в графическом программировании), обойтись без хорошей программы мониторинга практически невозможно. Построение программы мониторинга Программа мониторинга обычно состоит из двух частей: управляющей программы и разведчика (DLL или драйвера). Управляющая программа засылает разведчика в нужное место, отдает ему команды и, возможно, получает информацию. Разведчик проникает «в тыл» пользовательского процесса, закрепляется в нужном месте, собирает мельчайшие обрывки информации из интересующей области, действует в соответствии с поставленной задачей или передает информацию управляющей программе. На рис. 4.1 изображена схема работы такой программы. Конечно, у этой общей модели существует немало разновидностей. Если вы найдете надежный способ внедрения разведчика, чтобы он мог действовать самостоятельно, возможно, управляющая программа вам и не понадобится. Например, некоторые среды с двухбайтовой кодировкой символов существуют «поверх» обычной системы Windows. Вместо внедрения DLL во все приложения, обладающие графическим интерфейсом, они просто переименовывают системные DLL и заменяют их собственными реализациями, обеспечивающими поддержку двухбайтовой кодировки в однобайтовой системе. Если вы хотите проследить за операциями, происходящими в адресном пространстве режима ядра, вам наверняка понадобится драйвер устройства (то есть разведывательная DLL) режима ядра. В этом случае управляющая программа устанавливает драйвер и управляет его работой. Например, в программе Fosterer из главы 3 драйвер Periscope режима ядра использовался для чтения данных из адресного пространства ядра и последующего анализа структур данных графической системы, хранящихся в режиме ядра. SoftICE/W, отладчик системного уровня от компании Numega, также использует драйвер режима ядра для обеспечения возможностей отладки общесистемного уровня на одном компьютере.
Отслеживание вызовов функций Win32 API 243 Процесс 2 Программа под наблюдением Наблюдатель DLL/Драйвер Системная DLL Рис. 4.1. Компоненты программы мониторинга При написании программы-разведчика необходимо решить несколько задач: О внедрение разведчика в процесс; О подключение к цепочкам вызовов функций API; О получение параметров, возвращаемых значений и данных хронометража; О сохранение данных в удобном формате; О создание пользовательского интерфейса для выбора программ и модулей, за которыми вы хотите наблюдать, а также перехватываемых функций Win32 API и методов СОМ. В этом разделе мы создадим программу Pogy, предназначенную для общего мониторинга вызовов Win32 API. Программа названа в честь подводной лодки, участвовавшей в подводных научных исследованиях. Мы будем использовать Pogy для исследований глубин операционной системы Windows. Пользовательский интерфейс управляющей программы Роду.ехе оформлен в виде диалогового окна, состоящего из нескольких страниц. Наблюдением занимается DLL Diver.dll. А теперь давайте кратко рассмотрим строение этой программы. Внедрение DLL-разведчика В Win32 API существует возможность установки перехватчиков (hooks) на системном уровне или на уровне программного потока. Перехватчики отслеживают сообщения или изменяют стандартные действия, выполняемые при их обработке. Установка перехватчиков выполняется функцией API SetWindowsHooksEx. В Windows 2000 количество классов перехватчиков даже увеличилось до 15. Скажем, при установке перехватчика класса WMGETMESSAGE отслеживаются сообщения, поставленные в очереди сообщений, а перехватчик класса WH_SHELL получает оповещения о создании и уничтожении окон верхнего уровня.
244 Глава 4. Мониторинг графической системы Windows Функции-перехватчики обычно реализуются в DLL — для перехватчиков системного уровня это является обязательным требованием. Причина заключается в том, что для работы перехватчика в других процессах его код должен загружаться в адресное пространство целевого процесса. Исполняемый файл может загружаться другим процессом только в виде данных, поэтому перехватчик системного уровня должен быть реализован в DLL. После загрузки DLL в адресное пространство процесса перехватчик может вытворять практически все, что захочет. На этом факте основаны некоторые приемы отслеживания вызовов API. Впрочем, вы должны позаботиться о том, чтобы DLL оказалась в нужном месте. Функция SetWindowsHookEx является лишь одним из возможных способов внедрения DLL в исследуемый процесс. Впрочем, этот способ прост и хорошо документирован. Чтобы DLL внедрялась в каждый процесс, ее можно включить в следующий ключ реестра Windows NT/2000: HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NTXCurrent Version\Windows\AppInit_DLLs Знание нетривиальных способов внедрения DLL во внешние процессы является неплохим показателем квалификации в области Windows-программирования. В классической книге Мэтта Питрека (Matt Pietrek), «Windows 95 System Programming Secrets», продемонстрирован механизм внедрения DLL через API отладчика Win32 и динамическую модификацию кода исследуемого процесса. В книге Джеффри Рихтера Qeffery Richter), «Programming Applications for Microsoft Windows» (5 издание), показано, как сделать то же самое с использованием удаленного программного потока. В нашей программе Pogy функция SetWindowsHookEx устанавливает перехватчик системного уровня, который представляет собой функцию косвенного вызова, определяемую приложением. После регистрации в системе перехватчик системного уровня вызывается при наступлении некоторых событий в системе, тогда как перехватчик уровня программного потока отвечает лишь за один поток. Функция-перехватчик ShellProc реализуется в DLL Diver.dll, как это требуется для перехватчика системного уровня. Модуль Diver экспортирует функцию SetupDiver, вызываемую из управляющей программы Роду.ехе для выполнения установки, удаления и настройки взаимодействия между компонентами. Ниже приведена часть кода перехватчика, работающая на стороне DLL-разведчика. #pragma data_seg("Shared") HWND h_Controller = NULL; HHOOK hJhellHook - NULL; #pragma data_seg() #pragma comment(1 inker. "/section:Shared,rws") LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam. LPARAM 1 Param ) { if ( nCode==HSHELL_WINDOWCREATED ) if (...) StartSpyO; assert(h_ShellHook);
Отслеживание вызовов функций Win32 API 245 if (h_ShellHook) return Cal1NextHookEx(h_ShellHoQfc. nCode. wParam. lParam); else return FALSE; } void _declspec(dllexport) SetupDiver(int nOpt. HWND hWnd) { switch (nOpt) { case Diver_Insta11: assert(h_ShellHook==NULL); hJhellHook = SetWindowsHookEx(WH_SHELL. (H00KPR0C) ShellProc, hlnstance. 0); h_Controller = hWnd; break; case Diver_UnInstall: assert(h_She11Hook!=NULL); UnhookWindowsHookEx(h_ShellHook); h_ShellHook = NULL; break; } } Перехватчик системного уровня регистрируется в системе (диспетчере окон) только один раз. Функция SetWindowsHookEx возвращает манипулятор, который используется функцией-перехватчиком и по которому в итоге перехватчик удаляется вызовом UnhookWindowsHookEx. Возникает проблема: если перехватчик системного уровня может загружаться в адресные пространства разных процессов, обычно изолированные друг от друга, где же тогда хранится манипулятор? Ответ: в секции общих данных той DLL, в которой определена функция перехвата. Обычная секция данных ЕХЕ-файла Win32 является закрытой для процесса, загрузившего DLL; иначе говоря, каждый процесс работает со своей собственной копией этой секции. Однако секция общих данных совместно используется всеми процессами, загрузившими DLL. В приведенном выше фрагменте начало и конец этой секции отмечены двумя директивами dataseg, а директива comment (linker) сообщает компоновщику о том, что эта секция доступна для чтения/записи и является общей («rws»). Мы сохраняем в общей секции манипуляторы перехватчика и окна. Пожалуйста, обратите внимание на необходимость инициализации данных общей секции. Управляющая программа Pogy.exe связана с той же DLL Diver.dll. При загрузке Pogy создает окно для взаимодействия с DLL-разведчиком. Далее Pogy вызывает функцию SetupDiver(Diver_Instan,...), сообщая разведчику манипулятор своего окна и позволяя создать перехватчик. При вызове функции SetWindowsHookEx возвращается манипулятор перехватчика, необходимый для вызова следующего перехватчика в цепочке перехватов. Манипуляторы окна управляющей программы и перехватчика хранятся в DLL и поэтому доступны для всех пользовательских процессов. Таким образом, после присваивания значений h_ShellHook и hController любой процесс может обратиться к этим переменным.
246 Глава 4. Мониторинг графической системы Windows Однако к этому моменту библиотека Diver.dll загружена еще только в процесс управляющей программы. Функция перехвата вызывается лишь при создании или уничтожении окна верхнего уровня. Если это происходит в каком-то процессе, отличном от процесса управляющей программы, операционная система видит, что вызываемый перехватчик отсутствует в текущем процессе, и загружает DLL с перехватчиком. После загрузки DLL вызывается функция Shell Ргос с кодом HSHELLWINDOWCREATED. Функция Shell Ргос связывается с управляющей программой и определяет, следует ли начать отслеживание вызовов API. Главное, что требует операционная система от функции-перехватчика — чтобы она не забыла вызвать следующий перехватчик в цепочке функцией CallNextHookEx. В функции SetupDiver также предусмотрена возможность отключения перехватчика. Подключение к цепочке вызовов функций API Получив от управляющей программы приказ о начале работы, DLL-разведчик инициализируется и создает скрытое окно. Манипулятор этого окна передается управляющей программе. С этого момента управляющая программа и разведчик могут обмениваться сообщениями посредством манипуляторов окон. В операционной системе Windows для обмена простыми сообщениями с двумя 32-разрядными параметрами задействуются коды пользовательских сообщений, начинающиеся с префикса WMUSER. Но если вы захотите передать блок данных за границы процесса, обычный указатель не подойдет — указатель, относящийся к одному адресному пространству, в общем случае не работает в другом адресном пространстве. К счастью, для отправки блоков данных можно воспользоваться функцией WM_COPYDATA. Операционная система Windows специально обеспечивает правильность копирования блоков данных в сообщениях типа WM_ SETTEXT, WM_GETTEXT и WM_COPYDATA за границами процесса. Получив информацию о том, что DLL-разведчик создал коммуникационное окно, управляющая программа отправляет список отслеживаемых функций. Для каждой функции задается имя вызывающего модуля, имя вызываемого модуля, имя функции, количество параметров, типы параметров и тип возвращаемого значения. Например, если пользователь хочет отслеживать вызовы функции GDI SetTextColor из программы CLOCK.EXE, задаются следующие значения: О имя вызывающего модуля — CLOCK.EXE; О имя вызываемого модуля — GDI32.DLL; О имя функции — SetTextCol or; О количество параметров — два; О типы параметров - HDC и C0L0RREF; О тип возвращаемого значения — C0L0RREF. По полученным данным DLL строит внутреннюю таблицу отслеживаемых модулей и функций. В главе 1 кратко рассматривался формат РЕ-файлов, используемых для представления модулей Win32 (находящихся как на диске, так и в памяти). При этом упоминалось, что при статической или динамической компоновке модулей используются каталоги экспорта и импорта, с хранением адреса каждой импор-
Отслеживание вызовов функций Win32 API 247 тируемой функции во внутренней переменной. Следовательно, чтобы подключиться к цепочке вызова функции Win32 API, необходимо лишь найти в каталоге импорта модуля тот адрес, по которому хранится адрес импортируемой функции, и заменить его адресом функции-перехватчика. Конечно, чтобы программа могла нормально работать, перед заменой исходный адрес следует сохранить. При мониторинге сразу нескольких функций вы не сможете просто заменить несколько импортируемых адресов одним адресом функции-перехватчика. Функция-перехватчик по крайней мере должна знать, для какой отслеживаемой функции она вызывается. В нашей реализации для каждого элемента таблицы отслеживаемых функций создается небольшая функция-заглушка, которая заносит индекс функции в стек перед вызовом универсальной функции ProxyProlog. Таким образом, при модификации каталога импорта модуля используются адреса заглушек. Заглушки выглядят следующим образом: push index // 68 хх хх хх хх jmp ProxyProlog // Е9 уу уу уу уу Функции ProxyProlog остается лишь извлечь индекс из стека, а затем воспользоваться им при обращении к таблице функций для получения полной информации. На рис. 4.2 показано, как происходит вызов функции Win32 до и после модификации каталога импорта адресом заглушки. В левой части изображена ситуация до перехвата; значение переменной каталога импорта используется для косвенного вызова функции Win32 API. В правой части показано, что происходит после модификации. Теперь приложение осуществляет косвенный вызов заглушки, передающей управление универсальной функции ProxyProlog библиотеки Diver.dll. Функция ProxyProlog, а также сопутствующие функции и структуры данных Diver.dll отвечают за то, чтобы после обработки была вызвана исходная функция Win32 API, а затем управление было возвращено вызывающей стороне. —► Application call [ imp_SetTextColor] & SetTextColor GDI32.DLL <— 1—► Application call [stub SetTextColor] Diver.DLL push id__SetTextColor jmp ProxyProlog ProxyProlog, etc. GDI32.DLL Рис. 4.2. Перехват вызова функции API с использованием заглушки
248 Глава 4. Мониторинг графической системы Windows ПРИМЕЧАНИЕ Чтобы решение было по возможности универсальным, следует избегать модификации содержимого регистров. Если бы индекс передавался не в стеке, а в регистре, наше решение не работало бы для функций, использующих регистры для передачи параметров. Сбор информации Для тех функций, за которыми мы следим, вызов ProxyProlog предшествует вызову настоящей функции Win32 API. Однако ProxyProlog и связанные с ней функции должны выполнить очень непростую работу — собрать информацию обо всех параметрах, сохранить время входа в функцию, вызвать исходную функцию API, сохранить время возвращения из функции, сохранить возвращаемое значение и, наконец, вернуть управление вызывающей стороне. Программа- разведчик должна восстановить в прежнем виде все, к чему она прикасалась, — все регистры и флаги процессора (кроме счетчика тактов). Из-за своей сложности эта задача разделена между несколькими функциями, написанными на ассемблере, С и даже на C++ с применением виртуальных функций. О Функция ProxyProlog написана на «голом» ассемблере — в том смысле, что компилятор не должен включать в нее стандартный код входа и выхода из функции. Функция сохраняет содержимое регистров, текущее время (время 1), вызывает функцию ProxyEntry, снова сохраняет время (время 2), восстанавливает регистры и, наконец, возвращает управление исходной функции Win32 API, вызываемой приложением. О Функция ProxyEntry написана на языке С. Она создает в программном стеке структуру KRoutinelnfo, сохраняет основную информацию о вызове, вызывает виртуальную функцию C++ KFuncTable: -.FuncEntryCallBack, модифицирует стек процессора, чтобы при выходе из исходной функции Win32 API управление сначала передавалось функции ProxyEpilog, а затем снова модифицирует стек процессора, чтобы функция ProxyProlog передала управление исходной функции Win32 API. О Функция KFuncTable::FuncEntryCallBack реализована как виртуальная функция C++. В минимальной реализации она не делает ничего. Впрочем, эта функция располагает всей информацией о параметрах и времени входа-выхода, поэтому при желании она может выполнить хронометраж, сохранить параметры, проверить и даже изменить их значения. О Функция ProxyEpilog, написанная на «голом» ассемблере, вызывается сразу же после возврата из функции Win32 API. Она сохраняет регистры, сохраняет время (время 3), вызывает функцию ProxyExit, снова сохраняет время (время 4), восстанавливает регистры и, наконец, возвращает управление вызывающей стороне, тем самым завершая мониторинг одного вызова функции API. О Функция ProxyExit написана на языке С. Она извлекает из программного стека структуру KRoutinelnfo, вызывает виртуальную функцию KFuncTable::Func- ExitCallBack и модифицирует стек процессора, чтобы функция ProxyEpilog вернула управление исходной вызывающей стороне.
Отслеживание вызовов функций Win32 API 249 О Функция KFuncTable: iFuncExitCallBack реализована как виртуальная функция C++. В минимальной реализации она не делает ничего. Функция располагает всеми данными о времени входа и выхода, а также о возвращаемом значении функции API. При необходимости она может вернуть эту информацию управляющей программе. Ниже приведен код важнейших входных функций, ProxyProlog и ProxyEntry. typedef struct { unsigned m_flag; unsigned m_edx unsigned m_ecx unsigned m_ebx unsigned m_eax unsigned m_funcid; unsigned m_rtnads; unsigned m_para[32]: } EntryInfo; _declspec(naked) void ProxyProlog(void) { // funcid, rtadr. pi..pn // funcid резервирует в стеке место. // в которое позднее заносится адрес вызывающей стороны // Сохранить общие регистры и флаги asm asm asm asm asm asm asm asm push push push push pushfd _emit _emit shrd eax ebx ecx edx OxOF 0x31 eax. edx. 8 // edx. ecx. ebx. eax // 4 байта EFLAGS // Время 1 // EAX = EDX:EAX » 8 _asm push eax // Время входа _asm sub eax. OverHead _asm push eax // Время входа - затраты _asm lea eax. [esp+8] // Смещение флага в стеке _asm push eax _asm call ProxyEntry // Функция С _asm pop ecx // ecx = время входа _asm _emit OxOF // Время 2 _asm _emit 0x31 _asm shrd eax. edx. 8 // EAX = EDX:EAX » 8 _asm sub eax. ecx // Новые затраты после ProxyEntry asm add OverHead. eax // Восстановить общие регистры и флаги _asm popfd
250 Глава 4. Мониторинг графической системы Windows _asm pop edx _asm pop ecx _asm pop ebx _asm pop eax // Вернуть управление вызывающей стороне asm ret } void _stdcall ProxyEntry(EntryInfo *info. unsigned entertime) { int id = info->m_funcid; assert(pStack!=NULL); KRoutinelnfo * routine - pStack->Push(); if ( routine ) { routine->entertime - entertime; routine->funcid - id: routine->rtnaddr * info->m_rtnads; pFuncTable->FuncEntryCal1 Back(routine, info); // Модифицировать адрес возврата, чтобы перед возвращением // к исходной вызывающей стороне управление было передано // нашей функции ProxyEpilog info->m_rtnads - (unsigned) ProxyEpilog; } // Обеспечить возврат управления исходной функции // при выходе из ProxyProlog info->m_funcid - (unsigned) pFuncTable->m_func[id].f oldaddress; } Измерение времени осуществляется самым точным и эффективным способом, существующим на процессорах Intel благодаря инструкции RDTSC. Эта инструкция возвращает в регистрах EDX:EAX 64-разрядное количество тактов процессора, прошедших с момента последнего запуска. На процессоре Pentium 200 МГц один такт занимает 5 не. Работать с 64-разрядными величинами неудобно, поэтому программа сдвигает пару EDX:EAX на 8 разрядов вправо и использует только младшее 32-разрядное значение. Минимальный интервал времени увеличивается до 5 х 28 - 1280 не, что все равно гораздо лучше миллисекундной точности, обеспечиваемой функцией GetTickCount. При точности в 1,28 мкс 32-разрядная величина способна представить интервал длительностью до 1,58 часа; для обычного тестирования этого вполне достаточно. Для одного вызова API программа читает счетчик тактов 4 раза: перед вызовом ProxyEntry, перед вызовом перехватываемой функции API, перед вызовом ProxyExit и перед возвратом управления вызывающей стороне. Интервал между точками 1 и 2 приближенно определяет затраты на вход в функцию; интервал между точками 2 и 3 определяет истинные затраты на вызов функции Win32 API; наконец, интервал между точками 3 и 4 определяет затраты на выход из
Отслеживание вызовов функций Win32 API 251 функции. Программа поддерживает глобальную переменную OverHead, в которой суммируются все непроизводительные затраты, и вычитает ее значение из данных хронометража. Стек, используемый для передачи параметров и адреса возврата, растет в направлении нижних адресов; при сохранении нового значения указатель стека уменьшается, а при извлечении — увеличивается. После блока параметров следует адрес возврата. При вызове функция-заглушка заносит в стек идентификатор (индекс) функции, после чего вызывает ProxyProlog. Функция ProxyProlog включает в стек несколько стандартных регистров и копию регистра флагов процессора. Все эти значения отображаются на структуру Entry Info уровня С, указатель на которую передается ProxyEntry. Функция ProxyEntry использует указатель на Entry Info для получения идентификатора функции и модификации адресов возврата в стеке. Дальше происходит самое интересное. После вызова ProxyEntry функция Proxy- Prolog восстанавливает общие регистры и регистр флагов, после чего выполняет инструкцию ret. Куда при этом возвращается управление? Когда-то на вершине стека процессора находился индекс функции, занесенный туда заглушкой, но позднее функция ProxyEntry записывает на это место адрес исходной функции Win32 API. Следовательно, последняя инструкция ret в ProxyProlog фактически возвращает управление исходной реализации API. Например, если мы включаемся в цепочку перехвата функции GDI DeleteObject, код заглушки заносит в стек индекс функции (например, 5) и вызывает ProxyProlog. Функция ProxyProlog вызывает функцию ProxyEntry, чтобы та сохранила параметры и записала на место индекса адрес GDI-реализации DeleteObject. Таким образом, последняя инструкция ProxyProlog передает управление функции GDI DeleteObject. Выходная часть представляет собой зеркальное отражение входной части. Функции ProxyEpilog и ProxyExit приведены ниже для полноты картины. typedef struct { unsigned m_rslt; } Exitlnfo; declspec(naked) void ProxyEpilog(void) I _asm push eax // Результат вызова функции API. // Также резервирует место // для адреса возврата __asm push eax // Сохранить общие регистры __asm push ebx __asm push ecx __asm push edx __asm pushfd // 4 байта флагов __asm _emit OxOF // Время 3 _asm _emit 0x31 asm shrd eax, edx, 8 // EAX » EDX:EAX » 8 asm push eax // Время выхода asm sub eax, OverHead
252 Глава 4. Мониторинг графической системы Windows _asm push eax // Время выхода - затраты _asm lea eax. [esp+28] // Адрес зарезервированного участка _asm push eax _asm call ProxyExit _asm pop ecx // ecx = время выхода _asm _emit OxOF // Время 4 _asm _emit 0x31 _asm shrd eax. edx. 8 // EAX - EDXrEAX » 8 _asm sub eax. ecx // Новые затраты после ProxyEpilog _asm add OverHead. eax _asm popfd // Восстановить флаги и регистры _asm pop edx _asm pop ecx _asm pop ebx _asm pop eax _asm ret // Вернуть управление // исходной вызывающей стороне void _stdcall ProxyExit(ExitInfo *info. unsigned leavetime) { int depth; assert(pStack); KRoutinelnfo * routine = pStack->Lookup(depth); if ( routine ) { pFuncTable->FuncExitCa"ll Back (routine, info, leavetime. depth): info->m_rslt = routine->rtnaddr; pStack->Pop(); При выходе из перехватываемой функции Win32 API управление не возвращается непосредственно вызывающей стороне. Вместо этого вызывается наша функция ProxyEpilog. Дело в том, что функция ProxyProlog изменяет адрес возврата в стеке так, чтобы он указывал на ProxyEpilog (посредством простого присваивания info->m_rtnads = (unsigned)ProxyEpilog). Мы предусмотрительно сохранили этот адрес возврата в программном стеке для последующего использования. Теперь особое внимание уделяется регистру ЕАХ; в нем хранится скалярное возвращаемое значение функции (например, манипулятор GDI, возвращаемый функцией CreateSolidPen). Функция ProxyEpilog сохраняет его в стеке и передает информацию ProxyExit в виде указателя на структуру Exitlnfo. Структура Exitlnfo состоит из единственного поля, в котором хранится возвращаемое значение функции. Функция ProxyExit находит структуру KRoutinelnfo в программном стеке, вызывает функцию KFuncTable: :FuncExitCallback, а затем заносит на место возвращаемо-
Отслеживание вызовов функций Win32 API 253 го значения в стеке адрес возврата, который используется функцией ProxyEpilog для передачи управления исходной вызывающей стороне посредством функции ret. На рис. 4.3 изображен процесс перехвата функции API вместе со всеми изменениями, происходящими в стеке процессора. В нижней части показана передача управления от приложения к заглушке, функции ProxyProlog, функции Win32 API, ProxyEpilog и обратно к приложению (функции ProxyProlog и ProxyEpilog являются вспомогательными). В верхней части рисунка показаны изменения в стеке. Стек Параметр ret addr Параметр ret addr funcid Параметр ProxyEpilog & gdi32!func Параметр ProxyEpilog —► Приложение Передача упрг —► шлек Функция- заглушка 1ИЯ —► ProxyProlog ProxyEntry ж —► GDI32.DLL —► ProxyEpilog j А т ProxyExit FuncEntryCall Back FuncExitCall Back Рис. 4.З. Передача управления и изменения в стеке при перехвате функций API И последнее, о чем следует упомянуть, — устройство программного стека. Для каждого вызова функции API программа должна создать структуру KRoutinelnfo с информацией о вызове функции, используемую как входной, так и выходной частью. При вызове функции API в стек заносится одна новая структура, а при завершении обработки вызова API последняя запись выталкивается из стека. Все замечательно... если только процесс не состоит из нескольких программных потоков. Рассмотрим следующую ситуацию: первый поток вызывает функцию API и блокируется в ожидании какого-то ресурса; затем второй поток вызывает функцию API и тоже блокируется. Теперь первый поток «просыпается» и завершает обработку функции API. В этом случае программный стек перестает соответствовать принципу LIFO («последним пришел, первым вышел»). Этот принцип действительно соблюдается только на уровне программного потока. Обратите внимание: стек процессора, используемый при обработке вызовов Win32 API, полностью соответствует принципу LIFO, поскольку каждый программный поток работает с отдельным стеком. В нашей реализации программного стека проблема решается благодаря пометке каждой структуры идентифи-
254 Глава 4. Мониторинг графической системы Windows катором текущего потока, а операции занесения и извлечения из программного стека приходится координировать на уровне потока. Для защиты стека от модификаций применяется критическая секция. Вывод данных Итак, рассмотренные нами функции собирают всевозможную информацию о вызовах функций API. Преобразование «сырых» данных в более осмысленную и удобную форму также является одной из задач DLL-разведчика. Конечно, данные можно сохранять в разных форматах, однако простой текстовый формат проще всего генерируется и читается. Вероятно, обработку больших объемов накопленных данных удобнее проводить в электронных таблицах или базах данных. Такие программы, как Microsoft Excel, Lotus 123 или Microsoft Access, легко преобразуют правильно отформатированные текстовые файлы в свой рабочий формат. Все, что от вас потребуется, — обеспечить последовательное разделение столбцов в текстовых файлах либо по фиксированной ширине, либо при помощи символов табуляции, двоеточий, запятых и других служебных символов. Например, программа SysCall из главы 2 генерирует списки системных функций GDI, вызываемых из GDI32.DLL. Однако список упорядочивается в соответствии с порядком символических имен в отладочных файлах, а не по идентификаторам системных функций или адресам вызывающих функций. Вы можете создать таблицу в Microsoft Excel, импортировать в нее текстовый файл, сгенерированный SysCall, с разделением столбцов по фиксированной ширине, а затем настроить ширину и типы столбцов. В результате вы получаете электронную таблицу Excel с удобными средствами сортировки и анализа данных. Наша разведывательная DLL выводит данные в текстовый файл, разделяя поля запятыми. Файлам присваиваются имена с последовательной нумерацией pogy0000.txt, pogy0001.txt и т. д. Программный код создания файла находит следующий свободный номер в последовательности, чтобы предотвратить стирание старых файлов. В простейшем случае вывод данных организуется просто. Параметры функций Win32 API обычно состоят из 4 байт; такой же размер имеет возвращаемое значение скалярной функции, передаваемое в регистре ЕАХ. Самое «тупое» решение — выводить все значения в виде 8 шестнадцатеричных цифр. Таким образом, TRUE будет выводиться в виде «0x00000001», FALSE — в виде «0x00000000», код растровой операции SRCC0PY — в виде «0х00СС0020», а для текстовой строки будет выводиться только адрес. В общем, для хакера сойдет, но для простых пользователей очень неудобно. В Win32 API определяется очень богатый ассортимент типов (или по крайней мере макросов типов). Мы работаем со знаковыми и беззнаковыми числами разного размера, всевозможными указателями, бесчисленными манипуляторами и типами высокого уровня, например BITMAPINF0, L0GF0NT, DEVM0DE и т. д. Архитектура DLL-разведчика позволяет вам выбрать специальную интерпретацию для каждого из этих типов. Для каждой функции Win32 API типы параметров и возвращаемых значений также могут задаваться по именам. Значения, относящиеся к одному типу, расшифровываются одинаково. Вы можете настроить
Отслеживание вызовов функций Win32 API 255 процесс преобразования «сырых» данных в текстовый формат и добавлять поддержку новых типов данных при помощи подключаемых DLL. Чтобы упростить работу с сотнями имен типов, функций и модулей, мы воспользуемся таблицей атомов и преобразуем имена из текстового формата в целочисленные индексы. Например, вместо имени COLORREF программа передает целочисленный атом COLORREF, значение которого получается на стадии инициализации при включении строки COLORREF в таблицу атомов. Все компоненты системы работают с одной таблицей атомов, поэтому если другой компонент вдруг захочет снова включить COLORREF в таблицу атомов, повторного включения не произойдет; вместо этого будет возвращено исходное целочисленное значение. Происходящее очень похоже на API работы с атомами в Win32. Программа реализует таблицу атомов без использования функций атомов Win32 API по соображениям быстродействия и переносимости. Таблица атомов преобразуется в базовый класс C++ IAtomTable, который сильно напоминает интерфейс СОМ (правда, в данном случае интерфейс IUnknown нам не нужен): struct IAtomTable { virtual ATOM AddAtom(const char * name) = 0: virtual const char * GetAtomName(ATOM atom) = 0; }: Наряду с таблицей атомов также определяется базовый класс C++ IDecoder, преобразующий некоторые типы данных в текстовый формат: struct IDecoder { virtual bool Initialize(IAtomTable * pAtomTable) = 0; virtial int DecodeCATOM typ. const void * pValue. char * szBuffer. int nBufferSize) = 0; }: В этом объявлении ключевое слово struct эквивалентно class, за исключением того, что все определяемые типы и функции являются открытыми (public). Ключевое слово COM interface определяется как struct в файле basetyps.h. Метод IDecoder: .-Initialize включает в таблицу атомов имена типов данных. Метод IDecoder:: Decode расшифровывает блок данных в текстовый буфер и возвращает размер задействованных данных. Такая архитектура позволяет работать с блоками данных вместо отдельных 4-байтовых значений, что бывает очень удобно при расшифровке параметров, которые не поддаются осмысленной расшифровке по отдельности. Например, для функции ExtTextOut в двух последних параметрах передается количество символов и указатель на целочисленный массив. Не зная количества символов, декодер не сможет определить, сколько элементов в массиве он должен расшифровать. Если класс IDecoder определяется так, как показано выше, вы можете определить новый тип массива CountedlntArray и передать методу IDecoder::Decode два 32-разрядных значения для этого массива. Метод IDecoder:-.Decode возвращает количество задействованных байт или О, если данные не были обработаны.
256 Глава 4. Мониторинг графической системы Windows DLL-разведчик содержит базовый декодер (класс KBasicDecoder) для простой расшифровки стандартных типов данных Win32. Ниже приведен небольшой фрагмент этого класса. ATOM atom_char; ATOM atom_BYTE; ATOM atom_C0L0RREF; boo! KBasicDecoder::InitializeCIAtomTable * pAtomTable) { if ( pAtomTable==NULL ) return false: atom_char - pAtomTable->AddAtom("char"); atom_BYTE = pAtomTable->AddAtomCBYTE"); atom_C0L0RREF = pAtomTable->AddAtom("COLORREF"): return true: } int KBasicDecoder::Decode(ATOM typ. const void * pValue. char * szBuffer. int nBufferSize) { unsigned data = * (unsigned *) pValue: if ( typ==atom_char ) wsprintf(szBuffer, "'%c'", data): return 4: f ( typ==atom_BYTE ) wsprintf(szBuffer. "*d\ data & OxFF): return 4: if ( typ==atom_COLORREF ) if ( data==0 ) strcpy(szBuffer. "BLACK"); else if ( data==OxFFFFFF ) strcpy(szBuffer. "WHITE"): else wsprintf(szBuffer. "ЯОбх". data): return 4: } return 0: // Необработанные типы } На стадии инициализации DLL-разведчик создает таблицу атомов, инициализирует экземпляр KBasicDecoder, загружает ini-файл с информацией о специальных настройках IDecoder, загружает и инициализирует каждую из них.
Отслеживание вызовов функций Win32 API 257 Статическая функция MainDecoder управляет всем процессом расшифровки блока данных. Она проходит по цепочке реализаций I Decoder и находит ту, которая позволяет расшифровать определенные типы данных. Реализации KFuncTable:: FuncEntryCallBack и KFuncTable::FuncExitCal 1 Back просто вызывают MainDecoder. Итак, в нашем распоряжении имеется расширяемый декодер для расшифровки типов данных Win32. Как видите, знакомство с архитектурой расширения отладчика WinDbg нас кое-чему научило. Управляющая программа Мы разобрались с процессом внедрения DLL-разведчика, перехватом функций Win32 API, сбором информации и выводом данных... Чего еще не хватает в нашем решении? Очевидно, управляющей программы, при помощи которой выбираются атакуемые программы, отслеживаемые модули и функции, а также точное определение Win32 API. Конфигурация управляющей программы Pogy определяется несколькими стандартными ini-файлами Windows. Эти файлы хранятся в текстовом формате, их структура понятна без лишних объяснений, а в Win32 API предусмотрены средства для их обработки. Управляющая программа является приложением Win32, поэтому ничто не мешает нам использовать все имеющиеся возможности Win32. Главный файл данных, Pogy.ini, состоит из двух секций. В секции Target перечисляются приложения, за которыми вы хотите следить, с указанием конфигурационных файлов для каждого приложения. В секции Option хранятся общие параметры работы программы (например, флаги регистрации вызовов API и отображения информации о вызовах в окне). Здесь же указываются DLL для расшифровки дополнительных типов данных. Пример файла Pogy.ini: [Target] KL0CK.EXE (pclock.ini) 2=N0TEPAD.EXE (pnotepad.ini) [Notepad] LogCall=l DispCall=0 Decoderl=pogygdi.dll!_Create_GDI_Decoder@0 Decoder2=pogygdi.dll!_Create_DDRAW_Decoder В соответствии с этим ini-файлом мы хотим регистрировать вызовы API, но без отображения информации о них. К программе подключаются два декодера для дополнительных типов данных: один предназначен для типов GDI, а другой — для типов, относящихся к DirectDraw. Пользователь может отслеживать работу одной из двух программ, для каждой из которых существует отдельный ini-файл. В ini-файле уровня приложения перечисляются модули прикладного процесса, за которыми вы собираетесь следить. Пользователь должен указать имя вызывающего модуля, имя вызываемого модуля и имя ini-файла для группы функций API. Пример: [Module] CL0CK.EXE. Gdi32.DLL. wingdi CL0CK.EXE. User32.DLL. winuser
258 Глава 4. Мониторинг графической системы Windows Это означает, что нас интересуют обращения к GDI32.DLL и USER32.DLL; им соответствуют отдельные ini-файлы wingdi.ini и winuser.ini. Имейте в виду, что ini-файлы групп функций API играют в нашей программе такую же роль, как заголовочные файлы Windows в компиляторе C/C++; другими словами, они содержат описание API, используемое программой во время мониторинга. Конечно, очень хотелось бы изобрести автоматизированный способ построения этих ini-файлов по содержимому заголовочных файлов Windows, библиотечных файлов или каких-нибудь файлов с символическими именами... Но пока не будем отвлекаться и просто введем вручную всю информацию — имя модуля, имя функции, список типов параметров и тип возвращаемого значения. Ниже приведен небольшой фрагмент файла для GDI API. [wingdi] int SelectClipRgnCHDC. HRGN) int SetR0P2(HDC.int) BOOL SetWindowExtEx(HDC. int. int. LPSIZE) BOOL SetBrushOrgEx(HDC. int. int. LPPOINT) BOOL LPtoDP(HDC. LPPPOINT. int) HBRUSH CreateBrushlndi rect(LPLOGBRUSH) HBRUSH CreateDIBPatternBrushPt(LPVOID. UINT) BOOL DeleteDC(HDC) HBITMAP CreateBitmap(int. int. UINT. UINT. LPVOID) HDC CreateCompatibleDC(HDC) HBRUSH CreateSolidBrush(COLORREF) HRGN CreateRectRgnlndi rect(LPRECT) INT SetBoundsRectCHDC. LPRECT. UINT) BOOL PatBltCHDC. int. int. int. int. DWORD) BOOL SetViewportOrgEx(HDC. int. int. LPPOINT) BOOL SetWindowOrgEx(HDC. int. int. LPPOINT) int SetMapModeCHDC. int) Пользовательский интерфейс управляющей программы Pogy представляет собой диалоговое окно, состоящее из трех страниц-вкладок. На странице Events регистрируются такие события, как создание и уничтожение окон, перехват вызовов функций API DLL-разведчиком, а также выводится подробная информация о вызовах API (если в ini-файле установлен соответствующий флаг). На странице Setup устанавливаются флаги регистрации данных. На странице API выводятся данные, прочитанные программой из ini-файлов. Здесь же выбирается приложение, за которым вы собираетесь наблюдать (из перечисленных в Pogy.ini). В таблице выводится информация о загруженных описаниях функций API. Страница API управляющей программы изображена на рис. 4.4. После запуска программа Pogy устанавливает общесистемный перехватчик, реализованный в Diver.dll. При создании или уничтожении окна верхнего уровня любого приложения DLL-разведчик загружается в его адресное пространство. Diver.dll получает имя главного исполняемого файла приложения и отправляет Pogy сообщение, чтобы узнать, нужно ли следить за данным процессом. Если приказ будет отдан, DLL-разведчик создает скрытое окно для получения информации об отслеживаемых функциях, включается в цепочку перехвата заданных функций и начинает записывать полученную информацию в текстовый файл. Наблюдение прекращается с завершением целевого приложения.
Отслеживание вызовов функций Win32 API 259 ICLODCEXE »', 1 Class-'-'---- lift 6di32.dll ;j£|Gdi32.dll :;|Й 6di32.dll iifiGdi32.dll ijUGdi32.dll iii|Gdi32.dll iiflGdi32.dll Ш Gdi32.dll |:|9 Gdl32.dll |j£| Gdi32.dll jjnterftsce . Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll Gdi32.dll ЛъА* - AddFontResourceA AddFontResourceW AnimatePalette Arc BitBU CancelDC Chord ChoosePixelFormat CloseMetaFile CombineRgn zzg jff •<4>f* m Рис. 4.4. Пользовательский интерфейс программы мониторинга Win32 API После всех потраченных усилий нас ожидает награда — протокол вызовов функций Win32 API, сгенерированный DLL-разведчиком под управлением главной программы. На рис. 4.5 изображен один из таких файлов, импортированный в Microsoft Excel. Depth: Enter i; 183,268 00 : 1: 183,486.00: 1! 192,405.00 : 1: 192,482.00 i 1: 192.552.00i 1; 192,608.00 ! i 11 192,655.00 j 1 i 762,636.00 ; 1! 762,649.00 j 1: 762,663.00 : 1; 762,712.00": 1! 762,754.00 i t 1! 762,758.00 Leave 183,262.00 183,496.00 192,409.00 192,488.00 192,606.00 192,653.00 762,630.00 762,648.00 762,658.00 762,710.00 762,753.00 762,755.00 791,667.00 Return 2 TRUE 2 TRUE 1b0a0132 18a0021 TRUE TRUE 1b0a0132 TRUE 1c0a0132 18a0021 TRUE Caller ; CLOCK EXE+16bd i CLOCK. EXE+166 : CLOCK. EXE+16bd i CLOCK. EXE+1615 : CLOCK. EXE+355b ; CLOCK. EXE+3571 i CLOCK.EXE+3589 ; CLOCK. ЕХЕ+35Ы i CLOCK. EXE+35bd : CLOCK.EXE+3616 : CLOCK EXE+3626 i CLOCK.EXE+3637 : CLOCK.EXE+365a : Gdi32. : Gdi32 ; Gdi32. i Gdi32. ! Gdi32. i Gdi32. i Gdi32. : Gdi32. ! Gdi32. : Gdi32. : Gdi32. : Gdi32 : Gdi32 Calee dlllSetBkMode diiibeleteObject dlllSetBkMode dp'ejeteObject"' dlHCreateFontindirectW dliiSeiectObj'ect dlilGe'tTextExtentPointW .^petTexfExtentPointW [ dlllSeiectbbject dinpeleteObject diiiCreateFontindiVectW difiSe{ectObject dlllGetf extExtentExPointW I Parameter 1 1010056 60i004de 1010058 II "6l'l004de LdGF6lMTW*(135a3c0l 1010058 1 1010058 1010058 1010058 1b0a0132 'LOGFONt^(135a3cO| 1010058 Рис. 4.5. Протокол вызовов API, импортированный в Excel Для каждого вызова функции API, соответствующего одной строке на рис. 4.5, указывается уровень вложенности (пока — только 1), время входа и выхода из
260 Глава 4. Мониторинг графической системы Windows функции, возвращаемое значение, адрес вызывающей стороны и имя вызываемой функции, а также все передаваемые параметры. Одни данные выводятся в десятичном виде, другие — в шестнадцатеричной системе, а третьи — в виде мнемонических обозначений. Пока наша программа-разведчик запрограммирована только на регистрацию вызовов API. Можно добавить в нее код, который бы обеспечивал проверку параметров, проверку результата вызова и даже обнаруживал утечки памяти/ ресурсов. Для проверки параметров необходимо знать область допустимых значений каждого параметра. Например, функция SelectObject выбирает в контексте устройства действительный манипулятор объекта GDI — либо стандартного, либо созданного текущим процессом. Попытка выбрать недействительный манипулятор GDI или манипулятор, принадлежащий другому процессу, является тревожным признаком (особенно в Windows NT/2000). По тому же принципу проверяется и результат функции. Например, если функция SelectObject возвращает действительный манипулятор GDI, это является признаком ошибки при исключении объекта GDI из контекста, возможной причины утечки объектов GDI. Впрочем, обнаружение утечки объектов GDI — задача более сложная. Вам придется регистрировать все вызовы функций, создающих объекты, вместе со значением манипулятора и адресом вызывающей стороны. При удалении объекта GDI (функцией DeleteObject) его манипулятор исключается из списка сохраненных манипуляторов. При завершении программы манипуляторы, оставшиеся в вашем списке, принадлежат «потерянным» объектам GDI; программа должна вывести точную информацию об их создателях. Как обычно, отладочные файлы символических имен помогут преобразовать адреса в более содержательные имена. Отслеживание вызовов Win32 GDI В любой области Windows-программирования действует общее правило: справиться с работой легко, а выполнить ее блестяще — трудно. Конечно, наша программа мониторинга Win32 API приносит реальную пользу, но и она оставляет желать лучшего. Чтобы добиться главной цели — понимания всех аспектов работы GDI, — нам предстоит еще изрядно потрудиться. В действительности мы хотим ориентировать программу на мониторинг функций GDI и DirectDraw, которым, собственно, и посвящена эта книга. Это позволит нам использовать функции Win32 API, реализованные в KERNEL32.DLL и USER32.DLL, не беспокоясь о том, что они сами могут быть предметом мониторинга. Файл определения GDI API Прежде всего нам понадобится полный или почти полный ini-файл, который может читаться DLL-разведчиком и который описывает как можно большее количество функций GDI API.
Отслеживание вызовов Win32 GDI 261 Вся необходимая информация присутствует в заголовочных файлах Windows вместе с информацией, которая нас совершенно не интересует. Конечно, нам хотелось бы иметь автоматизированные средства для выборки из заголовочных файлов основных прототипов функций и приведения их к упрощенному формату. Простой, но специализированный анализатор заголовочных файлов С — неплохая тема курсовой работы для студентов, изучающих построение компиляторов. В результате получилась небольшая консольная Windows-программа, Skimmer, которая ищет в файлах ключевые макросы типа WINGDIAPI, WINUSERAPI, WINAPI и APIENTRY, стандартные признаки прототипов функций Win32 API. Убедившись в том, что найден действительно прототип функции, программа удаляет излишества типа CONST, FAR, IN и OUT, а также имена параметров. Остается лишь лаконичное определение функции Win32 API. Документированные функции, экспортируемые модулем GDI32.DLL, определяются в трех заголовочных файлах Windows 2000 DDK: inc\wingdi.h (стандартные функции GDI), inc\winddi.h (функции DDI пользовательского режима) и sec\ print\genprint\winppi.h (функции GDI для поддержки процессора печати EMF). В поставку Visual C++ включается только файл include\wingdi.h. Обработав эти три заголовочных файла программой Skimmer, мы получаем три ini-файла, практически готовые к использованию программой Pogy. Единственным исключением является функция EngGetFilePath DDI; ее придется слегка подправить вручную. Какой-то умник воспользовался при объявлении второго параметра записью WCHAR(*pDest)[MAX_PATH+l]; нашему простому анализатору это не по силам. Ниже приведен наименьший из трех ini-файлов, содержащий определения GDI API для процессора печати EMF. [winppi] HANDLE Gdi GetSpoolFi1eHandle(LPWSTR.LPDEVMODEW.LPWSTR) BOOL GdiDeleteSpoolFileHandle(HANDLE) DWORD Gdi GetPageCount(HANDLE) HOC GdiGetDC(HANDLE) HANDLE GdiGetPageHandle(HANDLE.DWORD.LPDWORD) BOOL GdiStartDocEMFCHANDLE.DOCINFOW*) BOOL Gdi PIayPageEMF(HANDLE,HANDLE,RECT*,RECT*,RECT*) BOOL Gdi EndPageEMF(HANDLE.DWORD) BOOL GdiEndDocEMF(HANDLE) BOOL Gdi GetDevmodeForPage(HANDLE.DWORD.PDEVMODEW*.PDEVMODEW*) BOOL Gdi ResetDCEMF(HANDLE.PDEVMODEW) [Types] HANDLE LPWSTR LPDEVMODEW BOOL DWORD HDC LPDWORD %v, D0CINF0W* RECT* PDEVMODEW* PDEVMODEW
262 Глава 4. Мониторинг графической системы Windows Как видно из приведенного листинга, файл определения API состоит из двух секций. В первой секции перечисляются упрощенные прототипы функций, а во второй — уникальные типы данных, используемые этими функциями. Для создания условий, в которых происходит большая часть графического вывода, Win32 GDI пользуется услугами модуля управления окнами (USER32.DLL). Модуль USER32 содержит ряд интересных функций API, за которыми тоже было бы полезно проследить, — BeginPaint, EndPaint, GetDC и т. д. Исходя из этого, мы воспользуемся программой Skimmer и сгенерируем файл winuser.ini из файла winuser.h. Декодер данных GDI Программа Skimmer перечисляет все типы данных, задействованные в некоторой группе функций API; эта информация используется DLL-разведчиком. Чтобы сохраненные данные лучше читались, нам понадобится специальный декодер для работы со специфическими типами данных GDI — такими, как HGDIOBJ, L0GF0NTW и даже DEVMODEW, если эта информация кого-нибудь заинтересует. Благодаря знанию структур данных GDI, полученному из главы 3, задача построения DLL декодера данных GDI сводится к обычному кодированию. Ниже приведена базовая структура DLL декодера GDI. class KGDIDecoder : public IDecoder { ATOM atom_HGDIOBJ; public: KGDIDecoderO { pNextDecoder - NULL; } virtual bool InitializedAtomTable * pAtomTable); virtual int Decode(ATOM typ. const void * pValue. char * szBuffer, int nBufferSize); }: bool KGDIDecoder:: Initial izedAtomTable * pAtomTable) { if ( pAtomTable==NULL ) return false: atom_HGDIOBJ = pAtomTable->AddAtom("HGDIOBJ"): return true: } // Поиск типов объектов GDI int KGDIDecoder::Decode(ATOM typ, const void * pValue. char * szBuffer. int nBufferSize) {
Отслеживание вызовов Win32 GDI 263 unsigned data = * (unsigned *) pValue; if ( (typ==atom_HDC) || (typ==atom_HGDIOBJ) || (typ—atomJPEN) || (typ==atom_HBRUSH) jj (typ==atomJPALETTE) jj (typ~=atom_HRGN) jj (typ—atomJFONT) ) { TCHAR temp[32]; unsigned objtyp - (data » 16) & OxFF; if ( ! Lookup( objtyp & 0x7F. Dic_GdiObjectType, temp) ) _tcscpy(temp, "HGDIOBJ"); if ( objtyp & 0x80 ) // Стандартный объект wsprintf(szBuffer, ,,(S*s)*x". temp, data & OxFFFF); else wsprintf(szBuffer. "(*s)*x\ temp, data & OxFFFF); return 4; } if ( typ==atom_PLOGFONTW ) { LOGFONTW * pLogFont - (LOGFONTW *) data; if ( ! IsBadReadPtr(pl_ogFont. sizeof(LOGFONTW)) ) { wsprintf(szBuffer. "& LOGFONTW{Sd.Sd Sws}". pLogFont->1fHeight. pLogFont->1fWidth. pLogFont->lfFaceName); return 4; } } // Необработанные типы return 0; } KGDIDecoder GDIDecoder; extern "C" declspecCdllexport) IDecoder * WINAPI Create_GDI_Decoder(void) { return & GDIDecoder; } Класс KGDIDecoder представляет собой простой декодер для типов данных GDI, созданный на основе базового класса IDecoder (по аналогии с реализацией СОМ- интерфейсов в классах СОМ). Функция Create_GDIJDecoder возвращает указатель на глобальный экземпляр KGDIDecoder (примерно то же самое делает фабрика класса для класса СОМ). Разведчик загружает DLL декодера GDI во время
264 Глава 4. Мониторинг графической системы Windows работы, получает адрес функции-создателя, вызывает ее, а затем инициализирует декодер методом KGDIDecoder->Initialize. Затем новые декодеры подключаются поверх старых и последовательно вызываются для преобразования полученных данных в текстовый формат до тех пор, пока запрос не будет обработан. Как было показано в главе 3, манипулятор объекта GDI в Windows NT/2000 состоит из трех частей: 8-разрядного признака уникальности, 8-разрядного идентификатора типа и 16-разрядного индекса. В нашей программе эта информация используется для выделения из манипулятора имени типа и индекса. Для указателей на структуру L0GF0NTW программа выводит данные логического шрифта: высоту, ширину и название гарнитуры. Перевод DLL-разведчика на новый декодер заметно улучшает качество выходных данных. Каждый манипулятор объекта GDI теперь снабжается пометкой типа. Теперь в выходных данных четко прослеживается последовательность действий: приложение создает объект GDI, выбирает его, использует, затем исключает из контекста и, наконец, удаляет. Реализация новых возможностей декодера позволит внести новые усовершенствования в процесс мониторинга API. Полный мониторинг API До настоящего момента мы подключались к цепочке обработки вызовов API, модифицируя каталог импорта модуля. Таким образом, при модификации каталога импорта модуля CLOCK.EXE для мониторинга функции GDI SelectObject перехватываются все вызовы, исходящие из этого модуля (если программа не додумается до косвенного вызова SelectObject с использованием GetProcAddress). Однако многие компоненты окон (например, заголовок, название, меню и значки) не прорисовываются непосредственно вашей программой — подобные графические задачи решаются стандартной функцией окна заранее определенным способом. В программах MFC, использующих DLL-версию библиотеки, многие графические функции GDI вызываются из MFC DLL (например, MFC42.DLL или MFC42D.DLL для MFC версии 4.2). Если вы хотите отслеживать графические вызовы из всех этих модулей посредством модификации каталога импорта, вам придется перечислить их в ini- файле отслеживаемой программы. В этом случае DLL-разведчику придется перебирать все модули и править их каталоги импорта. Но даже перечисление всех модулей процесса еще не гарантирует полного успеха. Во время работы программы могут загружаться новые модули (например, COM DLL), о которых вы не знали заранее. А если этого недостаточно, учтите, что при вызове из GDI32 экспортируемых функций GDI32 каталог импорта вообще не используется. В этом случае происходит прямой внутримодульный (in- tramodule) вызов; конструкции типа call [ impSelectObj] в нем не участвуют. Для полного мониторинга вызовов API на уровне процесса (то есть перехвата всех обращений изнутри и извне модуля, в котором находится реализация; из модулей уже загруженных и тех, которые будут загружены потом) приходится модифицировать саму реализацию API. Например, если найти адрес функции SelectObject в GDI32.DLL и модифицировать саму функцию, все вызовы Select- Object будут проходить через ваш код.
Отслеживание вызовов Win32 GDI 265 Модифицировать программу нетрудно. Значительно труднее сделать так, чтобы после модификации приложение работало так же, как раньше. Как было показано в разделе «Отслеживание вызовов функций Win32 API», мы хотим вставить в функцию несколько строк ассемблерного кода, чтобы вызов функции API приводил к автоматической передаче управления нашему входному обработчику. После выхода из обработчика исходная функция API должна выполняться в точности с теми же значениями регистров. После завершения функции API перед возвращением управления вызывающей стороне должен быть вызван наш выходной обработчик. Главная проблема заключается в том, что из-за модификации точки входа в функцию API при завершении входного обработчика управление нельзя передать модифицированному входу функции. У этой проблемы существует два основных решения. В первом случае входной обработчик восстанавливает прежнее состояние точки входа, чтобы при возвращении из него управление передавалось исходной реализации API. Такое решение идеально подходит для одноразовой регистрации, но где же вносить исправления для последующих вызовов? Наиболее естественно было бы делать это в выходном обработчике, но это означает, что на время выполнения функции API мы не сможем обрабатывать рекурсивные вызовы, а также вызовы из других программных потоков. Таким образом, мы приходим ко второму решению — не восстанавливать модифицированный участок, а переместить точку входа в функцию. При модификации изначального входа в функцию API как минимум 5 байт приходится выделить под инструкцию безусловного перехода в функцию-заглушку, что приводит fc порче нескольких инструкций. Поврежденные инструкции можно скопировать в буфер, находящийся внутри DLL-разведчика, и поставить после них команду перехода к первой инструкции после поврежденного участка. Когда все это будет сделано, остается лишь разрешить входному обработчику DLL-разведчика передать управление на перемещенные инструкции. Следующий пример поможет лучше разобраться в происходящем. Рассмотрим несколько начальных инструкций функции Sel ectObject на ассемблере и в машинных кодах. _Select0bject@8: 55 push ebp 8В ЕС mov ebp. esp 51 push ecx 83 65 FC 00 and dword ptr [ebp-4]. 0 _Select0bject@8+8: Пять байт, начинающихся с адреса _Select0bject@8, понадобятся для нашей маленькой хирургической операции; это приведет к порче 4 инструкций общим объемом 8 байт. Мы сохраняем первые 8 байт Sel ectOb ject@8 и записываем по этому адресу инструкцию безусловного перехода в заглушку. _Select0bject@8: е9 хх хх хх хх jmp Stub_Select0bject@8 90 nop 90 nop 90 nop _Select0bject@8+8:
266 Глава 4. Мониторинг графической системы Windows Обратите внимание: на самом деле мы используем лишь 5 байт, но для того, чтобы программа нормально работала, в нее включаются три пустые инструкции пор. Код заглушки выглядит следующим образом: Stub_SelectObject@8: push index_selectobject jmp ProxyProlog New_Select0bject@8: push ebp mov ebp. esp push ecx and dword ptr [ebp-4], 0 jmp _Select0bject@8+8 Обратите внимание на пару любопытных подробностей. Во-первых, по адресу Stub_Select0bject@8 находится точно такой же код, как и в нашем предыдущем решении с модификацией каталога импорта. Во-вторых, функция New_ Sel ectObject@8 воссоздает начало функции _Select0bject@8 перед модификацией. Эти совпадения позволяют заново использовать весь код, задействованный в решении с модификацией каталога импорта, за одним исключением: мы должны присвоить pFuncTable->m_func[index_se1ectobject].f_oldaddress значение New_Select- 0bject@8, чтобы при возвращении из ProxyProlog выполнение проходило по тому же пути, что и при использовании исходной функции API. Впрочем, мы еще не рассмотрели самую сложную сторону решения с перемещением кода — внешне простую задачу вычисления количества перемещаемых байт. Мы уже выяснили, что минимальное количество равно 5 байтам, но определить точную величину нелегко, поскольку копироваться должны только целые инструкции. Для процессоров Intel не существует простых правил вычисления длины инструкции по нескольким первым байтам. В результате постоянного добавления новых инструкций в исходный набор 8086 ситуация невероятно усложнилась. Программа вычисления количества байт, работающая для целых инструкций размером не менее 5 байт, фактически представляет собой «скелет» дизассемблера. Во времена Win 16 задача решалась гораздо проще, поскольку все экспортируемые функции имели одинаковый пролог. С появлением 32-разрядного кода и компиляторов с улучшенной оптимизацией (а особенно для процессоров с несколькими конвейерами обработки инструкций) предсказать, с какой инструкции начинается функция, стало невозможно. Попутно возникает другая проблема — не все инструкции можно переместить простым копированием. Команды передачи управления (например, jmp) часто используют относительные адреса, зависящие от текущего местонахождения команды в памяти. Чтобы переместить такую команду, вам придется обновить относительное смещение. В нашей текущей реализации прологи функций с переходами по относительному смещению не поддерживаются. В статической библиотеке Patcher.lib, подключаемой к Diver.dll, реализована модификация с перемещением. Чтобы сообщить, что вы хотите использовать перехват на уровне процесса, задайте одинаковые имена вызывающего и вызываемого модуля. Например, следующий ini-файл обеспечивает перехват на уровне процесса для функций GDI32, перечисленных в wingdi.ini, и функций USER32, перечисленных в winuser.ini:
Отслеживание вызовов Win32 GDI 267 [Module] Gdi32.cn 1. Gdi32.DLL. wingdi User32.dll. User32.DLL, winuser При перехвате на уровне процесса всплывают многочисленные функции GDI API, вызываемые из других системных DLL — таких, как USER32.DLL, COMDLG32.DLL, COMCTL32.DLL, OLE32.DLL и даже из самой GDI32.DLL Вы увидите, что USER32.DLL обращается к GDI32.DLL для выполнения графических операций, что GDI32.DLL объединяет вызовы функций API в вызовы обобщенных функций или наоборот, разбивает сложные функции API на более простые. Таким образом, вы сможете наблюдать за представлением «из-за кулис». Небольшой пример приведен на рис. 4.6. ШШШШ1Ш ^Щ De^h Щт п ЯВ 2! fill 2! ИИ 2 SB 2i ЯВ 2] lijf 2l ^Щ 2! ■j з? |iii 3! ЯШ 3! ■И з1' ЯИ зг ШЩ 3 SB ^ ■l 2! ШЩ 2: |Щ 2| Enter 6271966 "6272098" ..__ 6272458! 6272490! "627252Б? '6272529: 6272534? 6272545! 6272594! 6272616? 6272629г 62729035 6272916! 6272926' "6272967" '62729681 "62729691 :р:ШшШ1р«>Яу012 jfiPjjjj Leaver Return "6272992!" HBITMAP(520504c8) "Й721"7бГ'(Н_с17 "Й72457ТнВ1ТМАР(5205Ь4с8) 6272486И 6272526; (SHBITMAP)f "6272528"! WHITE "6272532! BLACK 6272966 ;96 6272593:1 6272607! (НВГГМАР)4с8 6272626! (SHPALEtfE)b ■'6272902!96 * 6272915! (SHPALEtfEjii) 6272925!" (HBITMAP)4c8 6272966!TRUE " 6272968 Г BLACK "6272969:' WHITE " 6272983]. (HBITMAP)4c8 ^^ШШг^^'^'^'Л''^^^^^^^^ Caller "CARDS. dii+17e9' USER'32.d'li+c60i" USER32.'dli+c650 ' USER32.dll+c663 USER32.dll+c9c2 USER32.dii+c9el' "USER32.dil+c9fi ■'uSER32.dii+ca1e Gbl32.DLL+6baa • GDI32.DLL+6bbb ■■'GDi32'.DLL-»6bd7" "G'DI32.''D'LL46'c6a' "GDi32.DLL+6cic !"GDJ32'.DLL-»6c25 : GDI32.DLL46c32 ruSER32.'dii+ca3f'" ru'SER32!dii+ca4a"' ;'USER32!'dii+ca62 ' ШШ^ДЯИ Caiee ]^u8ei32.dH!LoadBjtmapA' zn'^^^^^z~zzziz j_Gdi32.d]j!Crea^ 1 user32dll!ReleaseDC ? Gdi32.dli!SelectObject ; Gdi'32.dii!SetBkColdr j'Gdi32dlllSetfextCoior' ' ! Gdi32. dlHSetbiBits j Gdi32.dll!SaveDC j Gdi32.dll!SelectObject ZJ^!^:M^^!f^^^.JlZ^ ..... ... rGdi32!dliis^lBiY8Tobewce 7 Gdi32! diiiSejectPaiette j Gdi32.dliiSelect6bject "j Gdi32.dil!RestoreDC rGdi32"diiisette'xtCoior I GdQZdVliSetBkCol'or 1 Gdi3idll!Se'l'ectObjiBct $ЩА ||| 111 III 111 ill 111 111 111 ||| III 111 111 ill Рис. 4.6. Полный мониторинг вызовов API дает представление о реализации LoadBitmap Вызовы API, показанные на рисунке, отсортированы по порядку их обработки. В первом столбце указывается уровень вложенности; во втором — возвращаемое значение; в третьем — адрес вызывающей стороны и в четвертом — имя вызываемой функции. Значения параметров не показаны для экономии места. Обратите внимание: непосредственно сгенерированные файлы сортируются не по времени входа, а по времени выхода. Для упрощения анализа данных использованы средства сортировки Excel. Если внимательно присмотреться к рисунку, вы поймете, что перед вами «секретная» реализация функции LoadBitmap. Функция LoadBitmap поддерживается диспетчером окон (USER32.DLL) и предназначается для загрузки растра в ап- паратно-зависимом формате GDI. Однако из документации мы не знаем, как реализована эта функция. Из рисунка видно, что LoadBitmapA (ANSI-версия Load- Bitmap) вызывает несколько функций GDI для преобразования аппаратно-неза- висимого растра в аппаратно-зависимый растр. Функция CreateCompatibleBitmap создает новый DDB-растр, а функция SetDIBits выполняет преобразование. Из рисунка также видно, как функция SetDIBits реализована в GDI — она сводится к вызову SetDIBitsToDevice.
268 Глава 4. Мониторинг графической системы Windows Отслеживание СОМ-интерфейсов DirectDraw DirectDraw API, как и остальные интерфейсы DirectX API, создан на основе технологии Microsoft COM (Component Object Model). Функциональные возможности DirectDraw предоставляются пользователю в виде нескольких СОМ-интерфейсов — например, IDirectDraw и IDirectDrawSurface. СОМ-интерфейс определяется как группа семантически связанных функций (или методов). Например, методы интерфейса IDirectDrawSurface предназначены для работы с поверхностями DirectDraw, а методы интерфейса IDirectDraw- Clipper управляют отсечением поверхностей DirectDraw. Давайте посмотрим, как организовать мониторинг этих методов. Таблица виртуальных функций Методы СОМ-интерфейса вызываются через интерфейсный указатель, который фактически представляет собой указатель на объект C++ с неизвестным представлением данных. Единственное, что известно клиентской стороне, — то, что СОМ-объект начинается с указателя на таблицу виртуальных функций. Эта таблица содержит указатели на функции, реализующее все методы интерфейса и следующие в определенном порядке. Все СОМ-интерфейсы являются производными от интерфейса IUnknown, в котором определяются три метода: Query- Interface, AddRef и Release. Это означает, что первые три указателя в таблице виртуальных функций СОМ всегда реализуют эти три метода. Обычно таблица виртуальных функций C++ или СОМ генерируется компилятором в глобальной области данных, доступной только для чтения или для чтения/записи. Прослеживается аналогия с внутренними переменными, используемыми каталогом импорта модуля для хранения адресов импортируемых функций. С технической точки зрения перехватывать вызовы методов СОМ-интерфейса или DirectDraw-интерфейса совсем несложно. Все, что для этого необходимо, — найти адреса всех интересующих нас таблиц виртуальных функций, а затем заменить хранящиеся в них указатели на функции указателями на заглушки DLL- разведчика. Получить адрес таблицы виртуальных функций для обычного СОМ-интерфейса просто. Найдите идентификаторы GUID класса и интерфейса, вызовите CoCreatelnstance — и реализация СОМ операционной системы загрузит нужный сервер СОМ, создаст СОМ-объект и вернет вам интерфейсный указатель. Первые 4 байта блока, на которые ссылается интерфейсный указатель, и дадут вам искомый адрес таблицы виртуальных функций. Большинство интерфейсов DirectDraw не создается стандартным вызовом CoCreatelnstance. Например, создать интерфейсный указатель для IDirectDrawSurface можно лишь одним способом — вызовом метода CreateSurface для интерфейса IDirectDraw. В контексте DirectDraw это абсолютно логично, поскольку поверхности DirectDraw всегда находятся под управлением объектов DirectDraw. Разведывательная библиотека DLL должна оказывать минимальное воздействие на работу системы. Следовательно, создавать объект DirectDraw и поверхность DirectDraw лишь для получения таблицы виртуальных функций IDirectDrawSurface было бы нежелательно. Альтернативное решение — получать данные
Отслеживание СОМ-интерфейсов DirectDraw 269 таблиц виртуальных функций автономно, в отдельной программе, сохранять их в ini-файле и затем использовать в процессе отслеживания. Программа Query- DDraw действует именно так. Она пытается создать как можно больше различных интерфейсных указателей DirectDraw и регистрирует адреса таблиц виртуальных функций, количество методов, а также имя и GUID интерфейса. В C++ определить количество методов класса практически невозможно, однако программа DirectDraw, написанная на С, должна знать это количество, поскольку таблица виртуальных функций имитируется при помощи массива указателей на функции. В следующем фрагменте показано, как получить необходимую информацию для интерфейса IDirectDraw. #define СINTERFACE #include <ddraw.h> IDirectDraw * lpdd; HRESULT hr - DirectDrawCreateCNULL. & lpdd. NULL); Dumplnterface("IID_IDirectDraw", IID_IDirectDraw, lpdd->lpVtbl. sizeof(*lpdd->lpVtbl) ); Перед включением ddraw.h, заголовочного файла DirectDraw, определяется макрос CINTERFACE. Тем самым активизируется определение СОМ-интерфейсов в стиле С, где таблица виртуальных функций имитируется массивом указателей на функции, а указатель на таблицу виртуальных функций хранится в одном из полей структуры (lpVtbl). Определение СОМ-интерфейсов в стиле С позволяет использовать функцию sizeof(*lpdd->1pVtbl) для вычисления размера таблицы виртуальных функций, а следовательно, — и количества функций в таблице. Вызов метода C++ несколько отличается от обычного вызова функции в С или Pascal. Вызываемому методу неявно передается дополнительный указатель на текущий объект (так называемый указатель this). Хотя компилятор C++ поддерживает возможность передачи указателя this в регистрах процессора для повышения быстродействия, СОМ-интерфейсы и интерфейс DirectDraw всегда передают указатель this в стеке. Остается лишь сообщить функции вывода параметров DLL-разведчика о наличии дополнительного параметра. Определение DirectDraw API Следующая задача — сгенерировать для всех методов DirectDraw ini-файл в формате управляющей программы Pogy. Для этого в простейший анализатор заголовочных файлов С, Skimmer, необходимо внести несколько изменений. Во-первых, начало объявления СОМ-интерфейса должно определяться по префиксу DECLAREINTERFACEj во-вторых, программа должна обрабатывать макросы STDMETHOD и STDMETHOD_ для восстановления типа возвращаемого значения и имени функции; в-третьих, макросы THIS и THIS_ также должны обрабатываться для передачи указателя this в качестве дополнительного параметра. Ниже приведена отредактированная версия полного, точного и недвусмысленного определения DirectDraw API. [ddraw] HRESULT DiYectDrawEnumerateW(LPPENUMCALLBACKW.LPVOID)
270 Глава 4. Мониторинг графической системы Windows HRESULT DirectDrawEnumerateA(LPPENUMCALLBACKA.LPVOID) HRESULT Di rectDrawEnumerateExW(LPPENUMCALLBACKEXW,LPVOID.DWORD) HRESULT DirectDrawEnumerateExACLPPENUMCALLBACKEXA.LPVOID.DWORD) HRESULT DirectDrawCreate(GUID*.LPDIRECTDRAW*.Iunknown*) HRESULT DirectDrawCreateClipper(DWORD.LPDIRECTDRAWCLIPPER*. Iunknown*) [COM_ddraw] 728405aO 7283Ш8 23 {6cl4db80-a733-llce-a5-21-00-20-af-0b-e5-60} 11D_IDirectDraw 728408eO 728318a8 24 {b3a6f3e0-2b43-llcf-a2-de-00-aa-00-b9-33-56} IID_IDirectDraw2 728407a0 7283Ш8 28 {9c59509a-39bd-lldl-8c-4a-00-c0-4f-d9-30-c5} IID_IDirectDraw4 72840940 7282f034 36 {6cl4db81-a733-llce-a5-21-00-20-af-0b-e5-60} IID_IDi rectDrawSurface [IDirectDraw] HRESULT QueryInterface(THIS.REFIID.LPVOID*) ULONG AddRef(THIS) ULONG Release(THIS) ULONG Compact(THIS) HRESULT Createdipper(THIS.DWORD.LPDIRECTDRAWCLIPPER*.Iunknown) HRESULT CreatePalette(THIS.DWORD,LPPALETTEENTRY. LPDIRECTDRAWPALETTE*.Iunknown) HRESULT CreateSurface(THIS.LPDDSURFACEDESC. LPDIRECTDRAWSURFACE*.Iunknown) В первой секции перечисляются обычные функции, экспортируемые из DDRAW.DLL Эта библиотека экспортирует довольно много функций. Здесь перечислены функции, документированные в ddraw.h; другие функции (такие, как DIlGetClassObject) принадлежат к числу стандартных экспортируемых функций СОМ; третьи документируются в других заголовочных файлах или вовсе не документируются. Во второй секции приведена информация о СОМ-интерфейсах, сгенерированная программой QueryDDraw. Для каждого СОМ-интерфейса DirectDraw указывается адрес таблицы виртуальных функций, адрес первой виртуальной функции (Querylnterface), количество методов, GUID и имя интерфейса. Эта секция строится заново для каждой ОС и установленных обновлений Service Packs. В дальнейших секциях подробно описываются прототипы методов (по одной секции на каждый интерфейс). Выше приведена секция лишь для интерфейса IDirectDraw. В интерфейсе IDirectDraw2 по сравнению с IDirectDraw добавляется всего один новый метод, а в IDirectDraw4 интерфейс IDirectDraw2 дополняется двумя новыми методами. Модификация таблицы виртуальных функций Содержимое файла определений DirectDraw API читается управляющей программой и передается DLL-разведчику. Разведчик строит таблицу интерфейсов, в которой для каждого интерфейса указывается имя, GUID, адрес таблицы виртуальных функций, адрес Querylnterface и количество методов. В процессе ини-
Отслеживание системных вызовов GDI 271 циализации он загружает COM DLL (в данном случае ddraw.dll), находит все перечисленные таблицы виртуальных функций и убеждается в том, что ее первый элемент совпадает с известным нам адресом метода Querylnterface. Затем DLL-разведчик вызывает следующую функцию для модификации всех перечисленных методов DirectDraw: BOOL HackMethod(uns1gned vtable, int n, FARPROC newfunc) { DWORD cBytesWritten; WnteProcessMemory(GetCurrentProcess(), (LPVOID) (vtable + n * 4). & newfunc. sizeof(newfunc). &cBytesWritten); return cBytesWritten — sizeof(newfunc); } Параметр newfunc указывает на функцию-заглушку, описанную в разделе «Отслеживание вызовов функций Win32 API». После модификации все работает так же, как и при правке каталога импорта. Ниже приведен маленький пример для интерфейса IDirectDraw. HRESULK О). ddraw.dll!SetCooperativeLevel. 0x893b28. HWND(800cc). 17 HRESULK0). ddraw.dll!SetDisplayMode. 0x893b28. 640. 480. 24 HRESULT(O). ddraw.dllICreateSurface. 0x893b28. LPDDSURFACEDESC(12fe54). LPDIRECTDRAWSURFACE*(12ff2c). Iunknown*(0) ULONG(O). ddraw.dll .'Release. 0x893b28 Как видно из приведенной последовательности вызовов, после создания объекта DirectDraw приложение вызывает методы SetCooperati veLevel, SetDi spl ay- Mode и CreateSurface интерфейса IDirectDraw, после чего уничтожает объект методом Release. Первый параметр, 0х893Ь28, представляет собой указатель this. Как видите, декодер типов данных DirectDraw приносит несомненную пользу. Отслеживание системных вызовов GDI От рассмотрения трех разных типов отслеживания вызовов API мы переходим к тому, о чем не пишут в документации. Да, речь идет о системных функциях GDI, интерфейсе между клиентом GDI пользовательского режима и графическим механизмом режима ядра. Как упоминалось выше, DirectDraw, Direct3D и OpenGL используют GDI для обращения к служебным функциям графического механизма. Из материала главы 2, посвященной архитектуре графической системы Windows NT/2000, следует, что системные функции графической системы играют очень важную роль — они отвечают за передачу запросов графического вывода
272 Глава 4. Мониторинг графической системы Windows из пользовательского режима графическому механизму режима ядра и драйверам устройств. Однако системные функции (и особенно системные функции графической системы) в официальной документации не упоминаются. В главе 2 была представлена программа SysCall, предназначенная для поиска вызовов системных функций в клиентских библиотеках DLL подсистем Win32 — а именно в GDI32.DLL, USER32.DLL и KERNEL32.DLL С помощью отладочных файлов символических имен программа перечисляет все вызовы системных функций с индексами, количеством параметров, адресами и символическими именами. Она даже может вывести данные о таблице системных функций в адресном пространстве ядра. Но поскольку обработчики системных функций в графическом механизме соответствуют вызовам функций в пользовательском режиме, нам будет гораздо проще следить за пользовательской стороной этого недокументированного интерфейса. Листинг, сгенерированный программой SysCall, не совсем отвечает нашим потребностям. Необходимо внести некоторые усовершенствования, чтобы программа генерировала список прототипов функций. В отличие от других модификаций, мы хотим, чтобы вместе с прототипами выводились и адреса этих функций. В противном случае программе-разведчику во время работы придется использовать отладочные символические имена, что сделает ее менее универсальной. В программу SysCall была добавлена новая команда меню, GDI32 system calls for Роду (Вызовы системных функций в GDI32 для Pogy). Ниже приведена лишь небольшая часть списка вызовов системных функций в GDI32.DLL [gdisyscall] D NtGdiCreateEllipticRgn(D.D.D.D). 77F725AB. 1020 D NtGdiDdGetBltStatus(D.D), 77F726A7. 1047 D NtGdiGetDeviceGammaRamp(D.D). 77F728D7. 10a8 D NtGdiSTROBJ_dwGetCodePage(D). 77F72CB7. 1274 D NtGdiGetTextExtentExW(D.D.D.D,D.D,D,D). 77F43C51. 10c9 D NtGdiGetColorAdjustment(D.D), 77F728BB. lOal D NtGdiFlushO. 77F413F9, 1093 D NtGdiDdSetOverlayPosition(D.D.D). 77F7274F, 105d D NtGdiPATHOBJJ)EnumCllpLines(D.D.D). 77F72CD3. 1279 D NtGdiEngCreateBitmap(D,D.D.D.D,D). 77F4B5CD. 1240 D NtGdiColorCreatePalette(D.D.D.D.D.D). 77F7258F, 1011 D NtGdiDdDestroySurface(D.D). 77F5AAB2. 1041 D NtGdiDdRenderMoComp(D.D), 77F72717. 1057 Возможно, вы заметили, что мы не располагаем точной информацией о типах параметров и возвращаемых значениях. Единственное, что нам известно, — это количество параметров, которое определяется по количеству байт, извлекаемых из стека при возвращении. Поэтому мы просто помечаем каждый параметр типом D (сокращение от DWORD) и откладываем их замену более осмысленными типами до появления дополнительной информации. В DLL-разведчика приходится внести ряд изменений. Во-первых, адрес функции известен, поэтому ухищрения типа GetProcAddress для Win32 API не понадобятся. Однако программа должна убедиться в том, что по этому адресу находится код в формате вызова системной функции:
Отслеживание системных вызовов GDI 273 NtGdi_SysCall_xx mov eax. function_index NtGdi_SysCall_xx+5: lea edx. [esp+4] int 0x2e ret parameterjnumber * 4 В принципе можно было бы воспользоваться методом модификации с перемещением, использованным для перехвата вызовов API на уровне процесса, но нетрудно заметить, что инструкции после NtGdi_SysCall_xx+5 существуют в ограниченном количестве вариантов — по одному для каждого количества параметров. Количество параметров, передаваемых при вызове системных функций GDI, лежит в пределах от 0 до 15. Следовательно, нам понадобится только 16 функций для замены кода, следующего после первой инструкции (сохранения индекса). После модификации код принимает следующий вид: NtGdi_SysCall_xx mov eax. functiorMndex NtGdi_SysCall_xx+5: jmp Stub_NtGdi_SysCall_xx Stub_NtGdi_SysCall_xx push func_id jmp ProxyProlog При возвращении из ProxyProlog мы должны передать управление одной из функций, в которых и происходит непосредственный вызов системных функций: // Для системных функций с двумя параметрами declspec(naked) void SysCall_08(void) { _asm lea edx, [esp+4] _asm int 0x2e _asm ret 0x08 } Перехват системных вызовов осуществлялся бы гораздо проще, если бы мы не использовали базовые функции разведчика ProxyProlog, ProxyEntry, ProxyEpilog и ProxyExit. Мониторинг графических системных функций — дело весьма увлекательное, поскольку он сильно отличается от обычного мониторинга функций API. Подробные описания на эту тему редко встречаются в книгах и журналах. А отслеживать вызовы GDI API вместе с вызовами системных функций еще интереснее. Не исключено, что этим еще никто не занимался. GDI API представляет собой интерфейс между приложением и механизмом поддержки ОС пользовательского режима, а графические системные функции образуют интерфейс между GDI и графическим механизмом режима ядра. Таким образом, мы следим за обеими сторонами клиентской DLL GDI GDI32.DLL Различия между ними наглядно показывают, что же именно происходит в клиентской DLL GDI. В табл. 4.1 представлена отредактированная версия протокола с одновременным мониторингом вызовов GDI и графических системных функций.
274 Глава 4. Мониторинг графической системы Windows Таблица 4.1. Пример протокола вызовов функций Win32 GDI и системных функций Уровень вложенности Результат Вызов функции 1 1 1 1 2 1 1 1 2 1 3 2 2 (SHF0ND21 WHITE 0 BLACK TRUE TRUE TRUE (SHBRUSH)IO (SHPENU7 (SHPEN)17 (HF0NT)3el (HF0NT)3el TRUE TRUE 3 2 1 2 1 HBITMAP(3d9) HBITMAP(3d9) HBITMAP(3d9) TRUE TRUE Se1ectObject((HDC)407, (HF0NT)3el) SetBkColor((HDC)305.a9c8a2) SetTextAlign((HDC)305,0) SetTextColor((HDC)305.BLACK) NtGdiDeleteObjectAppC(HPEN)4d9) De1ete0bject((HPEN)4d9) Delete0bject((HBRUSH)3e8) GetStockObject(O) NtGdiGetStock0bject(7) GetStock0bject(7) NtGdiHfontCreate(0xl2f8c0,0x164,0x0,0x0.0x137468) CreateFontInd1rectExW(ENUML0GF0NTEXDVW*(l2f8c0)) NtGdi GetWi dthTable((HDC)407,Oxb,0xl37b28.0x106. 0xl37d3e,0xl378b8) GetTextExtentPointW((HDC)407,LPCWSTR(1135a394),ll. LPSIZE(12fac4)) NtGdi CreateCompatibl eBi tmap( (HDO407, 0x20, 0x24) CreateCompatibleBitmap((HDC)407,32,36) CreateDiscardableBitmap((HDC)407,32.36) NtGdiRectangle((HDC)2e9.0x60,0x3.0x64,0x7) Rectangle((HDC)2e9,96,3,100,7) Помните о том, что функции с более высоким уровнем вложенности вызываются функциями более низкого уровня, следующими в протоколе после них. Полученные протоколы подтверждают некоторые факты, упоминавшиеся в предыдущих главах. О Часть структуры данных контекста устройства реализуется в пользовательском режиме, поэтому простые запросы к контексту легко и эффективно обрабатываются в пользовательском режиме без обращения к системным функциям режима ядра. О Таблица объектов GDI находится под управлением графического механизма, поэтому при создании и уничтожении объектов вызываются системные функции. Кисти и прямоугольные регионы занимают особое место — GDI
Отслеживание интерфейса DDI 275 кэширует удаленные объекты для повторного использования. Мы видим, что при удалении HPEN вызывается функция NtGdi Del eteObjectApp, тогда как удаление HBRUSH не всегда приводит к вызову системной функции. О CreateDiscardableBitmap — это просто CreateCompatibleBitmap. О Графические команды обычно напрямую транслируются в системные функции. О Системные функции GDI работают практически с теми же типами данных, что и функции Win32 GDI API. В сущности, у вас появился отличный инструментарий для самостоятельных исследований GDI. Вы можете спланировать собственный эксперимент в интересующей вас области GDI API, установить соответствующие параметры мониторинга, провести тест и проанализировать результаты. Отслеживание интерфейса DDI В предыдущих четырех разделах этой главы мы подробно рассмотрели возможности наблюдения за графической системой Windows в пользовательском режиме. Теперь мы можем отслеживать как входной, так и выходной интерфейс GDI32. А сейчас пора переходить на новую «территорию» — к графическому механизму режима ядра. DLL подсистем Win32 обращаются к графическому механизму посредством вызова системных функций. В главе 2 была представлена программа SysCall, которая выводит полный список вызовов системных функций (как графических, так и относящихся к управлению окнами). Списки функций GDI32 и USER32, использующих системные вызовы, практически полностью совпадают со списком обработчиков системных функций WIN32K.SYS. Единственное различие состоит в том, что некоторые системные функции не вызываются в системных DLL пользовательского режима. Мониторинг графических системных функций режима ядра приносит не так уж много новой информации, поскольку мы можем легко отслеживать системные вызовы в пользовательском режиме. Конечно, у отслеживания этого интерфейса со стороны ядра есть и свои преимущества — оно осуществляется на уровне всей системы, а не на уровне конкретного процесса. С другой стороны, подобные эксперименты слишком сильно отражаются на работе всей системы. Самым интересным графическим аспектом режима ядра является интерфейс DDI между графическим механизмом и драйверами устройств. В главе 2 уже упоминалось о том, что графическому механизму приходится изрядно потрудиться над преобразованием вызовов GDI в вызовы DDI, поскольку они находятся на разных уровнях абстракции. В разделе «Драйверы принтеров» главы 2 был представлен простой драйвер принтера, генерирующий документы HTML вместо принтерных команд. HTML-страницы содержат списки вызовов DDI с ше- стнадцатеричными дампами параметров и 24-битные цветные растры, воспроизведенные с разрешением 96 dpi. Наш простой драйвер HTML хорошо подходит для экспериментов с интерфейсом DDL Впрочем, этот вариант ограничивается драйвером принтера и фиксированным набором параметров. Конечно, желательно иметь более общее решение, которое
276 Глава 4. Мониторинг графической системы Windows бы позволяло следить за всеми графическими драйверами, экранами, принтерами, плоттерами и даже факсами. В главе 3 чрезвычайно подробно рассматриваются основные внутренние структуры данных GDI и графического механизма. В частности, там говорилось о том, что объект ядра каждого контекста устройства содержит указатель на структуру PDEV, содержащую всю информацию о физическом устройстве для графического механизма. Структура PDEV создается после загрузки драйвера экрана при вызове функций DrvEnableDriver, DrvEnablePDEV и, наконец, DrvCompletePDEV. Следовательно, PDEV содержит всю информацию, полученную от драйвера графического устройства при вызове этих функций, включая и точки входа DDL В Windows 2000 последний блок данных структуры PDEV содержит 89 указателей на функции; в Windows NT 4.0 он может содержать до 65 указателей на функции. Работать с указателями на функции при мониторинге вызовов API очень просто. Нам уже приходилось модифицировать указатели в таблице импорта DLL и в таблицах виртуальных функций С++/СЮМ. Массив указателей на функции в структуре PDEV имеет много общего с таблицей виртуальных функций. Среди этих 89 указателей довольно многие не используются, остаются зарезервированными или обычно не реализуются драйвером устройства. Даже мониторинг 20-30 вызовов DDI означал бы, что мы неплохо справились с поставленной задачей. Учитывая, что это число совсем невелико по сравнению с тремя сотнями функций GDI, мы могли бы просто написать 20-30 промежуточных функций DDI вместо того, чтобы разбираться с ассемблерными командами в адресном пространстве ядра. Программа для мониторинга вызовов GDI (как и для мониторинга функций API в пользовательском режиме) состоит из двух компонентов. Драйвер режима ядра загружается в адресное пространство ядра, включается в цепочку обработки вызовов DDI, получает информацию о параметрах и передает ее управляющей программе. Управляющая программа пользовательского режима запускает и завершает работу драйвера, передает ему команды и получает перехваченные данные. Драйвер режима ядра, DDISpy.SYS, представляет собой слегка расширенную версию драйвера Periscope, использованного в главе 3. Драйвер Periscope обрабатывал всего одну команду ввода-вывода для чтения блока данных из адресного пространства ядра, что так помогло нам при исследованиях внутренних структур данных GDI. DDISpy обрабатывает четыре команды ввода-вывода, перечисленные в табл. 4.2. Таблица 4.2. Команды ввода-вывода DDISpy Код команды Параметры Функция DDISPYREAD Адрес, размер То же, что и у Periscope, — чтение блока данных из адресного пространства ядра DDISPYSTART Адрес таблицы Модификация содержимого таблицы функ- функций DDI, ций (начало мониторинга вызовов DDI) количество
Отслеживание интерфейса DDI 277 Код команды Параметры Функция DDISPYEND Адрес таблицы Восстановление содержимого таблицы функ- функций DDI, ций (конец мониторинга вызовов DDI) количество DDISPYREPORT Размер Передача собранной информации управляющей программе Для каждой функции DDI создается соответствующая промежуточная функция, которая регистрирует данные, вызывает исходную функцию и, возможно, регистрирует ее возвращаемое значение. Хронометраж в данном случае не производится, поскольку общее быстродействие GDI мы измеряем в пользовательском режиме. Мы также не беспокоимся о сохранении регистров, зная, что по правилам DDI регистры используются только для возвращения значения функции. Словом, никакого ассемблера — сплошной код С. Ниже приведена самая интересная часть DDISpy — промежуточные функции. typedef struct PFN рРгоху; PFN pReal; PROXYFN; <YFN DDI_Proxy [] = // Перечисление в г (PFN) DrvEnablePDEV, (PFN) DrvCompletePDEV, (PFN) DrvDisablePDEV. (PFN) DrvEnableSurface, (PFN) DrvDisableSurface. (PFN) NULL. (PFN) NULL. (PFN) DrvResetPDEV. NULL. NULL. NULL. NULL. NULL. NULL. NULL. NULL. void DDISpy_Start(unsigned fntable. int count) { unsigned * pFuncTable = (unsigned *) fntable; // Очистить буфер for (int i=0; i<count; i++) if ( pFuncTable[i] > OxaOOOOOOO ) // Действительный указатель if ( DDIJ>roxy[i].pProxy != NULL ) // Есть промежуточная функция { // Запомнить настоящий адрес вызываемой функции DDI_Proxy[i].pReal - (PFN) pFuncTable[i]; // Подправить pFuncTable[i] - (unsigned) DDI_Proxy[i].pProxy: }
278 Глава 4. Мониторинг графической системы Windows void DDISpy_Stop(unsigned fntable. int count) { unsigned * pFuncTable = (unsigned *) fntable; for (int i=0: i<count; i++) if ( pFuncTable[i] > OxaOOOOOOO ) // Действительный указатель if ( DDI_Proxy[i].pProxy != NULL ) // Есть промежуточная функция { // Вернуть старый адрес pFuncTable[i] = (unsigned) DDI_Proxy[i].pReal; #define Call(name) (*(PFN_ ## name) \ DDI_Proxy[INDEX_ # namej.pReal) void APIENTRY DrvDisableDriver(void) { WriteC'DisableDriver"); Call(DrvDisableDriver)(); BOOL APIENTRY DrvTextOut(SURFOBJ *pso. STROBJ *pstro. FONTOBJ CLIPOBJ RECTL RECTL BRUSHOBJ BRUSHOBJ POINTL MIX *pfo, *pco. *prclExtra. *prclOpaque, *pboFore, *pboOpaque, *pptlOrg. mix) WriteCDrvTextOut"): // ... return Call(DrvTextOut) (pso, pstro. pfo. pco. prclExtra, prclOpaque. pboFore. pboOpaque. pptlOrg. mix); } Применение макроса Call оправдывается тем, что он делает программу более наглядной. Этот макрос направляет указатель на настоящую функцию DDI в таблицу DDI_Proxy, преобразует его к правильному типу указателя на функцию DDI и вызывает эту функцию. Кстати, вы обратили внимание на недостаток подобных перехватов API на языках высокого уровня? При вызове настоящей функции DDI происходит дублирование кадра стека. Управляющая программа DDIWatcher не вызывает особых проблем, поскольку она имеет много общего с программой TestPeriScope из главы 3. Ниже приведена самая важная функция, вызываемая после установки драйвера ядра. KDDIWatcher::SpyOnDDI(void) { unsigned buf[2048]; HDC hDC = GetDC(NULL); // Создать контекст устройства
Итоги 279 typedef unsigned (CALLBACK * ProcO) (void); ProcO pGdiQueryTable = (ProcO) GetProcAddress( GetModuleHandle("GDI32.DLL"), "GdiQueryTable"); assert(pGDIQueryTable); // Получить адрес таблицы объектов GDI unsigned * addr = (unsigned *) (pGDIQueryTableO + (unsigned) hDC & OxFFFF) * 16); // Элемент таблицы для hDC addr = (unsigned *) addr[0]; // Указатель на объект ядра scope.Read(buf. addr. 32): // Прочитать 8 двойных слов #ifdef NT4 unsigned pdev = buf[5]; // PDEV * unsigned fntable = pdev + 0x3F4; // Таблица функций #else unsigned pdev - buf[7]; // PDEV * unsigned fntable - pdev + 0xB8C; // Таблица функций #endif // Прочитать таблицу функций для проверки, ..DrvScope scope.ReadCbuf, (void *) fntable. 25 * 4); unsigned cmd[2] - { fntable. 25 }; unsigned long dwRead; // Начать отслеживание DDI IoControKDDISPYjTART. and. sizeof(cmd). buf. 100. &dwRead): // Добавить графические вызовы или переместить окно на рабочем столе // Прекратить отслеживание DDI IoControKDDISPYJND. cmd. sizeof(cmd). buf. 8. &dwRead); cmd[l] - sizeof(buf); // Прочитать зарегистрированные данные IoControKDDISPYJREPORT. cmd. sizeof(cmd). buf. sizeof(buf), &dwRead); // Отобразить полученные данные } Итак, у нас появилась программа для отслеживания интерфейса DDI, работающая с любым драйвером графического устройства. Работа программы основана на модификации структуры данных механизма GDI в памяти. Даже если это приведет к сбою компьютера и появлению «синего экрана» (что маловероятно), вы всегда сможете перезагрузить компьютер и восстановить его работоспособность. Итоги В этой главе были представлены различные инструменты для исследования логики работы GDI. В разделе «Отслеживание вызовов функций Win32 API» описаны общие принципы мониторинга вызовов API. Раздел «Отслеживание вызовов Win32 GDI» иллюстрирует методику мониторинга всех вызовов функ-
280 Глава 4. Мониторинг графической системы Windows ций GDI в процессе — как из GDI32.DLL, так и из внешних модулей. В разделе «Отслеживание СОМ-интерфейсов DirectDraw» мы сосредоточили свое внимание на СОМ-интерфейсах, используемых в DirectDraw. В разделе «Отслеживание системных вызовов GDI» подробно рассматривается мониторинг вызов графических системных функций. Глава завершается разделом «Отслеживание интерфейса DDI», посвященным перехвату функций интерфейса DDI с использованием нового драйвера режима ядра. При помощи инструментов, разработанных в этой главе, вы сможете следить за работой Win32 GDI/DirectDraw API и наблюдать за динамикой вызовов GDI/ DirectDraw на уровне процесса или модуля. Отслеживая недокументированные системные функции графической системы, вы увидите, как GDI32.DLL опирается в своей работе на поддержку со стороны графического механизма. Если вас больше интересуют реальные подробности взаимодействия графического механизма с драйвером устройства — в вашем распоряжении также имеется простое, но мощное средство мониторинга вызовов DDL Более того, у вас даже появляется утилита для автоматического построения файлов определений API и механизм для написания модулей расширения, обеспечивающих усовершенствованную или нестандартную обработку типов данных. Хотя в этой главе основное внимание уделяется GDI и DirectDraw, представленные решения носят общий характер и могут использоваться в отношении других частей Win32 API и других СОМ-интерфейсов. «Дайте мне функцию API, и я покажу вам, куда вас заведет этот вызов... или, по крайней мере, у меня есть все инструменты, чтобы это узнать». Теперь вы можете заявить это с полным правом. Примеры программ Примеры программ главы 4 (табл. 4.3), как и примеры программ главы 3, не принадлежат к числу обычных примеров графического программирования. Скорее, это изощренные системные утилиты, предназначенные для анализа работы графической подсистемы Windows и общих принципов внутреннего устройства операционной системы Windows. Пользуйтесь на здоровье. Таблица 4.3. Программы главы 4 Каталог проекта Описание Samples\Chapt_04\Patcher Библиотека модификации пролога функций для перехода к коду заглушки Samples\Chapt_04\Skimmer Программа для извлечения определений API из заголовочных файлов SDK Samples\Chapt_04\Diver Разведывательная библиотека DLL, внедряемая в исследуемый процесс для сбора информации Samples\Chapt_04\Pogy Управляющая программа мониторинга; устанавливает перехватчик Windows для внедрения DLL-разведчика по имени Diver
Итоги 281 Каталог проекта Описание Samples\Chapt_04\PogyGDI Декодер типов данных GDI (загружается из Diver) Samples\Chapt_04\QueryDDraw Вспомогательная программа для построения файла определений DirectDraw API Samples\Chapt_04\DDISpy Драйвер режима ядра для мониторинга функций интерфейса DDI Samples\Chapt_04\DDIWatcher Тестовая программа для мониторинга вызовов DDI с использованием программы DDISpy
Глава 5 Абстракция графического устройства Как известно, среди всех интерфейсов API графического программирования Windows центральное место занимает интерфейс GDI (Graphics Device Interface). DirectDraw, новый API двумерной графики от Microsoft, ориентирован на программирование игр, а интерфейс Direct3D предназначен для игр и приложений, строящих объемное изображение. Все эти графические API являются аппаратно-независимыми программными интерфейсами, что позволяет приложениям, написанным с их применением, работать на разных графических устройствах. Для обеспечения аппаратной независимости графического API необходима хорошая абстракция, которая бы позволяла представлять различные графические устройства и маскировать их различия без потери производительности. В этой главе описан главный механизм абстрагирования графических устройств в GDI — контекст устройства (device context, DC). Мы познакомимся с возможностями современных видеоадаптеров, представлением абстрактного графического устройства в виде контекста устройства, а также взаимодействием контекста устройства с модулем управления окнами ОС. Современные видеоадаптеры Графический API в системе Windows прежде всего ориентируется на работу с видеоадаптером как с главным средством взаимодействия пользователя и компьютера. Возможно, вас удивит, насколько сложным устройством является современный видеоадаптер. В индустрии PC 64-разрядные компьютеры едва замаячили на горизонте, а в руководстве к видеоадаптеру заявлено, что он использует 128-разрядную архитектуру. Возможно, ваши программы работают в Windows NT
Современные видеоадаптеры 283 с 32 мегабайтами памяти, а ваш видеоадаптер использует тот же объем памяти с 128-разрядной адресацией для собственных целей. Но самое невероятное заключается в том, что видеоадаптер способен выполнять в секунду до 9 миллиардов вещественных операций, а код режима ядра Windows NT имитирует вещественные операции с использованием целых чисел. Рассмотрим основные компоненты современного видеоадаптера. Кадровый буфер Все современные видеоадаптеры работают на растровом принципе; это означает, что информация в них хранится в виде двумерных массивов пикселов в области памяти видеоадаптера. Такая область памяти называется кадровым буфером (frame buffer). Кадровые буферы имеют различные размеры. Когда говорят о размере экрана, обычно имеют в виду «разрешение» (resolution). Эта характеристика принципиально отличается от разрешения, измеряемого в точках на дюйм (dots per inch, dpi), широко используемого для принтеров. Под разрешением экрана обычно понимается количество пикселов, которые могут отображаться на экране по вертикали и горизонтали; под разрешением принтера обычно понимают количество независимо адресуемых пикселов на один дюйм. Минимальный кадровый буфер, поддерживаемый в ОС Windows, имеет размеры, стандартные для VGA, — 640 пикселов в строке на 480 строк. Впервые этот размер был использован фирмой IBM на компьютерах PS/2. Обычно размер 640 х 480 встречается лишь при загрузке компьютера в безопасном режиме или при запуске старых программ, которые заставляют вас переключить экран в этот размер. Максимальные размеры кадрового буфера могут достигать 1600 х 1200 и даже 1920 х 1200 пикселов. Обратите внимание: для большинства разрешений ширина и высота экрана находятся в пропорции 4:3 — например, 640 х 480, 800 х 600, 1024 х 768 и даже 1600 х 1200. Эта пропорция соответствует отношению ширины к высоте самого монитора, благодаря чему соседние пикселы на экране находятся на одинаковом расстоянии по вертикали и по горизонтали. В зависимости от количества цветов, воспроизводимых в кадровом буфере, пикселы могут представляться разным количеством бит. В монохромном кадровом буфере пиксел представляется всего одним битом, а в 16-цветном буфере используются 4 бита на пиксел. В видеоадаптерах нового поколения эти цветовые режимы практически не встречаются. В наши дни кадровый буфер содержит минимум 256 цветов, при этом каждый пиксел представляется 8 битами (или одним байтом). Часто используются так называемые режимы High Color с кодировкой одного пиксела 15 или 16 битами; это позволяет представить 32 768 (32К) или 65 536 (64К) цветов, хотя в обоих случаях пиксел кодируется 2 байтами. Все чаще встречаются видеоадаптеры с поддержкой режимов True Color, в которых 24 бита используются для представления 224 (16М) разных цветов. В некоторых режимах даже используется 32-разрядная кодировка пикселов, хотя это и не значит, что в этих режимах имеет место 232 цветов; 8 бит обычно требуются для хранения данных альфа-канала, в результате для представления цветовой информации остается всего 24 бита.
284 Глава 5. Абстракция графического устройства Чтобы драйвер графического устройства мог осуществлять вывод в кадровый буфер, последний необходимо отобразить в адресное пространство процессора. На ранних моделях PC использовались 20-разрядные адресные линии, что позволяло работать с адресным пространством объема до 1 Мбайт. Видеоадаптеру отводилось всего 64 или 128 Кбайт из общего 1-мегабайтного адресного пространства. Для первых видеоадаптеров Super-VGA с разрешением 1024 х 768 и 256 цветами требовался кадровый буфер объемом 768 Кбайт, что значительно превосходило жалкие 128 Кбайт. Поэтому вместо хранения кадрового буфера в виде одного непрерывного блока 1024 х 768 х 1 байт оборудования приходилось делить его на восемь цветовых плоскостей (planes) 1024 х 768 х 1 бит. Каждая плоскость занимала всего 96 Кбайт, что делало возможным использование видеоадаптера на PC. В результате деления пикселов на восемь плоскостей для записи одного пиксела в кадровый буфер приходилось заносить в аппаратный регистр команду отображения плоскости в адресное пространство процессора, обновлять один бит, переходить к следующей плоскости и т. д. Иногда производители оборудования делили большие кадровые буферы на несколько банков (banks) или использовали плоскости одновременно с банками. Как нетрудно догадаться, все это изрядно затрудняло реализацию аппарат- но-независимого интерфейса GDI. В результате компания Microsoft выдвинула концепцию аппаратно-зависимых растров (DDB), которая позволяла производителям оборудования обеспечивать поддержку быстрого перевода растров в свой собственный формат кадрового буфера и обратно. В Windows NT/2000 вся система, включая графическую подсистему, работает в 32-разрядном адресном пространстве. Объем этого пространства (4-гигабайтный) оставляет достаточно места для любых кадровых буферов. В связи с активным продвижением DirectX компания Microsoft требует, чтобы новые видеоадаптеры поддерживали линейные кадровые буферы с упакованными пикселами. «Упаковка» означает, что все пикселы должны находиться вместе, без деления на цветовые плоскости. Линейность означает, что весь кадровый буфер может отображаться в 32-разрядное линейное адресное пространство. По мере увеличения количества бит;на пиксел и разрешения для хранения всего кадрового буфера требуется все больше памяти. В табл. 5.1 перечислены объемы памяти, необходимые для хранения одного кадрового буфера при разном разрешении и формате пикселов. Таблица 5.1. Геометрия кадрового буфера Разрешение Отношение Объем памяти для хранения кадрового буфера, Кбайт «ширина/ высота» 8бит 15,16 бит 24 бита 32 бита 640 х 480 800 х 600 1024 х 768 1152x864 4:3 4:3 4:3 4:3 300 469 768 972 600 938 1536 1944 900 1407 2304 2916 1200 1875 3072 3888
Современные видеоадаптеры 285 Разрешение Отношение Объем памяти для хранения кадрового буфера, Кбайт «ширина/ высота» 8 бит 15'1б бит 24 бита 32 бита 1280 х 1024 1600 х 1200 1920 х 1080 1920 х 1200 5:4 4:3 16:9 8:5 1280 1875 2025 2250 2560 3750 4050 4500 3840 5625 6075 6750 5120 7500 8100 9000 В максимальном режиме, поддерживаемом видеоадаптером автора, используется разрешение 1920 х 1200 с 32-разрядным кадровым буфером и частотой вертикальной развертки 60 Гц. Это означает, что каждую секунду этот видеоадаптер 60 раз читает весь 9000-килобайтный кадровый буфер и преобразует его в видеосигнал. Таким образом, в секунду видеоадаптер должен обрабатывать 540 Мбайт информации; становится понятно, почему для него нужна 128-разрядная быстрая синхронная память. Шаг Высота В G R Ширина х байт на пиксел Рис. 5.1. Геометрия кадрового буфера В разрешении 1024 х 768 при 24 бит/пиксел одна строка развертки представляется минимум 2304 байтами. Спецификация Microsoft требует, чтобы для повышения быстродействия при работе с памятью строки развертки выравнивались в кадровом буфере по 32-разрядной границе двойных слов. Объем в 2304 байта соответствует этому требованию. При этом строка развертки вовсе не обязана иметь точную длину в 2304 байта — она лишь должна быть не меньше
286 Глава 5. Абстракция графического устройства этой величины. Таким образом, производителям оборудования предоставляется определенная гибкость при выравнивании строк развертки. Размер одной строки развертки в кадровом буфере называется шагом (pitch). В структуре кадрового буфера, изображенной на рис. 5.1, буфер представляет собой массив строк развертки, а размер каждого элемента массива определяется шагом буфера. В строке развертки каждый пиксел представляется определенным количеством смежных битов или байтов. Например, для кадрового буфера с кодировкой 24 бит/пиксел один пиксел представляется тремя байтами, определяющими интенсивность цветовых составляющих в последовательности «синий — зеленый — красный». Следующая функция вычисляет адрес пиксела по начальному адресу кадрового буфера, шагу, размеру и относительной позиции пиксела в буфере: char *GetPixelAddress(chaг * buffer, int pitch, int byteperpixel, int x, int y) { return buffer + у * pitch + x * byteperpixel; } Формат пикселов Когда вы смотрите на какой-нибудь предмет, отраженный им свет попадает вам в глаза. Свет является таким же электромагнитным излучением, как, например, радиоволны, микроволны, инфракрасное и рентгеновское излучение или гамма- лучи. Человеческий глаз воспринимает лишь малую часть всего электромагнитного спектра, которая называется видимым светом и лежит в интервале длин волн от 400 до 700 нм. Различные цвета соответствуют разным длинам волн в спектре видимого света. В наших глазах находятся особые клетки, так называемые колбочки; они чувствительны к этим длинам волн и позволяют нам видеть мир в цвете. Три разных типа колбочек подвержены воздействию света в красной, зеленой и синей частях спектра. Эти три цвета называются основными. Свет, порождаемый разными источниками, относится к разным частям спектра и воспринимается как имеющий тот или иной цвет. В компьютерной промышленности цвет обычно описывается совокупностью трех основных цветовых составляющих — красной, зеленой и синей. Цвет можно рассматривать как точку в цветовом трехмерном пространстве, в котором составляющие соответствуют трем осям (так называемое цветовое пространство RGB). В литературе по компьютерной графике цветовые составляющие обычно представляются вещественными числами в интервале от 0 до 1, что позволяет описывать бесконечное количество цветов. Но в дискретном мире современных видеоадаптеров каждый компонент обычно преобразуется к целому числу в интервале от 0 до 255, представленному в пространстве памяти восемью битами или одним байтом. Таким образом, цвет одного пиксела описывается тремя байтами — по одному для красной, зеленой и синей составляющей, а 24-разрядное дискретное цветовое пространство RGB может описывать до 16 777 216 различных цветов. В монохромном кадровом буфере каждый пиксел представляется одним битом памяти. Информация о восьми пикселах упаковывается в один байт, при этом
Современные видеоадаптеры 287 старший бит соответствует первому пикселу, а младший бит — последнему пикселу. Скорее всего, вам не придется использовать монохромный буфер для непосредственного вывода, но и в наши дни монохромные буферы играют значительную роль в Windows-программировании. В цветном кадровом буфере цветовые плоскости представляются в формате монохромных буферов. Монохромный формат часто используется для представления растровых изображений в памяти — например, глифы шрифтов обычно преобразуются в монохромные растры перед выводом на экран или отправкой на принтер. Одноцветные принтеры также работают с некоторыми разновидностями монохромных растров на уровне языка принтера или внутреннего микрокода. Представление одного пиксела 8 битами позволяет использовать до 256 разных цветов. Если бы эти цвета жестко фиксировались, нам пришлось бы выбрать универсальный набор точек для представления всего цветового пространства RGB — для нормального отображения нашего многоцветного мира этого явно недостаточно. Поэтому вместо фиксированного набора цветов видеоадаптер использует цветовую таблицу, называемую палитрой (palette). Для кадрового буфера с 8-разрядной кодировкой палитра состоит из 256 элементов, каждый из которых соответствует 24-разрядному значению RGB. В кадровом буфере сохраняются не цвета, а индексы в палитре. При косвенном представлении цветов с использованием палитры кадровый буфер, как и раньше, в любой момент времени содержит только 256 разных цветов, однако эти цвета выбираются из 16 миллионов кандидатов 24-разрядного цветового пространства. Например, при помощи палитры с 256 оттенками серого цвета можно выводить рентгенограммы, а палитра теплых тонов красновато-оранжевой гаммы хорошо подойдет для изображения заката. При обновлении кадрового буфера, использующего палитру, видеоадаптер должен прочитать индексы из буфера, пропустить их через цветовую таблицу и отправить полученные данные в видеопорт. На аппаратном уровне этот процесс реализуется весьма эффективно. При этом драйвер устройства должен предоставить программам высокого уровня точки входа для управления аппаратной палитрой. Если в графических командах вместо индексов палитры указываются конкретные цветовые значения в формате RGB, они должны быть преобразованы в индексы палитры при записи пикселов или наоборот, — при чтении пикселов. Процесс преобразования значений RGB в индексы палитры сводится к просмотру таблицы и поиску наиболее точного совпадения. Если найти точное совпадение не удается, цвет можно имитировать узором из пикселов, входящих в палитру, с использованием алгоритма смешения (dithering). Преобразование индексов палитры в значения RGB осуществляется простой индексацией. На рис. 5.2 иллюстрируется процесс определения цветов для кадрового буфера с кодировкой 8 бит/пиксел. В 15-разрядных кадровых буферах High Color каждая из основных цветовых составляющих представляется 5 битами. Информация об одном пикселе хранится в 16-разрядном слове; старший бит остается неопределенным, а за ним следуют 5 бит красной, 5 бит зеленой и младшие 5 бит синей составляющих. 15- разрядный формат пикселов часто обозначается сокращением «5:5:5». Кадровый буфер в этом формате может содержать до 32 768 разных цветов.
288 Глава 5. Абстракция графического устройства 8-разрядный Аппаратная палитра з кадрового буфера 1 1 1 1 1 1 1 1 1 00 00 00 00 00 FF 00 FF 00 FF АА 55 FF FF FF FF АА 55 Красный сигнал Зеленый сигнал Синий сигнал Рис. 5.2. Поиск в палитре для 8-разрядного кадрового буфера Формат High Color (16 разрядов) слегка улучшает 15-разрядный формат. Вместо простой потери старшего бита в 16-разрядном слове зеленая составляющая расширяется до 6 бит, поскольку человеческий глаз обладает повышенной чувствительностью к зеленому цвету. В 16-разрядном кадровом буфере один пиксел по-прежнему представляется 16-разрядным словом, обычно в формате 5:6:5. По сравнению с кадровыми буферами True Color использование формата High Color обеспечивает экономию памяти при нормальном количестве цветов и высоких разрешениях. Например, видеоадаптер всего с 2 мегабайтами памяти в 16- разрядном режиме может поддерживать разрешения вплоть до 1152 х 864. Впрочем, есть и обратная сторона — скорость. Запись цветового пиксела из 24-разрядного формата RGB в кадровый буфер High Color не сводится к простому копированию. 8-разрядные составляющие приходится сокращать до 5 или 6 бит, объединять их в соответствии с форматом пикселов и только потом сохранять данные. Преобразование пиксела из кадрового буфера High Color в 24-разрядный формат True Color означает выделение каждой цветовой составляющей при помощи маски и его расширение до 8 бит. Существует несколько вариантов внутреннего формата пикселов, однако Microsoft требует, чтобы производители оборудования использовали фиксированную структуру кадрового буфера. Более того, видеоадаптер, который поддерживает 15-разрядные кадровые буферы, но не поддерживает 16-разрядных, все равно должен имитировать свою поддержку 16-разрядных буферов. Эти требования улучшают совместимость программ с различными устройствами. На рис. 5.3 показан формат пикселов в 15- и 16-разрядных кадровых буферах и маски для выделения красной, зеленой и синей составляющих. В приложениях с особо качественной графикой и играх даже 15- и 16-разрядные кадровые буферы не обеспечивают необходимого разнообразия цветов и плавности цветовых переходов. Например, при выводе изображения в оттенках серого цвета с использованием 15-разрядного кадрового буфера удается вывести лишь 32 уровня серого цвета — каждая цветовая составляющая RGB хранится в 5 битах, что позволяет задействовать 25 уровней интенсивности. В таких
Современные видеоадаптеры 289 приложениях просто необходимо использовать самое лучшее — 24- или 32-разрядные кадровые буферы True Color. И в 24-, и в 32-разрядных кадровых буферах красная, зеленая и синяя составляющие представляются 8 битами. В старых видеоадаптерах старшие 8 бит 32-разрядного пиксела обычно оставались неиспользованными. У новых видеоадаптеров для ОС Windows 98 или Windows 2000 в старших 8 битах хранится информация о прозрачности (transparency). 15-разрядный формат пикселов | Красный (0х7С00) | Зеленый (ОхОЗЕО) | Синий (0x001 F) | R R R R R G G G G G В В В В В Старший бит Младший бит 16-разрядный формат пикселов | Красный (0xF800) | Зеленый (0х07Е0) | Синий (0x001 F) | R R R R R G G G G G G В В В В В Рис. 5.3. Формат пикселов в кадровых буферах High Color Составляющая прозрачности обычно называется альфа-каналом (alpha channel). Эта характеристика определяет весовой коэффициент исходного пиксела при выводе на поверхность. Минимальный альфа-коэффициент равен 0; это означает, что пиксел абсолютно прозрачен и на поверхность вообще не выводится. Максимальный альфа-коэффициент в 8-разрядном альфа-канале равен 255. В этом случае пиксел совершенно не прозрачен, поэтому он просто заменяет соответствующий пиксел принимающей поверхности. При любых промежуточных значениях новый пиксел поверхности вычисляется как взвешенная сумма копируемого пиксела и старого пиксела принимающей поверхности. 24-разрядный формат пикселов часто называется «форматом RGB», а 32-разрядный формат — «форматом ARGB». Структура пиксела в обоих форматах изображена на рис. 5.4. 16 777 216 разных цветов, представляемых 24- или 32-разрядным кадровым буфером, хватает для всех — от фотографа-любителя до профессионала экстракласса. Однако постепенно выяснилось, что с широким распространением режимов High Color и True Color была утрачена гибкость, присущая аппаратным палитрам. Небольшое изменение аппаратной палитры немедленно отражалось на всем экране. Например, если художник хотел слегка отрегулировать насыщенность цветовой гаммы рисунка, ему приходилось изменять значения RGB не более чем в 256 элементах палитры. Но при традиционной структуре кадровых буферов High Color и True Color требуется изменять все пикселы буфера, общий объем которого при разрешении 1024 х 768 и 24-разрядной кодировке составлял 2304 Кбайт. При выводе высококачественных изображений возникала и другая проблема — сопоставление цветов на экране с цветами печатного изображения. Цвет, отображаемый на электронном устройстве, воспринимается нашим глазом не
290 Глава 5. Абстракция графического устройства так, как на бумаге. Профессиональные художники используют так называемую гамма-коррекцию, обеспечивающую дополнительное преобразование цветных пикселов кадрового буфера. Чтобы таблица преобразования имела разумные размеры, каждая из составляющих RGB преобразуется по отдельной таблице, для чего необходимы три таблицы по 256 байт каждая. На аппаратном уровне такое преобразование выполняется микросхемой RAMDAC (RAM digital- to-analog converter). Microsoft требует, чтобы видеоадаптеры поддерживали программируемые (downloadable) микросхемы RAMDAC для кадровых буферов True Color с целью выполнения гамма-коррекции на аппаратном уровне. Stetefftae* !то1зриш ,<t, fisPfyteeC-ap» Graphics Blaster Riva TNT ATTACHED_TO_DESKTOP ;V| PCI WEN ШЕШЕУ 0020&SUBSYS 1 \R E GIS T RY\M achine\Sy sterrAControlS et 640 by 480,8 bits, 320 by 200,8 bits, 320 by 200,8 bits, 320 by 200,8 bits, 320 by 240,8 bits, 320 by 240,8 bits, 320 by 240,8 bits, 320 by 240,8 bits, 400 by 300,8 bits, 400 by 300,8 bits, 400 by 300,8 bits, 400 by 300,8 bits, 480 by 360,8 bits. ***!.'•:*&'Av&s* ■",', 60 Hz. 300 Kb 70 Hz, 62 Kb 72 Hz, 62 Kb 75 Hz, 62 Kb 60 Hz, 75 Kb 70 Hz, 75 Kb 72 Hz, 75 Kb 75 Hz, 75 Kb 60 Hz, 117 Kb 70 Hz, 117 Kb 72 Hz, 117 Kb 75 Hz, 117 Kb 60.Hz,.168Kb.% .^~\ ^f Рис. 5.4. 24- и 32-разрядные форматы пикселов Двойная буферизация, z-буфер и текстуры В компьютерных играх одно из центральных мест занимает анимация — небольшие изображения и даже целые экраны, вид которых меняется с течением времени. Для каждого кадра в анимационной последовательности программа должна стереть некоторые части кадрового буфера и вывести поверх стертых областей новое изображение. В схеме с одним кадровым буфером видеосигнал генерируется по содержимому кадрового буфера в то время, когда программа стирает и перерисовывает его. В результате возникает раздражающее мерцание.
Современные видеоадаптеры 291 Проблема решается посредством использования двух буферов — основного (экранного) и вспомогательного (внеэкранного). Пользователь всегда видит на экране лишь содержимое готового основного буфера, а приложение в это время работает над заполнением внеэкранного буфера. Когда вывод завершается, происходит переключение — основной и вспомогательный буферы меняются местами. Пользователь видит новый основной буфер, а программа начинает работу над новым внеэкранным буфером. При этом пользователь никогда не видит незавершенного изображения, а анимация становится плавной. Методика использования двух буферов называется двойной буферизацией (double buffering). Видеоадаптеры нового поколения должны обеспечивать двойную буферизацию для всего кадрового буфера. Применение двойной буферизации удваивает объем необходимой видеопамяти. В соответствии с табл. 5.1, для поддержки 32-разрядного кадрового буфера в разрешении 1920 х 1200 видеоадаптеру теперь требуется 17,5 Мбайт видеопамяти. Получив запрос на переключение буферов, видеоадаптер должен дождаться вертикального обратного хода луча, то есть момента, когда один цикл обновления изображения полностью завершен, а новый цикл еще не начался. Если переключение буферов не синхронизируется с вертикальным обратным ходом луча, на экране возникают неприятные искажения. В процессе ожидания программа не может записывать данные ни в один из двух буферов, что приводит к напрасным потерям процессорного времени. Для экономии времени на синхронизацию используется схема тройной буферизации, при которой запись может осуществляться в третий кадровый буфер. В этом случае первый буфер содержит изображение, выводимое на экран, второй буфер ожидает вывода, а в третьем буфере строится новый кадр. В трехмерных играх сцена состоит из различных объектов, находящихся на разных расстояниях от зрителя. Ближние объекты блокируют линию видимости, в результате чего дальние объекты частично или полностью скрываются. Для прорисовки трехмерной сцены программа должна рассортировать объекты по расстоянию от зрителя, а это очень сложный и длительный процесс. Ситуация осложняется тем, что пикселы графического объекта тоже могут находиться на разных расстояниях от пользователя (в соответствии с их расположением на объекте). Два соприкасающихся объекта тоже могут частично перекрывать друг друга. Как обычно, эффективное решение проблемы связано с дополнительными затратами памяти. В нем используется дополнительный буфер глубины, называемый z-буфером (по названию третьей координатной оси). В z-буфере хранится глубина каждого пиксела, то есть расстояние от пиксела объекта до зрителя. При запросе на вывод нового пиксела его глубина сравнивается с соответствующей глубиной из z-буфера. Выводятся лишь пикселы с меньшей глубиной, при этом одновременно обновляется содержимое z-буфера. Объем z-буфера в памяти зависит от того, сколько дискретных уровней глубины должна различать программа. 8-разрядный z-буфер обеспечивает 256 уровней глубины; для сколько-нибудь нетривиальных целей этого недостаточно. 16- разрядные z-буферы повышают количество уровней глубины до 65 536 и очень часто используются в современных видеоадаптерах, представленных на рынке. Но в наши дни требования к детализации изображений в играх непрерывно рас-
292 Глава 5. Абстракция графического устройства тут и даже 16-разрядного z-буфера может оказаться недостаточно. При выводе объектов с ошибочным порядком глубин возникает так называемая z-размывка (z-aliasing). Все чаще встречаются видеоадаптеры с 24- и 32-разрядными z-буфе- рами. Некоторые видеоадаптеры поддерживают вещественные z-буферы, повышающие точность измерения глубины. 16-разрядный z-буфер увеличивает размер видеопамяти еще на 0,6-4,4 Мбайт. При использовании 32-разрядного z-буфера эта величина удваивается и доходит до 1,2-8,8 Мбайт. Трехмерные объекты и сцены образуются из трехмерных поверхностей, которые обычно строятся из тысяч элементарных треугольников. Затем на эти треугольники накладываются растры, называемые текстурами, благодаря которым поверхность имитирует вид одежды, песчаной отмели или кирпичной стены. При аппаратном ускорении наложение текстур выполняется аппаратурой видеоадаптера, а не процессором вашего компьютера. Ключевым фактором производительности в этом случае является быстрый доступ к текстурам; для этого видеоадаптер должен хранить растры текстур в видеопамяти вместо того, чтобы извлекать их из системной памяти по медленной и сильно загруженной системной шине. Итак, в памяти видеоадаптера хранятся основной и внеэкранный буферы, z-буфер и, кроме того, мегабайты текстурных растров. В табл. 5.2 приведены возможные конфигурации вашего видеоадаптера. Таблица 5.2. Распределение видеопамяти Использование 8 Мбайт 16 Мбайт 32 Мбайт Основные буферы Внеэкранные буферы Z-буферы Текстуры 1875 Кбайт 800 х 600 х 32 3750 Кбайт 800 х 600 х 32 х 2 938 Кбайт 800 х 600 х 16 629 Кбайт 3072 Кбайт 1024 х 768 х 32 6144 Кбайт 1024 х 768 х 32 х 2 2304 Кбайт 1024 х 768 х 24 4864 Кбайт 3888 Кбайт 1152x864x32 7776 Кбайт 1152x864x32x2 2304 Кбайт 1152x864x32 17 216 Кбайт Как показано в таблице, если на вашем видеоадаптере установлено 32 Мбайт памяти, при разрешении 1152 х 864 с 32-разрядным цветом основной буфер занимает 3888 Кбайт, два внеэкранных буфера в общей сложности занимают 7777 Кбайт и 32-разрядный z-буфер требует еще 3888 Кбайт; для текстурных растров остается 17 216 Кбайт. Но если переключиться в разрешение 1600 х 1200, которое остается намного ниже максимального 1920 х 1440, для текстур остается всего 2768 Кбайт. Одним из способов решения этой проблемы является сжатие, уменьшающее размер текстур. Другой возможный путь — ускорение загрузки текстур из системной памяти в память видеоадаптера. В современной аппаратной архитектуре PC пересылка данных, включая пересылку из системной памяти в видеопамять, осуществляется по шине PCI (Peripheral Component Interconnect).
Современные видеоадаптеры 293 Максимальная скорость передачи шины PCI равна 100 Мбит/с. Новая шина AGP (Accelerated Graphics Port), спроектированная компанией Intel, представляет собой специализированную высокоскоростную шину, обеспечивающую быстрый доступ к текстурам, находящимся в системной памяти. Например, скорость передачи по шине AGP 2X составляет 528 Мбит/с. Видеоадаптеры также могут поддерживать оверлейные поверхности, то есть поверхности, накладываемые на основной экран. В частности, это позволяет выводить телевизионный сигнал поверх обычного экрана. Аппаратное ускорение Функции современного видеоадаптера не ограничиваются предоставлением кадровых буферов, на которых программа выводит изображение, и генерацией видеосигнала по содержимому буфера. В противном случае вычислительной мощности даже самого быстрого процессора общего назначения не хватило бы для воспроизведения трехмерного ролика с приемлемой частотой кадров. Ниже перечислены некоторые возможности, поддерживаемые большинством видеоадаптеров. О Вывод курсора, в том числе с альфа-каналом. О Поддержка двумерной графики: линии и кривые с возможным использованием дробных координат, заливка областей, блиттинг растров, альфа-наложение, градиентные заливки, множественная буферизация и программирование RAMDAC. О Вывод текста, включая сглаживание с использованием глифов нескольких уровней. О Поддержка трехмерной графики: конвейер операций трехмерной графики, различные варианты сглаживания текстур, наложение текстур с учетом перспективы на уровне пикселов, z-буфер, сглаживание краев, сглаживание на уровне пикселов, анизотропная фильтрация, текстуры на базе палитр и т. д. О Видео: декодирование MPEG, декодирование DVD, плавное масштабирование с фильтрацией, вывод видеоинформации в нескольких окнах с преобразованием цветового пространства и фильтрацией, назначение цветовых ключей на уровне пикселов, оверлеи и т. д. Экранное устройство и перечисление режимов Windows 2000 позволяет использовать в одной системе несколько экранных устройств для отображения главного рабочего стола, вывода вспомогательной информации или зеркального воспроизведения экранов в NetMeeting. Многоэкранная поддержка позволяет установить на PC несколько видеоадаптеров, каждый из которых подключается к отдельному монитору. Эти мониторы либо образуют большой виртуальный рабочий стол, либо работают независимо друг от друга. Первый вариант удобен в приложениях, у которых желаемый размер рабочего стола превышает размеры монитора — например, при широкоформатной печати, в программах компьютерной верстки или системах автоматиза-
294 Глава 5. Абстракция графического устройства ции проектирования. Второй вариант хорошо подходит для компьютерных игр, отладки, обучающих программ и презентаций. Зеркальное копирование незаменимо в тех случаях, когда вы хотите передавать содержимое своего экрана другому пользователю по сети. Все графические команды передаются в виде сетевых пакетов на другой компьютер, где и воспроизводится зеркальная копия исходного экрана. Интерфейс Windows GDI/DDI первоначально проектировался как протокол локального вывода — другими словами, предполагалось, что графические команды GDI передаются драйверу экрана на том же компьютере. В этом он отличается от протокола XWindow, используемого в мире UNIX, который проектировался как протокол удаленного вывода. Использование XWindow на рабочих станциях UNIX позволяет вам прийти домой, зарегистрироваться на компьютере, находящемся в офисе за несколько километров от вас, и получить на домашнем компьютере содержимое экрана офисного компьютера, чтобы управлять им в удаленном режиме. Существуют приложения, позволяющие работать с терминальными окнами XWindow в Microsoft Windows. Более того, экран XWindow можно передать нескольким сторонам и позволить каждой из них вносить в него изменения. До этапа официальной поддержки зеркального копирования разработчикам приложений приходилось модифицировать или переписывать драйвер экрана, чтобы организовать передачу графических команд по сети. В Windows 2000 появился отдельный зеркальный драйвер, который «видит» данные, переданные настоящему драйверу экрана. С каждым экранным устройством связывается уникальное имя, по которому на данное устройство можно ссылаться в пользовательских приложениях. Имя задается в форме WADISPLAYx, где х — номер в последовательности, начинающейся с 1. Обратите внимание: в программах C/C++ строка должна записываться в виде WW.WDISPLAYx, поскольку служебный символ \ в строках должен экранироваться. В Windows 2000 появилась новая функция EnumDisplayDevices, предназначенная для перечисления всех экранных устройств, установленных в системе. Приведенная ниже функция фиксирует экранные устройства и заполняет список их именами. void AddDisplayDevices(HWND hList) { DISPLAY_DEVICE Dev; Dev.cb = sizeof(Dev); SendMessageChList. CB_RESETC0NTENT. 0, 0); for (unsigned i-0. EnumDisplayDevices(NULL, i. & Dev, 0); i++) SendMessage(hList. CB_ADDSTRING. 0, (LPARAM) Dev.DeviceName): SendMessage(hList. CB_SETCURSEL. 0, 0); } Для каждого экранного устройства EnumDisplayDevices заносит в структуру DISPLAY_DEVICE имя устройства (например, WADISPLAY1), строку описания устрой-
Современные видеоадаптеры 295 ства (например, NVIDIA RIVA TNT), флаги состояния (например, ATTACHED_TO_DESKTOP | MODESPRUNED|PRIMARY_DEVICE), идентификатор устройства Plug-and-Play и ключ реестра. Зная имя экранного устройства, можно воспользоваться функцией EnumDisplaySettings для получения списка всех форматов кадрового буфера, поддерживаемых устройством, с частотами вертикальной развертки. Код следующего примера выполняет перечисление и заносит в список строку с краткими сведениями о каждом формате. int FrameBufferSizednt width, int height, int bpp) { int bytepp - ( bpp + 7 ) / 8; // Байт на пиксел int byteps - ( width*bytepp + 3 ) / 4*4; // Байт на строку развертки return height * byteps; // Байт на кадровый буфер } void AddDisplaySettingsCHWND hList. LPCTSTR pszDeviceName) { DEVMODE dm; dm.dmSize • sizeof(DEVMODE); dm.dmDriverExtra - 0; SendMessage(hList. LB_RESETCONTENT. 0. 0); for (unsigned i - 0; EnumDisp1aySettings(pszDeviceName. i. & dm); i++ ) { TCHAR szTemp[MAX_PATH]; wsprintf(szTemp. JCXd by Xd. Xd bits. Xd Hz. Xd KB"). dm.dmPelsWidth. dm.dmPelsHeight. dm.dmBitsPerPel. dm.dmDi splayFrequency. FrameBufferSi ze(dm.dmPelsWi dth. dm.dmPelsHei ght. dm.dmBitsPerPel) / 1024 ); SendMessage(hList. LB_ADDSTRING. 0. (LPARAM)szTemp); } } Для каждого режима EnumDisplaySettings заполняет структуру DEVMODE информацией о ширине и высоте кадрового буфера, количестве бит на пиксел, частоте развертки и т. д. Приведенная функция вычисляет размер одного кадрового буфера на основании полученной информации. Учтите, что при использовании структуры DEVMODE необходима осторожность. В Win32 API документирована открытая структура DEVMODE. Драйвер графического устройства может присоединить к открытым полям DEVMODE закрытые данные, для чего размер дополнительных данных указывается в поле dmDriverExtra. Перед вызовом EnumDisplaySettings программа заполняет поле dmSize размером
296 Глава 5. Абстракция графического устройства (открытой части) DEVMODE и обнуляет поле dmDriverExtra, чтобы драйвер экрана не пытался получить дополнительные данные. На прилагаемом компакт-диске имеется программа DEVICE, использующая функции EnumDisplayDevices и EnumDisplaySettings. На странице DisplayDevic.es отображается список экранных устройств, установленных в системе, и поддерживаемые ими форматы кадровых буферов. На рис. 5.5 изображен примерный вид окна программы DEVICE. "jj*i Device Name: Device String:. ' State Flag*: DevicelD: g.etDeviceCaps| DC Attributes Graphics Blaster Riva TNT ATTACHED TO DESKTOP PCISVEN 10DE&DEV 0020&SUBSYS 1 \REGISTRY\Machine\System\ControlSef 640 by 480, 320 by 200, 320 by 200, 320 by 200, 320 by 240, 320 by 240, 320 by 240, 320 by 240, 400 by 300, 400 by 300, 400 by 300, 400 by 300, 480 bv 360. 8 bi 8bi 8 b 8 bi 8 b 8 bi 8 b 8 b 8 b 8bi 8 bi 8 bi 8bi 60 Hz, 70 Hz, 72 Hz, 75 Hz, 60 Hz, 70 Hz, 72 Hz, 75 Hz, 60 Hz, 70 Hz, 72 Hz, 75 Hz, 60 Hz. 300 Kb 62 Kb 62 Kb 62 Kb 75 Kb 75 Kb 75 Kb 75 Kb 117 Kb 117 Kb 117 Kb 117 Kb 168 Kb Рис. 5.5. Перечисление экранных устройств и режимов Контекст устройства Видеоадаптеры образуют лишь один класс графических устройств, поддерживаемых графической системой Windows. Другим важным классом графических устройств являются устройства создания жестких копий — принтеры, плоттеры и факсы. Графическая система Windows NT/2000 имеет многоуровневую архитектуру. Верхний уровень состоит из 32-разрядных клиентских DLL, предоставляю-
Контекст устройства 297 щих функции API в распоряжение пользовательских приложений. Например, GDI32.DLL поддерживает функции GDI API для традиционной двумерной графики; DDRAW.DLL — функции DirectDraw API для программирования двумерной графики в играх, а D3DRM.DLL и D3DIM.DLL — функции Direct3D API для программирования игровой трехмерной графики. Клиентские DLL отображаются в адресное пространство приложения (в часть пользовательского режима). На среднем уровне находится графический механизм, работающий в адресном пространстве режима ядра и обеспечивающий поддержку графического API для всей системы. В графическом адресном пространстве режима ядра находятся сотни обработчиков графических системных функций, вызываемых клиентскими DLL. В Windows NT/2000 графический механизм и часть системы управления окнами, работающая в режиме ядра, объединены в большую DLL режима ядра WIN32K.SYS. Нижний уровень графической системы состоит из драйверов графических устройств, предоставленных производителями оборудования и реализующими интерфейс DDI (Device Driver Interface) в соответствии со спецификацией Microsoft DDK (Device Driver Kit). За подробным описанием графической системы Windows, графических системных функций, интерфейса DDI и драйверов графических устройств обращайтесь к главе 2. Для взаимодействия с драйверами графических устройств графическая система Windows NT/2000 использует внутреннюю структуру данных, называемую контекстом устройства (device context). На самом деле контекст устройства представляет собой сложную иерархию структур и объектов, объединенных посредством указателей и находящихся как в адресном пространстве пользовательского режима приложения, так и в системном адресном пространстве ядра. В главе 3 подробно проанализировано внутреннее строение контекста устройства и других структур данных графической системы. Контекст устройства решает две важные задачи в графической системе. Главной задачей является абстракция графического устройства, чтобы все компоненты, расположенные выше драйвера устройства (в том числе графический механизм, клиентские DLL Win32 и пользовательское приложение), могли быть аппаратно-независимыми. Кроме того, в контексте устройства сохраняются часто используемые графические атрибуты — например, цвет фона, растровая операция, перо, кисть, шрифт и т. д., чтобы их значения не приходилось задавать в каждой графической команде. Клиентская DLL Win32 GDI скрывает реальный контекст устройства от пользовательских приложений. Приложению предоставляется лишь манипулятор контекста устройства — 32-разрядное число недокументированного формата. Манипулятор возвращается при создании контекста устройства средствами GDI, а затем передается GDI при всех последующих запросах на выполнение графических операций. Механизм манипуляторов скрывает реализацию надежнее, чем указатели this в C++ и интерфейсные указатели СОМ. Кроме того, он существенно расширяет свободу действий Microsoft по созданию совместимых реализаций в разных системах. Например, программы Win32 работают как в Windows 95/95, так и в Windows NT/2000, хотя в этих классах систем манипуляторы контекстов устройств реализованы по-разному.
298 Глава 5. Абстракция графического устройства Создание контекста устройства Контекст устройства создается функцией Win32 CreateDC: HDC CreateDC (LPCSTR pszDriver, LPCSTR pszDevice, LPCSTR pszOutput. CONST DEVMODE * pdvmlnit): Первый параметр, pszDriver, в программах Win32 для передачи имени драйвера графического устройства не используется — это пережиток эпохи Win 16 API. Допустимыми значениями этого параметра являются только DISPLAY (контекст экранного устройства), NULL и WINSP00L (контекст устройства для принтера). Второй параметр, pszDevice, определяет имя графического устройства. В нем может передаваться как имя экранного устройства, возвращаемое функцией Enum- DisplayDevices, так и имя принтера, указанное в мини-приложении Printers (Принтеры) панели управления. Например, значение WW.WDISPLAY1 или NULL обозначает первичное экранное устройство; значение WW.WDISPLAY2 обычно соответствует вторичному экранному устройству, WW. WDISPLAY3 может обозначать драйвер NetMeeting, обеспечивающий зеркальное воспроизведение экрана на другом мониторе. Третий параметр определяет имя порта, в который передается задание печати. В Win32 для передачи имени порта используется новая функция StartDoc, поэтому этот параметр всегда должен быть равен NULL. Последний параметр, pdvmlnit, содержит указатель на структуру DEVMODE с описанием параметров инициализации. Обычно передается значение NULL — это означает, что драйвер устройства должен использовать текущую конфигурацию устройства, хранящуюся в реестре. Для экранных устройств pdvmlnit может указывать на структуру DEVMODE, возвращаемую функцией EnumDisplaySettings и содержащую высоту, ширину, количество бит на пиксел и частоту вертикальной развертки. Для устройств создания жестких копий pdvmlnit может указывать на структуру DEVMODE, возвращаемую функцией DocumentProperties. Функция CreateDC возвращает манипулятор контекста устройства GDI, который используется при последующих вызовах функций GDI вплоть до последнего вызова DeleteDC, который освобождает системные ресурсы, занятые контекстом устройства; после этого манипулятор контекста становится недействительным. Процесс создания контекста устройства очень сложен. По имени устройства операционная система получает из реестра имя драйвера устройства и загружает драйвер. Для экрана монитора драйвер загружается только при первом вызове CreateDC, а при последующих вызовах используется ранее загруженный драйвер. Фактическая загрузка и инициализация драйвера принтера также происходит при вызове CreateDC. Информация о создании нового контекста устройства для принтера также передается спулеру и библиотеке DLL, обеспечивающей пользовательский интерфейс с драйвером принтера. При загрузке драйвера графического устройства вызывается его главная точка входа DrvEnableDriver. Функция DrvEnableDriver заполняет структуру с номером версии и адресами точек входа всех функций DDI, реализуемых драйвером. Затем графический механизм вызывает функцию DrvEnablePDEV, требуя, чтобы драйвер описал свои атрибуты и возможности, а также создал свою структуру
Контекст устройства 299 данных физического устройства. Параметры pdvmlnit и pszDevice, переданные при вызове CreateDC, передаются функции DrvEnablePDEV. Функция DrvEnablePDEV заполняет две важные структуры, GDI INFO и DEVINF0, информацией об атрибутах, возможностях, форматах пикселов и стандартных параметрах устройства. Графический механизм создает свою внутреннюю структуру физического устройства с информацией, возвращаемой функциями DrvEnableDriver и DrvEnablePDEV. Теперь он знает возможности графического устройства и адреса точек входа, к которым следует обращаться при вызове различных графических команд DDL В завершающей фазе создания контекста устройства графический механизм вызывает функцию драйвера DrvEnableSurface; драйвер создает графическую поверхность, на которой и происходит фактический вывод. За подробностями обращайтесь к главе 2 (описание интерфейса DDI) и главе 3 (внутренние структуры данных). Получение информации о возможностях устройства Контекст устройства хранит (непосредственно или в виде ссылок) большой объем данных о графическом устройстве и его драйвере. Часть информации можно получить при помощи вызовов Win32 API; другая часть хранится во внутренних структурах GDI для упрощения взаимодействия с драйвером. Функция GetDeviceCaps возвращает информацию об атрибутах или возможностях графического устройства по целочисленному индексу: int GetDeviceCaps (HDC hDC. int nlndex); При помощи функции GetDeviceCaps приложение получает конкретную информацию о графическом устройстве — например, формате кадрового буфера, возможности обработки цветов, разрешении, палитре, физических размерах, размерах полей, поддержке альфа-наложения и градиентных заливок, поддержке ICM (Image Color Management), а также о возможностях и ограничениях DDL Большинство возможностей не представляет интереса для прикладных программ; это всего лишь рекомендации, управляющие взаимодействием графического механизма с драйвером устройства. Некоторые флаги ориентированы на 16-разрядные драйверы графических устройств, используемые в Windows 3.1, Windows 95 и Windows 98. Например, флаг CC_ELLIPSES в запросе CURVECAPS показывает, способен ли драйвер устройства нарисовать эллипс. В интерфейсе DDI систем Windows NT/2000 этот флаг отсутствует, поскольку все эллиптические кривые до передачи драйверу устройства преобразуются в кривые Безье. Когда приложение обращается с запросом по индексу CURVECAPS, Windows NT/2000 возвращает стандартный ответ просто для того, чтобы не нарушить работу старых приложений. В табл. 5.3 перечислены индексы и возвращаемые значения функции GetDeviceCaps. При выводе на экран вызов GetDeviceCaps позволяет получить очень важную информацию о том, поддерживает ли контекст устройства аппаратную палитру. Программа, осуществляющая вывод в контексте с поддержкой палитры, должна создать логическую палитру, выбрать ее в контексте устройства перед началом вывода и обрабатывать сообщения, связанные с палитрой.
300 Глава 5. Абстракция графического устройства Таблица 5.3. GetDeviceCaps: индексы и возвращаемые значения (Windows NT/2000) Индекс Пример Возвращаемое значение и смысл DRIVERVERSION TECHNOLOGY H0RSIZE VERTSIZE LINECAPS 0x4001 DT RASDISPLAY 320 240 H0RZRES VERTRES BITSPIXEL PLANES NUMBRUSHES NUMPENS NUMFONTS NUMCOLORS CURVECAPS 1024 768 8,16,24,32 1 -1 -1 0 -1 OxlFF OxFE Версия драйвера; 16 бит в формате OxXYZZ, где X — основная версия ОС, Y — дополнительная версия ОС, a ZZ — номер версии драйвера. Информация сообщается драйвером Информация сообщается драйвером. DTPLOTTER — для плоттеров, DTRAS DIS P LAY — для растровых видеоадаптеров, DTRASPRINTER — для растровых принтеров, DTRASCAMERA — для растровых камер, DTCHARSTREAM — для символьных потоков Ширина физической поверхности в миллиметрах. Для экрана выводится приблизительное значение. Информация сообщается драйвером Высота физической поверхности в миллиметрах. Для экрана выводится приблизительное значение. Информация сообщается драйвером Ширина физической поверхности в пикселах. Информация сообщается драйвером Высота физической поверхности в пикселах. Информация сообщается драйвером Количество смежных битов в каждой цветовой плоскости. Информация сообщается драйвером Количество цветовых плоскостей. Информация сообщается драйвером Количество кистей устройства Количество перьев устройства. Для плоттеров — количество физических перьев Количество шрифтов устройства Количество элементов в палитре устройства или -1, если палитра отсутствует Возможности вывода кривых. Стандартный ответ: CC_CH0RD | CC_CIRCLES | CCJLLIPSES | CCJNTERI0RS | CC_PIE | CC_R0UNDRECT|CC_STYLED|CC_WIDE|CCWIDESTYLED Возможности вывода линий. Стандартный ответ: LC_P0LYLINE|LC_MARKER|LC_P0LYMARKER|LC_WIDE|LC_STYLED| LC_WIDESTYLED | LCJNTERI0RS
Контекст устройства 301 Индекс Пример Возвращаемое значение и смысл P0LYG0NALCAPS OxFF TEXTCAPS CLIPCAPS RASTERCAPS ASPECTX ASPECTY ASPECTXY LOGPIXELSX LOGPIXELSY SIZEPALETTE NUMRESERVED 0x7807 0х7е99 36 36 51 96 или 120 96 или 120 0, 16 или 256 2 или 20 Возможности вывода многоугольников. Стандартный ответ: PC_P0LYG0N|PC_RECTANGLE|PC_WINDP0LYG0N| PC_SCANLINE | PC_WIDE | PC_STYLED | PC_WIDESTYLED | PC_INTERI0RS. Обратите внимание: PCP0LYP0LYG0N и PCPATHS не включаются в стандартный ответ, но это не значит, что они не поддерживаются устройством — просто при сообщении возможностей допущена ошибка Возможности вывода текстовых строк. Информация сообщается драйвером Возможности отсечения. Стандартный ответ: CPRECTANGLE. Обратите внимание: это не означает, что устройство не может выполнять отсечение по сложным регионам Растровые возможности. Частично сообщаются драйвером, частично берутся из стандартного ответа: RC_BITBLT|RC_BITMAP64|RC_GDI20_OUTPUT|RC_DI_BITMAP| RC_DIBT0DEV | RCJIGF0NT | RCJTRETCHBLT | RCJLOODFILL | RC_STRETCHDIB|RC_0P_DX_0UTPUT Относительная ширина пиксела устройства в интервале от 1 до 100. Информация сообщается драйвером Относительная высота пиксела устройства в интервале от 1 до 100. Информация сообщается драйвером Относительная диагональ пиксела устройства, Sqrt(ASPECTX*2+ASCPECTY*2). Информация сообщается драйвером Логическое разрешение в точках на дюйм (dpi) по ширине. Информация сообщается драйвером Логическое разрешение в точках на дюйм (dpi) по высоте. Информация сообщается драйвером Количество элементов в системной палитре. Значение действительно лишь в том случае, если RASTERCAPS содержит флаг RC_PALETTE Количество зарезервированных элементов в системной палитре. Значение действительно лишь в том случае, если RASTERCAPS содержит флаг RCPALETTE. Ответ генерируется в зависимости от системных настроек C0L0RRES 24 Количество бит в представлении одного пиксела Продолжение &
302 Глава 5. Абстракция графического устройства Таблица 5.3. Продолжение Индекс Пример Возвращаемое значение и смысл PHYSICALWIDTH О PHYSICALHEIGHT О PHYSICALOFFSETX О PHYSICALOFFSETY О SCALINGFACTORX 100 SCALINGFACTORY 100 VREFRESH 60 DESKT0PH0RZRES 1024 DESKT0PVERTRES 768 BLTALIGNMENT 0 SHADEBLENDCAPS 0 C0L0RMGMT CAPS 2 Для устройств создания жестких копий: ширина физической страницы в единицах устройства. Информация сообщается драйвером Для устройств создания жестких копий: высота физической страницы в единицах устройства. Информация сообщается драйвером Для устройств создания жестких копий: ширина непечатаемого левого поля в единицах устройства. Информация сообщается драйвером Для устройств создания жестких копий: высота непечатаемого верхнего поля в единицах устройства. Информация сообщается драйвером Для устройств создания жестких копий: коэффициент масштабирования по оси х Для устройств создания жестких копий: коэффициент масштабирования по оси у Вертикальная частота развертки для текущего видеорежима. Информация сообщается драйвером Ширина рабочего стола в пикселах (отличается от ширины одного экрана при работе с несколькими мониторами) Высота рабочего стола в пикселах (отличается от высоты одного экрана при работе с несколькими мониторами) Предпочтительное выравнивание при блиттинге на устройство. Нулевое значение означает, что для устройства используется аппаратное ускорение, поэтому выравнивание может быть произвольным. Информация сообщается драйвером Возможности альфа-наложения и градиентной заливки. Информация сообщается драйвером Возможности управления цветом. Информация сообщается драйвером Перед выводом на устройство создания жестких копий хорошо написанная программа всегда должна проверять точные размеры бумаги и полей. Следует помнить, что приложение может изменить ориентацию листа и перейти от стандартной книжной ориентации к альбомной; при этом ширина и высота листа, а также левые и верхние поля меняются местами.
Контекст устройства 303 Для приложений, работающих под управлением Windows NT/2000, проверка графических возможностей устройства (CURVECAPS, LINECAPS, POLYGONCAPS, CLIPCAPS и т. д.) уже не столь важна, поскольку при необходимости графический механизм помогает драйверу устройства в обработке графических команд GDI. Проверяя возможности контекста устройства, приложение также может оптимизировать свое быстродействие. Например, если устройство не поддерживает градиентных заливок, приложение может имитировать заливку своими средствами, упростить или вообще отказаться от градиентной заливки. Приложения, работающие в 8-разрядных режимах с 256 цветами, могут использовать графические заготовки с уменьшенным количеством цветов (вместо 24-разрядных). В системе Windows NT/2000 графический механизм хранит гораздо больше информации об устройстве, чем можно получить при помощи функции Get- DeviceCaps, предназначавшейся для 16-разрядного GDI. Драйвер графического устройства должен сообщить информацию о выводе стилевых линий, о многочисленных полутоновых параметрах, о поддержке устройством цветового пространства CIE (Commission Internationale de L'Eclairage) и некоторых внутренних графических возможностях. Например, графическому механизму может потребоваться информация о том, поддерживает ли устройство непрозрачные прямоугольники при выводе текста, поддерживается ли спулинг EMF, допускается ли закраска непрозрачных текстовых прямоугольников произвольной кистью, поддерживаются ли дробные координаты при выводе текста, поддерживается ли 4-разрядное сглаживание текста и т. д. Щшш<ЩШ Б щ ?<4% TECHNOLOGY DRIVERVERSION H0RZSIZE VERTSIZE H0RZRES VERTRES L0GPIXELSX L0GPIXELSY BITSPIXEL PLANES NUMBRUSHES NUMPENS NUMMARKERS NUMFONTS NUMCOLORS PDEVICESIZE CURVECAPS LINECAPS ЩМШШ. 1 0x4000 320 mm 240 mm 1152 pixels 864 pixels 96 dpi 96 dpi 32 bits 1 planes -1 -1 0 0 -1 0 Iff fe Ытштшшж , , •з$Г~* Рис. 5.6. Получение информации о возможностях графического устройства
304 Глава 5. Абстракция графического устройства Функция GetDeviceCaps работает элементарно и не требует пространных комментариев. В программе DEVICE кнопка GetDeviceCaps на странице Display Devices открывает диалоговое окно с перечнем всех флагов устройства (рис. 5.6). Атрибуты в контексте устройства В графических командах GDI используются два вида данных — атрибуты, общие для разных команд, и значения, специфические для конкретной команды. Конечно, было бы крайне неэффективно требовать, чтобы общие параметры и атрибуты снова и снова указывались в программе. В Windows GDI в контексте устройства хранятся следующие атрибуты: О система координат, режим отображения и мировое преобразование; О основной цвет, цвет фона, палитра и параметры управления цветом; О параметры вывода линий; О параметры заливки областей; О шрифт, межсимвольные интервалы и выравнивание текста; О режим масштабирования растров; О регион отсечения; О ряд других атрибутов. У каждого атрибута имеется набор допустимых значений и значение по умолчанию, заносимое в контекст устройства при создании. Для каждого атрибута обычно определяется пара функций Win32 API, предназначенных для чтения и присваивания ему нового значения. В табл. 5.4 перечислены атрибуты контекста устройства, значения по умолчанию и функции для работы с ними. Таблица 5.4. Атрибуты контекста устройства (Windows 2000) Атрибут Ассоциированный манипулятор окна Базовая точка контекста Растр Графический режим Режим отображения Габариты области просмотра Значение по умолчанию NULL Растр 1x1 GM_C0MPATIBLE MMJTEXT {1,1} Функции доступа WindowFromDC (только чтение) GetDCOrgEx (только чтение) GetCurrentObject, SelectObject (только для совместимых контекстов устройств) GetGraphicsMode, SetGraphicsMode GetMapMode, SetMapMode GetVi ewportExtEx, SetVi ewPortExtEx, Базовая точка области про- {0, 0} смотра SealeViewportExtEx GetVi ewportOrgEx, SetViewportOrgEx, OffsetVi ewportOrgEx
Контекст устройства 305 Атрибут Значение по умолчанию Функции доступа Габариты окна Базовая точка окна {1,1} {0,0} GetWindowExtEx, SetWindowExtEx, ScaleWindowExtEx GetWindowOrgEx, SetWindowOrgEx, OffsetWindowOrgEx Преобразование Цвет фона Цвет текста Палитра Регулировка цвета Цветовое пространство Режим ICM Профиль ICM Текущая позиция пера Бинарная растровая операция Режим вывода фона Логическое перо Цвет пера DC Направление дуг Угловой лимит Логическая кисть Цвет кисти DC Базовая точка кисти Режим заполнения многоугольников Матрица тождественного преобразования Системный цвет фона Черный DEFAULT_PALETTE {0,0} R2_C0PYPEN OPAQUE BLACK_PEN 10.0 WHITE_BRUSH {0,0} ALTERNATE GetWorldTransform, SetWorldTransform, Modi fyWorldTransform GetBkColor, SetBkColor GetTextColor, SetTextColor GetCurrentObject, EnumObjects, SelectPalette GetColorAdjustment SetColorAdjustment GetColorSpace, SetColorSpace SetlCMMode GetlCMProfile, SetlCMProfile GetCurrentPositionEx, MoveToEx, LineTo, BezierTo,... GetR0P2, SetR0P2 GetBkMode, SetBkMode SelectObject, GetCurrentObject GetDCPenColor, SetDCPenColor GetArcDirection, SetArcDirection GetMiterLimit, SetMiterLimit SelectObject, GetCurrentObject GetDCBrushCoior, SetDCBrushColor GetBrushOrgEx, SetBrushOrgEx GetPolyFillMode, SetPolyFillMode Продолжение &
306 Глава 5. Абстракция графического устройства Таблица 5.4. Продолжение Атрибут Значение по умолчанию Функции доступа Режим масштабирования растров Логический шрифт Дополнительные межсимвольные интервалы Флаги подстановки шрифтов Выравнивание текста Выключка текста (выравнивание по ширине) Раскладка Траектория Область отсечения Метарегион Ограничивающие прямоугольники STRETCH_ANDSCANS Системный шрифт TA_TOP|TA__LEFT {0,0} Клиентская область, вся поверхность устройства GetStretchBltMode, SetStretchBltMode SelectObject, GetCurrentObject, GetCharWidth32, GetKerningPairs, GetTextMetrics,... GetTextCharacterExtra, SetTextCharacterExtra SetMapperFlags GetTextAl1gn, SetTextAl1gn SetTextJustification (только присваивание) GetLayout, SetLayout BeginPath, ClosePath, EndPath, GetPath SelectObject, GetClipBox, GetClipRgn, SelectCli pRgn, ExcludeCli pRect, IntersectClipRect GetMetaRgn, SetMetaRgn GetBoundsRect, SetBoundsRect Эти атрибуты контекста устройства будут подробно рассмотрены ниже. А пока вы лишь получили общее представление о количестве информации, хранящейся в контексте устройства. В таблице перечислены атрибуты контекстов устройств, поддерживаемые в Windows 2000. Список включает почти все атрибуты, поддерживаемые на разных Windows-платформах. Большинство атрибутов было унаследовано из 16- разрядного Windows API. Некоторые атрибуты (например, мировые преобразования координат) в полной мере поддерживаются только в Windows NT/2000. В Windows 98 и Windows 2000 появился ряд новых атрибутов — например, кисть DC, перо DC и атрибуты ICM. В программе DEVICE кнопка DC Attributes на странице Display Devices вызывает диалоговое окно для вывода списка всех доступных атрибутов контекста (рис. 5.7). В этом диалоговом окне предусмотрено несколько возможностей получения манипулятора контекста устройства. В частности, программа может создать новый контекст функцией CreateDC или получить контексты устройств, связанные с различными окнами.
Контекст устройства 307 Рис. 5.7. Атрибуты контекста устройства Связь контекста устройства с окном Контекст устройства, созданный функцией CreateDC, можно рассматривать как графическую поверхность, распространяющуюся на всю площадь устройства — на весь экран для экранных устройств или на всю страницу для принтеров. Однако функция CreateDC не предоставляет стандартный способ получения контекста устройства в среде Microsoft Windows и обычно применяется только при работе с устройствами создания жестких копий (таких, как принтеры). Графический вывод в многооконной среде Графический вывод в первую очередь ориентируется на экран монитора — ресурс, совместно используемый несколькими приложениями в операционной системе Windows. Обычные приложения Windows работают в оконном режиме, при котором вывод каждого приложения ограничивается определенной частью экрана. Окно обычно имеет прямоугольную форму, а его параметры указываются при вызове функции CreateWindow. Впрочем, операционная система позволяет создать окно произвольной формы — в виде прямоугольника с закругленными углами, эллипса или многоугольника. Чтобы изменить форму окна, достаточно создать объект региона и передать его манипулятор функции SetWindowRgn. Регион задается в экранных координатах относительно базовой точки окна. Ниже приведен простой пример создания обычного окна с последующим преобразованием его к эллиптической форме.
308 Глава 5. Абстракция графического устройства const TCHAR szProgram [] - JT'Window Region"); const TCHAR szRectWin [] = _T("Rectangular Window"); const TCHAR szEptcWin [] = _T("Elliptic Window"); int WINAPI WinMain(HINSTANCE hlnstance. HINSTANCE. LPSTR, int) { HWND hWnd = CreateWindow(_T("EDIT"), NULL. WS_OVERLAPPEDWINDOW, 10. 10. 200. 100. GetDesktopWindowO. NULL, hlnstance. NULL): ShowWindow(hWnd. SW_SH0W); SetWindowText(hWnd. szRectWin); MyMessageBoxCNULL. szRectWin. szProgram. MB_0K); HRGN hRgn « CreateEllipticRgnCO. 0. 200. 100): SetWindowRgn(hWnd. hRgn. TRUE); SetWi ndowText(hWnd. szEptcWi n); MessageBox(NULL. szEptcWin. szProgram. MB_0K); DestroyWindow(hWnd); return 0; } На рис. 5.8 изображены два окна: обычное прямоугольное и эллиптическое. Прямоугольное окно (слева) имеет обычную для окон верхнего уровня рамку и строку заголовка, тогда как у эллиптического окна рамка и строка заголовка отсекаются по границам эллиптического региона. Rectangular Window elliptic Window Рис. 5.8. Окна разной формы ПРИМЕЧАНИЕ ■ Непрямоугольные окна и специализированные неклиентские области считаются новым течением в разработке пользовательских интерфейсов Windows-приложений. При выводе в окнах нетрадиционной формы используются регионы, определяемые при помощи растровых или векторных изображений. Обработка неклиентских сообщений заменяет стандартную обработку неклиентской области.
Контекст устройства 309 Несколько окон, одновременно находящихся на экране, могут перекрывать друг друга. В старой реализации Microsoft Windows передние окна полностью или частично блокировали окна, находящиеся сзади, хотя в своей последней реализации Windows 2000 компания Microsoft стремится к интерпретации окон как экранных объектов, которые могут объединяться с использованием различных операторов. В результате перекрытия у каждого окна появляется еще один важный атрибут — видимая часть. Окно делится на две части: клиентскую и неклиентскую. Неклиентская часть включает рамку, строку заголовка, строку меню, панели инструментов, полосы прокрутки и прочие служебные элементы. К клиентской части относится вся площадь окна, не входящая в неклиентскую часть, — как правило, это прямоугольная область в середине окна. Вывод в неклиентской области обычно обеспечивается стандартной функцией окна, DefWindowProc, представляемой модулем управления окнами (user32.dll). DefWindowProc имеет доступ к стилю окна, тексту окна, информации фокуса и другим данным, необходимым для прорисовки неклиентской области. В большинстве случаев пользовательское приложение обеспечивает вывод в клиентской части окна. В многозадачных средах типа Windows состояние экрана неустойчиво. В любой момент времени какое-нибудь приложение может вызвать временное окно, вывести информацию и прекратить свое существование. Приложения, продолжающие работать, несут полную ответственность за восстановление нормального изображения на экране. В этом случае операционная система посылает окнам, чье изображение было нарушено, сообщения с запросом на перерисовку. Окно- получатель не знает, что произошло на экране, поэтому ему нужно точно сообщить, как часть изображения нуждается в перерисовке. В противном случае перерисовка всего окна приведет к напрасному расходованию драгоценных ресурсов. Ниже перечислены факторы, которые должны учитываться контекстом устройства при выводе в окне. О Базовая точка — левый верхний угол окна. О Размеры — ширина и высота окна. О Регион окна — подмножество прямоугольной области, определяемой базовой точкой и размерами окна (для окон нетрадиционной формы). О Видимость — перерисовывается только видимая (не перекрытая) часть региона окна. О Все окно или клиентская область — хочет ли приложение обеспечить специализированную прорисовку неклиентской области или его интересы ограничиваются клиентской областью? О Обновляемая область — участок окна, реально нуждающийся в обновлении. Получение контекста устройства, связанного с окном Функция CreateDC не позволяет приложению создать контекст устройства, связанный с конкретным окном. В Win32 API предусмотрено несколько функций для создания контекстов устройств, связанных с окнами:
310 Глава 5. Абстракция графического устройства HDC GetWindowDC (HWND hWnd); HDC GetDC(HWND hWnd); HDC GetDCEx(HWND hWnd, HRGN hrgnClip. DWORD flags); HDC BeginPaintCHWND hWnd, LPPAINTSTRUCT lpPaint); Функция GetWindowDC возвращает контекст устройства, подготовленный к выводу во всем окне, включая строку заголовка, меню и полосы прокрутки. Базовая точка контекста устройства совпадает с базовой точкой окна. Функция GetDC возвращает контекст устройства, подготовленный к выводу только в границах клиентской части окна. Базовая точка контекста устройства совпадает с базовой точкой клиентской области. Ни GetWindowDC, ни GetDC не учитывают флагов стиля WS_CLIPCHILDREN и WS_CLIPSIBLINGS. Другими словами, возвращаемые ими манипуляторы позволяют осуществлять вывод поверх дочерних и соседних (sibling) окон. После завершения вывода контекст устройства необходимо вернуть операционной системе. Функция ReleaseDC освобождает ресурсы, связанные с манипулятором контекста устройства, полученным при вызове GetWindowDC, GetDC или GetDCEx. Вызову BeginPaint должен быть сопоставлен парный вызов EndPaint. Контекст устройства содержит ряд параметров, отражающих его связь с конкретным окном. Функция WindowFromDC возвращает манипулятор окна, с которым связан данный контекст. Базовая точка контекста устройства, возвращаемая функцией GetDCOrgEx и всегда равная {0,0} для контекстов, созданных функцией CreateDC, содержит экранные координаты базовой точки окна или его клиентской области. Кроме этих документированных атрибутов, доступных только для чтения, контекст устройства содержит ряд недокументированных полей. В частности, в контексте устройства хранится базовая точка и размеры окна, связанного с контекстом. Мы будем называть этот прямоугольник прямоугольником вывода (display rectangle), хотя на самом деле он относится только к выводу клиентской области окна (отсюда и его «официальное» называние erclWindow). Информация о видимой части региона окна хранится в объекте-регионе. Если окно полностью видно на экране, видимый регион контекста представляет собой прямоугольник, размеры которого совпадают с размерами изображения. Если угол окна закрыт другим окном, видимый регион контекста изменяется и представляет собой объединение двух прямоугольников. Например, видимый регион контекста устройства, возвращаемого функцией GetWindowDC, может объединять два прямоугольника: {10,10,210,62} и {10,62,92,110}. Обратите внимание: значение атрибута видимого региона присваивается перед возвращением из GetWindowDC или GetDC, однако атрибут продолжает обновляться операционной системой по мере того, как другие окна создаются и уничтожаются, передают фокус, изменяют размеры или положение на экране. Такой подход гарантирует, что связь манипулятора контекста устройства с конкретным окном будет сохраняться и при этом вам не придется беспокоиться об изменениях в атрибутах окна. Если с окном связан нестандартный регион окна, назначенный функцией SetWindowRgn (в приведенном выше примере — эллипс), то видимый регион контекста устройства представляет собой видимое подмножество пересечения региона окна с прямоугольником окна. Другими словами, в видимый регион контекста устройства включаются только те пикселы, которые удовлетворяют всем
Контекст устройства 311 трем условиям — они входят в регион окна, назначенный функцией SetWindowRgn, принадлежат прямоугольнику окна и являются видимыми. В нашем примере с эллиптическим окном видимый регион состоит из десятков прямоугольников или, выражаясь точнее, — из десятков структур SCAN, используемых для более эффективного представления регионов в Windows NT/2000. Третий способ получения контекста устройства, связанного с конкретным окном, предоставляет функция GetDCEx. Функция GetDCEx по сравнению с GetDC или GetWindowDC получает два дополнительных параметра — объект-регион и флаг. Хотя в документации Microsoft утверждается, что регион определяет границы области отсечения, он не совпадает с регионом отсечения, которым приложение управляет при помощи функций SelectClipRgn и ExtSelectClipRgn. Поскольку в электронной документации MSDN не упоминаются два важных флага функции GetDCEx, мы перечислим все флаги здесь (табл. 5.5). Таблица 5.5. Флаги GetDCEx Флаг Описание DCX_WINDOW DCX_CACHE DCX_PARENTCLIP DCX_CLIPSIBLINGS DCX_CLIPCHILDREN DCX_NORESETATTRS DCX_LOCKWINDOWUPDATE DCXJXCLUDERGN DCXJNTERSECTRGN DCXJXCLUDEUPDATE DCXJNTERSECTUPDATE DCXJALIDATE 0x10000 Вернуть контекст устройства для прямоугольника окна (вместо прямоугольника клиентской области) Использовать контекст устройства из кэша диспетчера окон, даже если у класса окна установлен флаг стиля CS0WNDC или CS_CLASSDC Использовать прямоугольник и видимый регион родительского окна, не обращая внимания на флаги стиля родительского окна WSCLIPCHILDREN и CS_PARENTDC Исключить из видимого региона все регионы соседних окон Исключить из видимого региона все регионы дочерних окон Не восстанавливать значения по умолчанию для атрибутов контекста устройства Игнорировать блокировку обновления, установленную функцией LockWindowUpdate Исключить регион, заданный параметром hrgnClip, из видимого региона Построить новый видимый регион как пересечение региона, заданного параметром hrgnClip, с текущим видимым регионом Исключить обновляемый регион окна из видимого региона Построить новый видимый регион как пересечение обновляемого региона с текущим видимым регионом Объявить содержимое окна действительным — другими словами, сбросить обновляемый регион Недокументированный флаг, который автоматически делает вызов GetDCEx успешным
312 Глава 5. Абстракция графического устройства При таком обилии флагов GetDCEx может использоваться для замены других функций. Скажем, вызов GetDCEx(hWnd, NULL, DCX_WINDOW|DCX_NORESETATTRS) легко заменяет GetWindowDC(hWnd), а вызов GetDCEx(hWnd. NULL, DCXNORESETATTRS) заменяет GetDC(hWnd). При помощи дополнительных флагов можно отменить использование системой контекста устройства, принадлежащего окну или классу, а также исключить из видимого региона соседние и дочерние окна. Кроме того, функция GetDCEx позволяет видоизменить видимый регион с использованием дополнительного параметра-региона или обновляемого региона окна и даже сбросить данные обновляемого региона окна. Мы добрались до последнего способа создания контекста устройства, связанного с конкретным окном. Функция BeginPaint возвращает контекст устройства, предназначенный для обработки сообщения WMPAINT. Если рассматривать BeginPaint только с точки зрения возвращаемого контекста, ее можно реализовать следующим образом: HDC BeginPaintO(HWND hWnd. LPPAINTSTRUCT lpPaint) { DWORD flags = 0; if ( GetWindowLong(hWnd, GWLJTYLE) & WS_CLIPCHILDREN) flags |= DCX_CLIPCHILDREN; if ( GetWindowLong(hWnd. GWL_STYLE) & WS_CLIPSIBLINGS) flags |= DCX_CLIPSIBLINGS; return GetDCEx(hWnd. NULL, flags | DCXJNTERSECTUPDATE | DCXJALIDATE); } Функция BeginPaint проверяет стиль окна и определяет, нужно ли исключить из видимого региона дочерние и соседние окна, после чего определяет пересечение видимого региона с обновляемым регионом окна. При этом содержимое окна объявляется действительным, то есть обновляемый регион сбрасывается. Флаги DCXCACHE и DCXNORESETATTRS в данном случае не используются, поэтому функция GetDCEx должна проверить стиль окна и узнать, как следует поступить в этой ситуации. Впрочем, настоящая реализация BeginPaint решает и другие задачи. Например, если каретка находится в выводимом регионе, BeginPaint скрывает ее, чтобы предотвратить возможное стирание каретки. Функция BeginPaint посылает сообщение WMERASEBKGND обработчику сообщений окна. Если приложение обрабатывает это сообщение, оно получает возможность вывести однородный или растровый фон. Если сообщение передается стандартной функции окна DefWindowProc и в классе окна имеется кисть для закраски фона, то эта кисть используется для стирания перерисовываемого региона. Кроме того, функция BeginPaint также должна занести в структуру PAINTSTRUCT манипулятор созданного контекста устройства, ограничивающий прямоугольник перерисовываемого региона и некоторые флаги. Вероятно, вы достаточно четко представляете себе отличия между контекстом устройства, связанным с конкретным окном, и контекстом, созданным функцией CreateDC. Главное отличие заключается в том, что к числу атрибутов первого относится прямоугольник вывода, являющийся подмножеством поверхности
Контекст устройства 313 устройства, и объединенный видимый регион, который строится с учетом таких факторов, как регион окна, отсечение дочерних и соседних окон, видимых частей и обновляемого региона окна. Общий контекст устройства Необходимо ответить еще на один вопрос, который нередко приводит к недоразумениям, — откуда берутся контексты устройства, возвращаемые функциями GetDC, GetWindowDC, GetDCEx и BeginPaint? В прежние времена операционная система Windows работала в реальном режиме на компьютерах с 640 Кбайт памяти. Контекст устройства, занимавший почти 200 байт памяти, считался большой структурой, а создание контекста устройства с загрузкой драйвера, поиском точек входа и настройкой атрибутов на 20-мегагерцовых компьютерах происходило довольно медленно. Модуль управления окнами (USER) пять раз вызывал функцию CreateDC и создавал кэш с пятью контекстами устройств. Функции GetDC, GetWindowDC и BeginPaint просто брали готовые контексты из кэша. Приложения должны были освобождать манипуляторы контекста устройства сразу же после завершения вывода, чтобы ими могли воспользоваться другие приложения. В 16-разрядных версиях Windows отсутствие свободного контекста в кэше приводило к сбоям в выводе приложения. Обычный контекст устройства, полученный из кэша контекстов, называется общим (common) контекстом устройства. Ограничение в пять контекстов устройств относится только к 16-разрядным реализациям Windows. В Windows 95, 98, NT и 2000 такое ограничение уже не действует. Если в системе кончаются кэшированные контексты устройств, она создает и использует новый контекст. В этой сфере Windows NT/2000 отличается от Windows 95/98. Реализация Windows NT/2000 основана на полноценной 32-разрядной архитектуре, при которой каждый процесс работает в собственном адресном пространстве. Хотя большинство ресурсов GDI совместно используется на уровне системы, манипуляторы объектов GDI привязываются к конкретным процессам; это означает, что контекст устройства может использоваться только процессом, создавшим этот контекст. Windows 95 и 98 основаны на усовершенствованной 16-разрядной реализации GDI, в которой большие структуры данных (такие, как контексты устройств) перемещаются в отдельную 2-мегабайтную кучу. Для сравнения стоит заметить, что в 16-разрядных версиях Windows объем кучи GDI равен 64 Кбайт. Классовый контекст устройства Флаг CSCLASSDC поля стилей структуры WNDCLASS сообщает модулю управления окнами, что для данного класса следует создать контекст устройства, совместно используемый всеми окнами класса. Такой контекст называется классовым контекстом устройства (class device context). Классовый контекст создается при создании первого экземпляра окна данного класса и инициализируется значениями по умолчанию.
314 Глава 5. Абстракция графического устройства При вызове функций GetDC, GetWindowDC и BeginPaint для окна, относящегося к этому классу, возвращается контекст устройства, связанный с классом окна, с обновленным прямоугольником вывода, видимым регионом и пустой областью отсечения. Все остальные атрибуты классового контекста (логическое перо, цвет текста, режим отображения и т. д.) сохраняют прежние значения. После завершения вывода функция ReleaseDC или EndPaint возвращает контекст устройства классу, не уничтожая его и не сбрасывая значения атрибутов. Классовый контекст устройства уничтожается лишь с уничтожением последнего окна класса. Если вы где-нибудь читали, что для классового контекста устройства можно опускать вызовы ReleaseDC и EndPaint, поскольку они все равно ничего не делают, — забудьте об этом. Подобные рекомендации вредны; ради ничтожной выгоды вы можете нарваться на большие неприятности. Кстати, именно EndPaint восстанавливает каретку, скрываемую при вызове BeginPaint. Классовые контексты устройств удобно использовать для управляющих окон, которые выводятся с одними и теми же атрибутами, поскольку это сокращает время на подготовку контекста к выводу и его освобождение. К числу других преимуществ классовых контекстов устройств относится экономия памяти. В наше время классовые контексты устройств поддерживаются для обеспечения совместимости. Их преимущества становятся несущественными на фоне увеличения объема памяти и быстродействия процессора, а также архитектуры защищенных адресных пространств Win32. Классовые контексты устройств не рекомендуется использовать в программировании Win32. Закрытый контекст устройства Флаг CS_0WNDC поля стилей структуры WNDCLASS сообщает модулю управления окнами, что для каждого окна, созданного на базе данного класса, должен создаваться отдельный контекст устройства. Таким образом, каждое окно на протяжении всего жизненного цикла связано со специальным контекстом устройства. Такие контексты устройств называются закрытыми (private). Закрытый контекст устройства всего один раз инициализируется значениями по умолчанию. При каждом вызове GetDC, GetWindowDC и BeginPaint загружается закрытый контекст окна с новым прямоугольником вывода и видимым регионом. Получив контекст устройства, приложение может изменять его атрибуты и выполнять графические команды. Функции ReleaseDC и EndPaint возвращают контекст устройства окну, не изменяя его, поэтому при следующем получении контекста его атрибуты (такие, как перо и кисть) сохраняют прежние значения. В документации MSDN закрытые контексты устройств описаны невразумительно (см. раздел «Private Display Device Contexts»). В частности, там утверждается, что приложение должно получать манипулятор закрытого контекста только один раз и многократно использовать его, а также — что приложение может включить обновляемый регион в обработку сообщения WM_PAINT при помощи функции BeginPaint. Закрытые контексты устройств обеспечивают максимальное быстродействие ценой максимальных затрат памяти. Контекст устройства использует ресурсы трех типов — манипулятор GDI, память в адресном пространстве пользовательского приложения и память в адресном пространстве ядра. Закрытые контексты
Контекст устройства 315 устройств имеют смысл только для окон со сложными атрибутами, подготовка которых занимает много времени, и для окон, нуждающихся в частом обновлении. Рекомендуется использовать приватные контексты лишь в тех случаях, когда фактор быстродействия значительно важнее повышенных затрат памяти и ресурсов GDI. Родительский контекст устройства Флаг CS_PARENTDC не связан с той проблемой, которую пытаются решать закрытые и классовые контексты устройств. При установке этого флага функция GetDC или BeginPaint для дочернего окна использует прямоугольник вывода и видимый регион родительского окна для подготовки контекста устройства; вот почему эти контексты устройства называются родительскими (parent). Родительский контекст устройства выделяется из кэша, поэтому его атрибуты инициализируются значениями по умолчанию. Отличие состоит в том, что родительский контекст устройства наследует прямоугольник вывода и видимый регион родительского окна, что позволяет сэкономить время на вычисление прямоугольника вывода и видимого региона дочернего окна. Флаг CS_PARENTDC учитывается лишь в простом случае, когда дочернему окну хочется задействовать параметры родительского окна при своей прорисовке. Он игнорируется в ситуациях, когда родительское окно использует закрытый или классовый контекст устройства, когда родительское окно отсекает свои дочерние окна, а также когда дочернее окно отсекает свои дочерние или соседние окна. Прочие контексты устройств До настоящего момента мы ограничивались рассмотрением контекстов устройств, созданных функцией CreateDC, и контекстов, связанных с окнами. Эти два типа контекстов обеспечивают полноценные средства для работы с устройством, то есть они позволяют получать информацию и передавать графические команды видеоадаптеру или принтеру. В среде Windows существуют и другие разновидности контекстов устройств — а именно, информационные, совместимые и метафайловые контексты. Информационный контекст устройства Иногда потребности приложения ограничиваются простым получением атрибутов графического устройства. Например, при загрузке документа текстовый редактор должен узнать у стандартного принтера размеры бумаги и полей, чтобы правильно отформатировать документ в стиле WYSIWYG. В таких ситуациях Windows позволяет создать усеченный контекст устройства, называемый информационным контекстом. Информационный контекст создается функцией CreateIC: HDC CreateIC(LPCTSTR pszDriver, LPCTSTR pszDevice. LPCTSTR pszOutput. CONST DEVMODE * pdvmlnist);
316 Глава 5. Абстракция графического устройства Функция CreateIC аналогична CreateDC, однако она работает быстрее и расходует меньше памяти. Попытки графического вывода по манипулятору информационного контекста, возвращенному CreateIC, просто игнорируются. Информационный контекст удаляется функцией DeleteDC (функции DeleteIC не существует). Совместимый контекст устройства Предполагается, что контекст устройства обеспечивает аппаратно-независимый интерфейс приложения с графическими устройствами. Однако контексты устройств, возвращаемые описанными выше функциями, позволяют выводить графику только на физических устройствах — таких, как видеоадаптеры и принтеры. Работа этих устройств обеспечивается драйверами, получающими низкоуровневые команды от графического механизма. Но в некоторых ситуациях бывает очень удобно осуществлять вывод на графическом устройстве, имитируемом в памяти в виде растра. Совместимый контекст устройства (memory device context) позволяет выполнять вывод на связанном с ним растре или копирование растра на поверхность другого графического устройства. HDC CreateCompatibleDCCHDC hDC); Параметр hDC определяет существующий контекст устройства, с которым должен быть «совместим» создаваемый контекст. Совместимый контекст устройства использует растр в качестве графической поверхности. По умолчанию при создании совместимого контекста этот растр состоит из одного пиксела. Win32 содержит функции для создания растров и их связывания с поверхностью (функция SelectObject). Совместимые контексты удаляются функцией DeleteDC. Совместимый контекст наследует многие атрибуты от своего «эталонного» контекста. Более того, для совместимого контекста функция GetDeviceCaps возвращает те же результаты, как и для эталонного контекста. Совместимый контекст устройства с флагом DT_RASPRINTER в атрибуте TECHNOLOGY способен сбить с толку функцию, работающую как с совместимыми, так и с обычными контекстами устройств. Совместимые контексты устройств — весьма полезная штука. Мы подробно рассмотрим их в главе 10, при описании аппаратно-зависимых растров (DDB) и DIB-секций. Метафайловый контекст устройства Другой разновидностью контекста, не соответствующего реальному физическому устройству, является метафайловый контекст устройства. Совместимый контекст позволяет сформировать растр с использованием графических команд GDI; метафайловый контекст устройства позволяет сохранить команды GDI в виде потока данных или дискового файла, который затем воспроизводится как аудиозапись или видеоклип. Главное отличие между этими типами контекстов состоит в том, что совместимый контекст для хранения результатов вывода создает растр с фиксированными размерами и разрешением, а метафайловый контекст
Контекст устройства 317 сохраняет векторные и растровые команды, которые затем точно масштабируются по разным размерам. Метафайловые контексты устройств создаются двумя функциями. Одна функция генерирует метафайлы Winl6, а другая — расширенные метафайлы Win32: HDC CreateMetaFi1е(LPCTSTR IpszFile); HDC CreateEndMetaFileCHDC hdcRef. LPCTSTR IpszFileName, CONST RECT * lpRect. LPCTSTR lpDescription); Как метафайлы Windows (метафайлы Win 16), так и расширенные метафайлы широко используются в коммерческих приложениях для хранения графических заготовок (cliparts). Расширенные метафайлы также занимают важное место в реализации спулинга в Windows 95, 98, NT и 2000. Метафайлам посвящена глава 16 настоящей книги. Подведем итог: контекст устройства — удобная концепция, используемая в Windows API для обеспечения аппаратно-независимого графического вывода. В этом разделе мы познакомились с разными классами контекстов устройств, рассмотрели способы их создания, атрибуты и методы для работы с атрибутами. В табл. 5.6 приведена краткая сводка разных контекстов устройств и их характеристик. Таблица 5.6. Краткая сводка контекстов устройств Тип контекста Создание, уничтожение Применение Общий контекст устройства Контекст устройства, связанный с окном CreateDC, DeleteDC GetWindowDC, GetDC, GetDCEx, BeginPaint, EndPaint, ReleaseDC Информационный контекст Совместимый контекст Метафайловый контекст CreateIC, DeleteDC CreateCompatibleDC, DeleteDC CreateMetaFile, CreateEnhMetaFile, DeleteDC Доступ ко всей поверхности устройства, вывод на первичный и вторичный экран, зеркальное воспроизведение и устройства создания жестких копий Вывод в части экранной поверхности, соответствующей видимому региону окна или его клиентской области с исключением регионов дочерних и соседних окон. Контекст устройства, возвращаемый функцией BeginPaint, ограничивает область вывода той частью, которая входит в обновляемый регион окна. Контексты этого типа делятся на обычные, классовые, закрытые и родительские Получение информации о возможностях устройства и драйвера Вывод на растровой поверхности в памяти и передача изображения в другой контекст устройства Запись команд GDI в поток данных или в файл с последующим воспроизведением
318 Глава 5. Абстракция графического устройства Формальное представление контекста устройства В предыдущем разделе были описаны разные типы контекстов устройств и их общие атрибуты. В этом разделе мы внесем некоторые уточнения на концептуальном уровне на основании информации, полученной при анализе реализации GDI в Windows 2000. Итак, контекст устройства представляет собой структуру данных, которая в графической системе Windows решает две основные задачи. Во-первых, контекст устройства обеспечивает аппаратно-независимую абстракцию, позволяющую выводить графику на различных графических устройствах, как физических (скажем, на видеоадаптере), так и логических (например, в метафайл). Во- вторых, в контексте устройства хранятся различные параметры и графические объекты, используемые графическими командами. Базовая графическая поверхность, поддерживаемая контекстом устройства, представляет собой двумерный массив пикселов, отдельно адресуемых и доступных для чтения и записи. Модель графической поверхности идеально подходит для растровых видеоадаптеров и принтеров, однако она не универсальна. Устройства, не соответствующие этой модели, не поддерживают некоторые графические операции. Например, принтеры с поддержкой PostScript позволяют только выводить на поверхность, но не разрешают читать ее содержимое, поэтому реализовать бинарные или тернарные операции на принтерах PostScript было бы затруднительно. Другой пример — метафайловые контексты, которые не позволяют получить цветовое значение пиксела. Обычно контекст устройства поддерживает запись для каждого пиксела устройства, хотя у принтера возникают проблемы с печатью пикселов на краях листа; именно поэтому контекст устройства позволяет пользовательскому приложению получить информацию о размере бумаги. Для поддержки вывода в условиях многооконной и многозадачной среды контекст устройства может быть связан с окном. Участки контекста, в которых разрешен вывод, определяются по довольно сложной схеме, находящейся под управлением модуля управления окнами. Для определения подмножества поверхности, на котором возможен вывод, контекст устройства использует следующие атрибуты. О Прямоугольник окна (window rectangle). Прямоугольная область поверхности устройства, на которой осуществляется вывод. Соответствует ограничивающему прямоугольнику окна, указанному при вызове CreateWindow. Все перемещения и изменения размеров окна автоматически отслеживаются системой и отражаются в прямоугольнике окна контекста. Функция GetDCOrgEx возвращает позицию левого верхнего угла прямоугольника окна. О Системный регион (system region). Регион, вычисляемый с учетом нескольких факторов. Первоначально системный регион совпадает с регионом окна, который обычно имеет прямоугольную форму, но также может представлять собой любой регион, указанный при вызове SetWindowRgn. Из системного региона исключаются участки, занятые дочерними или соседними окнами, если в стиле класса окна установлены соответствующие флаги. Затем исключаются все участки, закрытые в z-порядке окон на рабочем столе. Далее систем-
Формальное представление контекста устройства 319 ный регион пересекается с обновляемым регионом окна, если для получения контекста устройства была использована функция BeginPaint. В системном регионе контекста автоматически отслеживаются все перемещения окна и все изменения в z-порядке. О Метарегион (meta region) и регион отсечения (clipping region). Определяемые приложением подмножества поверхности устройства, на которые должен происходить вывод. При создании контекста устройства или его получении у модуля управления окнами метарегион и регион отсечения всегда сбрасываются в состояние всей поверхности устройства. Метарегионы плохо документированы в Win32 API; они обеспечивают дополнительный уровень отсечения. В Wn32 API существуют многочисленные функции для модификации региона отсечения в контексте устройства. О Регион Pao (Rao region). Заранее вычисленное пересечение системного региона, метарегиона и региона отсечения. Системный регион, метарегион и регион отсечения хранятся в независимых полях контекста устройства, хотя из документации следует, что системный регион определяет исходное значение региона отсечения при получении контекста устройства. Однако все функции графического вывода работают только в пересечении системного региона, метарегиона и региона отсечения. Чтобы это пересечение не рассчитывалось заново при каждом графическом вызове, графический механизм вычисляет его заранее, обновляет при всех изменениях системного региона, метарегиона и региона отсечения и сохраняет результат в специальном поле. Результат называется регионом Рао в честь программиста Microsoft по имени Рао Ре- мала (Rao Remala), который, согласно «Undocumented Windows», настоял на включении этого поля в контекст устройства. Контекст устройства обычно связывается с драйвером графического устройства, несущим полную ответственность за передачу команд графическому устройству. Интерфейс между графическим механизмом и драйвером графического устройства называется DDI (Device Driver Interface) и документируется в Microsoft DDK (Device Development Kit). Драйвер графического устройства передает графическому механизму таблицу функций косвенного вызова, реализующих вызовы интерфейса DDL Графический механизм создает структуру логического устройства для хранения информации о драйвере графического устройства. Драйвер графического устройства может существовать в нескольких воплощениях с различными параметрами — например, форматом пикселов кадрового буфера или настройками печати. Это позволяет осуществлять динамическое переключение видеорежимов и одновременный спулинг нескольких заданий. При создании очередного экземпляра драйвера устройства ему по запросу графического механизма или приложения передается структура DEVM0DE; драйвер возвращает две структуры с информацией об атрибутах и возможностях устройства и драйвера. Графический механизм сохраняет полученную информацию в структуре физического устройства. Графический драйвер также создает собственную структуру данных и передает ее манипулятор графическому механизму. В структуре физического устройства хранится большой объем информации о драйвере — размеры, возможности, ограничения, особые штриховые кисти, полутоновые узоры и т. д.
320 Глава 5. Абстракция графического устройства Структура контекста устройства содержит указатели на структуры логического и физического устройства. Из структуры физического устройства берется информация, возвращаемая пользовательскому приложению в ответ на запрос GetDeviceCaps. Кроме того, структура физического устройства сообщает графическому механизму, каким образом графические команды GDI должны разбиваться на вызовы DDI, обслуживаемые драйвером устройства. Например, поддерживает ли драйвер работу с кривыми Безье или же они должны разбиваться на сегменты? По указателям на функции косвенного вызова в структуре логического устройства графический механизм выходит на функцию, обрабатывающую тот или иной вызов DDL Таким образом, все аппаратно-зависимые аспекты графической системы Windows инкапсулируются в этих двух структурах. Кроме того, в контекст устройства входят поля, обеспечивающие его связь с окном, растром или метафайлом, а также объекты и атрибуты Win32 API. С одними полями можно работать средствами Win32 API, другие частично или полностью скрыты от пользовательских приложений. Некоторые поля доступны только для чтения (скажем, базовая точка контекста устройства); другие доступны как для чтения, так и для записи. По соображениям быстродействия некоторые часто используемые атрибуты контекстов устройств хранятся в пользовательском адресном пространстве, что позволяет легко получить их значения без переключения в режим ядра и обратно. Впрочем, основная часть контекста устройства хранится в адресном пространстве режима ядра, в котором работают графический механизм и нормальные драйверы графических устройств. GDI предпринимает особые меры по защите контекстов устройств — впрочем, как и остальных объектов GDI, которые будут рассмотрены в следующей главе. При создании контекста пользовательскому приложению предоставляется только его манипулятор, по которому приложение ссылается на контекст при вызове функций GDI. По манипулятору контекста устройства GDI находит элемент таблицы объектов GDI (см. следующую главу), содержащий указатели на обе структуры данных контекста (пользовательского режима и режима ядра). Структуру контекста устройства в Windows 2000 в некоторой степени иллюстрирует рис. 5.9. В пользовательском режиме контекст устройства представлен структурой DCATTR, содержащей практически все атрибуты и объекты, задействованные средствами Win32 API (кроме палитры, цветового пространства и т. д.). В режиме ядра используется структура DC0BJ, в которой содержится прямоугольник окна, регион отсечения, системный регион (prgnVis на рисунке), регион Рао и другие регионы. Поле PPDEV содержит указатель на структуру физического устройства, PDEVWIN32K. В полях GDI INFO, DEVINF0 и AHSURF структуры PDEVWIN32K хранится информация, полученная от драйвера устройства. Поле PLDEV содержит указатель на структуру логического устройства, LDEVWIN32K. Большая часть структуры LDEVWIN32K занята таблицей из 89 указателей на функции косвенного вызова, APFN, которая также дублируется в структуре PDEVWIN32K. Контексты устройств имеют много общего с объектами в объектно-ориентированных системах и языках типа C++. Различные атрибуты, хранящиеся в контексте устройства, соответствуют переменным класса, а таблица функций, хранящаяся в глубинах контекста устройства, в точности аналогична таблице виртуальных функций в объекте C++, содержащем виртуальные функции. Драйвер
Пример: родовой класс рамочного окна 321 графического устройства обеспечивает актуализацию абстрактного контекста, реализуя функции DDL После того как контекст устройства должным образом подготовлен, приложение работает с ним при помощи стандартного набора функций, не беспокоясь о том, как реализуются графические вызовы. ppdevnext hsemdvlck hsempointer spritestate hlfntdefault ahsurf I devinfo 1 gdiinfo 1 psurface 1 hspooler ddglobal pgraphisdev 1 pdevmode pldev 1- apfn[89] 1 1 1 nextldev 1 1 prevldev 1 1 levtype 1 1 cRefs J 1 pgdidrvinfo 1 uldrvversion 1 apfn[89] dcattr dcobj pdev_win32k Idev_win32k Рис. 5.9. Контекст устройства Windows 2000 и его структуры данных Рисунок 5.9 ни в коем случае не претендует на полноту. Обратитесь к главе 3 за дополнительной информацией или займитесь собственными исследованиями, используя либо WinDbg с расширением отладчика GDI, либо программу Fosterer из главы 3. В главе 4 представлена программа, которая модифицирует таблицу функций GDI в структуре PDEVWIN32K с целью отслеживания вызовов интерфейса DDL В главе 2 приведен пример реализации интерфейса DDI в драйвере принтера. Пример: родовой класс рамочного окна Начиная с этой главы, работа практически всех графических примитивов GDI будет поясняться конкретными примерами. Почти во всех программах, написанных ранее, пользовательский интерфейс состоял из диалогового окна с несколькими вкладками-страницами — для демонстрации GDI API этого явно недостаточно. В этом разделе мы разработаем родовой набор классов для написания Windows-программ, удовлетворяющий перечисленным ниже условиям. О Главное окно программы имеет строку заголовка, меню, системное меню и рамку, которую можно перетаскивать для изменения размеров главного окна. О В главном окне находится панель инструментов для ускоренного вызова часто используемых команд. Кнопки панели инструментов снабжаются наглядными растровыми изображениями и всплывающими подсказками (tooltips). Ill Таблица объектов GDI 1 Логическое перо 1 Логическое перо Цвет фона | Основной цвет 1 | Графический режим 1 гор2 Режим заполнения фона Режим заливки фигур strchbltmode 1 xform I 1 Базовая точка окна I ■j dhpdev dctype flgraphics Палитра 1 Цветовое пространство hdcsave Траектория prgnClip prgnMeta prgnAPI : prgnVis prgnRao erclWindow ppdev 1 hsem
322 Глава 5. Абстракция графического устройства О В главном окне присутствует строка состояния, разделенная на несколько панелей. О В оставшейся части главного окна (клиентской области) программа может выводить все, что считает нужным. В дальнейшем эта область называется «холстом» (canvas). Программа, реализующая эти требования, функционально эквивалентна базовой программе, сгенерированной мастером приложений MFC при выборе од- нодокументного интерфейса (SDI), отключении архитектуры «документ/представление» и без поддержки баз данных и элементов ActiveX. Чтобы библиотека была действительно универсальной, в нее включаются классы C++, содержащие виртуальные функции. Все классы C++ в этой книге начинаются с префикса «К»; это позволяет использовать их совместно с классами MFC, обычно начинающихся с буквы «С». Класс панели инструментов Панели инструментов реализуются следующим классом: class KToolbar { HWND mJiToolTip; UINT m_ControlID; HINSTANCE m_ResInstance: UINT m_ResId; public: HWND m_hWnd; KToolbarO { m_hWnd = NULL; mJiToolTip = NULL; m_ControlID = 0; m_ResInstance = NULL; m_ResId = 0; } void Create(HWND hParent. HINSTANCE hlnstance. UINT nControlID, const TBBUTTON * pButtons. int nCount); void Resize(HWND hParent. int width, int height); }: Класс KToolbar устроен очень просто, поэтому виртуальные функции в нем отсутствуют. Главный метод класса, Create, получает массив определений TBBUTTON, создает дочернее окно панели инструментов с кнопками и окно подсказок. Подсказки соответствуют растрам на кнопках панели. В поле dwData каждого определения TBBUTTON хранится идентификатор строкового ресурса, по которому метод Create загружает строку и включает ее в окно подсказки. Метод Resize изменяет
Пример: родовой класс рамочного окна 323 размеры окна панели инструментов в соответствии с новой шириной клиентской области родительского окна. Класс строки состояния Окно строки состояния тоже устроено очень просто. Объявление класса KStatus- Wi ndow выглядит следующим образом: typedef enum { pane_l. рапе_2. pane_3 }: class KStatusWindow { public: HWND m_hWnd; UINT m_ControlID; KStatusWindowO { m_hWnd = NULL; m_ControlID = 0; } void Create(HWND hParent, UIN.T nControlID); void Resize(HWND hParent, int width, int height); void SetText(int pane. HINSTANCE hlnst. int messid. int param=0); void SetText(int pane. LPCTSTR message); }: Метод Create создает окно строки состояния как дочернее по отношению к основному окну. Метод Resize изменяет ширину окна в соответствии с шириной клиентской части родительского окна и делит строку состояния на три панели. Два метода SetText предназначены для вывода сообщений в строке состояния. Класс холста Класс KCanvas описывает окно холста, в котором происходит весь основной вывод приложения. Класс KCanvas создается как производный от класса KWindow, описанного в главе 1. Он содержит четыре виртуальные функции, которые могут переопределяться в производных классах. class KStatusWindow; class KCanvas : public KWindow { public: virtual LRESULT WndProcCHWND hWnd. UINT uMsg, WPARAM wParam. LPARAM IParam); virtual void OnDraw(HDC hDC. const RECT * rcPaint); HINSTANCE m hlnst;
324 Глава 5. Абстракция графического устройства public: virtual BOOL OnCommand(WPARAM wParam. LPARAM lParam); KStatusWindow * m_pStatus; KCanvasO; void SetStatus(HINSTANCE hlnst. KStatusWindow * pStatus) { m_hlnst = hlnst; m_pStatus = pStatus; } virtual -KCanvasO; }: Виртуальный метод WndProc обрабатывает все сообщения, отправленные окну холста. В реализации по умолчанию обрабатываются сообщения WM_CREATE и WM_PAINT. В ходе обработки сообщения WMPAINT вызываются функции BeginPaint, KCanvas::OnDraw и EndPaint. Метод OnCommand обрабатывает сообщения WM_COMMAND, отправленные из главного окна. Позднее мы создадим класс, производный от KCanvas, который будет обрабатывать сообщения изменения масштаба и прокрутки. Класс рамочного окна Главное окно программы абстрагируется в виде класса KFrame, также производного от класса KWindow. В терминологии Windows класс KFrame воплощает рамочное окно (frame window) с интерфейсом SDI (Single Document Interface), но позднее мы создадим производный класс для реализации рамочных окон многодокументного интерфейса MDI (Multiple Document Interface). class KStatusWindow; class KCanvas; class KToolbar; class KFrame : public KWindow { typedef enum { ID_STATUSWINDOW = 101, ID TOOLBAR = 102 KToolbar * m_pToolbar; KCanvas * m_pCanvas: KStatusWindow * m_pStatus; const TBBUTTON * m_pButtons; int mjiButtons; int mjiToolbarHeight; int m_nStatusHeight; virtual LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM lParam);
Пример: родовой класс рамочного окна 325 virtual LRESULT OnCreate(void); virtual LRESULT OnSize(int width, int height): virtual BOOL OnCommand(WPARAM wParam, LPARAM lParam); public: KFrame(HINSTANCE hlnstance. const TBBUTTON * pButtons. int nCount. KToolbar * pToolbar. KCanvas * pCanvas, KStatusWindow * pStatus); virtual -KFrameO; }: Виртуальный метод WndProc обеспечивает основную обработку сообщений окна. В процессе обработки сообщения WMCREATE он вызывает метод OnCreate, в процессе обработки сообщения WMSIZE — метод OnSize, а в процессе обработки сообщения WM_COMMAND — метод OnCommand. В самом главном рамочном окне рисовать нечего, поскольку его клиентская область полностью перекрывается окнами панели инструментов, холста и строки состояния. Однако конструктор KFrame:: KFrame (...) заслуживает внимания. Мы хотим, чтобы этот класс был по возможности универсальным и подходящим для многократного использования, поэтому экземпляры KToolbar, KCanvas и KStatusWindow создаются вне класса KFrame. Указатели на них передаются конструктору класса KFrame вместе с определениями кнопок панели инструментов. Обратите внимание: вы можете создать класс, производный от KCanvas, и передать указатель на него вместо указателя на KCanvas. Реализация конструктора чрезвычайно проста: он просто сохраняет переданные параметры для последующего использования в OnCreate и других методах. Метод OnCreate — единственный метод класса, содержащий реальный код. Он вызывает методы для создания окон панели инструментов, холста и строки состояния, имеющих нужные размеры и находящиеся в нужной позиции. LRESULT KFrame::OnCreate(void) { RECT rect; // Окно панели инструментов находится // в верхней части клиентской области if ( m_pToolbar ) { m_pToolbar->Create(m_hWnd. mjilnst, ID_STATUSWINDOW, m_pButtons, mjiButtons): GetWindowRect(m_pToo1bar->m_hWnd. & rect); mjiToolbarHeight = rect.bottom - rect.top; } else mjiToolbarHeight = 0; // Окно строки состояния находится // в нижней части клиентской области
326 Глава 5. Абстракция графического устройства if ( m_pStatus ) { m_pStatus->Create(m_hWnd, ID_STATUSWINDOW); GetWindowRect(m_pStatus-<(a062>m_hWncl. & rect); m_nStatusHeight = rect.bottom - rect.top; } else m_nStatusHeight = 0; // Создать окно холста, расположенное над окном строки состояния if ( m_pCanvas ) { GetClientRect(m_hWnd, & rect); m_pCanvas->SetStatus(m_hInst. m_pStatus); m_pCanvas->CreateEx(0, _T("Canvas Class"). NULL, WSJISIBLE | WS_CHILD. 0, m_nToolbarHeight. rect.right, rect.bottom - mjnToolbarHeight - m_nStatusHeight. mJiWnd. NULL. m_r.Ir.st); } return 0; } Программа проверяет указатели на все объекты дочерних окон и вызывает методы их создания лишь в том случае, если указатель проходит проверку. В результате ни одно из дочерних окон не является строго обязательным — программа работает и без них. Система управления окнами ОС следит за тем, чтобы панель инструментов занимала верхнюю часть клиентской области, а строка состояния находилась внизу. Вызов CreateEx для окна холста учитывает это обстоятельство и производит соответствующую регулировку позиции и высоты холста. Стандартная реализация KFrame: :0nSize обеспечивает правильную позицию и размеры трех дочерних окон при изменении размеров главного окна. Первичная обработка команд меню осуществляется методом OnCommand. По умолчанию полученное сообщение передается функции KCanvas:: OnCommand. Тестовая программа Главным фактором при оценке классов рамочного окна являются их удобство и универсальность при программировании. Мы рассмотрим лишь самые интересные фрагменты программ, чтобы не повторять одно и то же снова и снова. В приведенной ниже простой тестовой программе используются все четыре класса окон. Программа создает окно со строкой заголовка, панель инструментов с двумя кнопками и подсказками, холст и окно строки состояния. По сравнению с базовой программой MFC, сгенерированной мастером, здесь многого не хватает, в том числе макросов, глобальных переменных, выделения памяти из кучи и обращений к системным DLL.
Пример: родовой класс рамочного окна 327 const TBBUTTON tbButtons[] « { { STDJILENEW. IDM_FILE_NEW. TBSTATEJNABLED. TBSTYLE_BUTTON. { 0. 0 }. IDSJILENEW, 0 }. { STDJELP. IDM_APP_ABOUT, TBSTATEJNABLED, TBSTYLEJUTTON. { 0. 0 }. IDSJELPABOUT. 0 } }: int WINAPI WinMain(HINSTANCE hinst. HINSTANCE. LPSTR IpCmd. int nShow) { KToolbar toolbar; KCanvas canvas; KStatusWindow status; KMyFrame frame(hlnst. tbButtons, 2, & toolbar, & canvas. & status); frame.CreateEx(0. JT'ClassNarne"). _J("Program Name"). WSJVERLAPPEDWINDOW, CWJJSEDEFAULT. CWJJSEDEFAULT. CWJJSEDEFAULT. CWJJSEDEFAULT. NULL. LoadMenu(hInst. MAKEINTRESOURCE(IDR_MAIN)). hinst); frame.ShowWi ndow(nShow); frame.UpdateWindowO; frame.MessageLoopO; return 0; } Примерный вид окна нашей программы показан на рис. 5.10. Create a New Document! Рис. 5.10. Пример программы, использующей родовые классы рамочного окна
328 Глава 5. Абстракция графического устройства Если вы думаете, что структура TBBUT0N здесь используется неправильно, вероятно, вы читали неверную документацию. Структура Win32 TBBUTTON состоит из семи полей. В MSDN и прочей документации не упоминается пятое поле: BYTE bReserved[2]. Компилятор C++ прощает неточности до тех пор, пока вы не начнете работать с двумя последними полями, в которых программа хранит идентификаторы строковых ресурсов подсказок. Пример программы: графический вывод в контексте устройства Графический вывод в среде Windows, как и большинство других процессов, управляется событиями. Предполагается, что приложение всегда должно уметь воспроизвести свое полное изображение, поскольку экран совместно используется несколькими окнами, принадлежащими разным приложениям. Когда возникает необходимость в перерисовке окна, функции окна посылается сообщение WMPAINT. Оно играет ключевую роль в графическом выводе, выполняемом в программах Windows, однако описать его с концептуальной точки зрения нелегко. Сообщение WM_PAINT автоматически генерируется диспетчером окон, когда окно является видимым, когда в системе нет более срочных сообщений и с окном связан непустой обновляемый регион. Обновляемый регион окна Обновляемый регион окна определяется несколькими факторами — ограничивающим прямоугольником окна; регионом, заданным функцией SetWindowRgn, и его связью с другими окнами на рабочем столе. Сообщение WMPAINT не ставится в очередь сообщений программного потока и не обрабатывается наравне с прочими сообщениями. Вместо этого при возникновении необходимости в перерисовке окна устанавливается бит, который заставляет планировщика окон напрямую вызвать обработчик сообщений окна при отсутствии других сообщений в очереди. Существует и другой способ выполнить форсированную перерисовку окна — вызвать функцию UpdateWindow. Изначально обновляемый регион окна пуст. Его состояние обновляется при вызове следующих функций: BOOL InvalidateRectCHWND hWnd. CONST RECT * lpRect. BOOL bErase): BOOL ValidateRect(HWND hWnd. CONST RECT * lpRect): BOOL InvalidateRgn(HWND hWnd. HRGN hRgn, BOOL bErase); BOOL ValidateRgnCHWND hWnd. HRGN hRgn); Функции InvalidateRect/InvalidateRgn включают прямоугольник или регион в обновляемый регион окна. Если при вызове передается параметр NULL, в обновляемый регион включается вся клиентская область окна. Функции Validate- Rect/ValidateRgn решают обратную задачу: они исключают прямоугольник или регион из обновляемого региона окна. Если при вызове передается параметр NULL, из обновляемого региона исключается вся клиентская область окна. Параметр
Пример программы: графический вывод в контексте устройства 329 bErase сообщает диспетчеру окон, следует ли генерировать сообщение стирания фона WM_ERASEBKGND при вызове BeginPaint. Обновляемый регион окна также изменяется при изменении размеров или прокрутке окна, а также при удалении, перемещении или изменении размеров другого окна, расположенного поверх данного. При изменении размеров окна генерируется сообщение WMSIZE; диспетчер окон проверяет флаги CS_HREDRAW и CS_VREDRAW в стиле класса окна (WNDCLASSEX.style), а не в стиле самого окна. Если флаг CSHREDRAW или CSJ/REDRAW установлен, то при изменении ширины или высоты окна вся клиентская область объявляется недействительной; в противном случае недействительной объявляется только добавленная область окна. Любые изменения размеров окна приводят к его немедленной перерисовке. Когда пользователь изменяет окно перетаскиванием рамки, диспетчер окон обычно лишь имитирует изменение размеров окна до того момента, когда будет отпущена кнопка мыши. В новых операционных системах семейства Windows (Windows 95, 98 и 2000) в приложении Display (Экран) панели управления имеется флажок, управляющий этим режимом. Если на вкладке Эффекты (Effects) установлен флажок Show window contents while dragging (Отображать содержимое окна при перетаскивании), сообщение об изменении размеров многократно генерируется в процессе перетаскивания. Если перерисовка окна выполняется медленно, это может привести к серьезным задержкам. Прокрутка окна или связанного с ним контекста устройства также приводит к перерисовке окна. При прокрутке окна или его клиентской области пикселы перемещаются вверх или вниз, налево или направо, и в окне появляются новые, не прорисованные участки содержимого. Такие участки тоже включаются в обновляемый регион окна. Сведения о текущем обновляемом регионе окна возвращаются двумя функциями: int GetUpdateRgnCHWND hWnd. HRGN hRgn. BOOL bErase); BOOL GetUpdateRectCHWND hWnd. LPRECT lpRect. BOOL bErase); Функция GetUpdateRgn возвращает обновляемый регион окна через манипулятор существующего региона hRgn; другими словами, перед вызовом функции манипулятор hRgn должен содержать действительный манипулятор объекта региона, а после вызова функции он содержит данные обновляемого региона окна. Функция GetUpdateRect просто возвращает ограничивающий прямоугольник для обновляемого региона окна. Параметр bErase управляет отправкой сообщения WM_ERASEBKGND в том случае, если обновляемый регион не пуст. Сообщение WM.PAINT Когда в функцию окна поступает сообщение WM_PAINT, приложение обычно вызывает функцию BeginPaint. Функция BeginPaint получает контекст устройства и инициализирует системный регион пересечением видимого региона окна с обновляемым регионом. Перед возвратом из BeginPaint обновляемый регион объявляется действительным (то есть сбрасывается), чтобы система могла начать новый цикл накопления данных обновляемого региона.
330 Глава 5. Абстракция графического устройства Помимо возвращения HDC, функция BeginPaint также заполняет структуру PAINTSTRUCT: typedef struct { HDC hdc; BOOL bErase; RECT rcPaint; BOOL fRestore; BOOL flncUpdate; BYTE rgbReserved[32]; } PAINTSTRUCT; Поле hdc содержит тот же манипулятор HDC, который возвращается функцией BeginPaint; значение используется функцией EndPaint для освобождения контекста устройства. Если флаг bErase равен TRUE, приложение должно само стереть фон окна, поскольку все попытки стирания фона завершились неудачей. Если при вызове InvalidateRect или InvalidateRgn был установлен флаг bErase (признак стирания фона), реализация BeginPaint отправляет сообщение WM__ERASEBKGND функции окна, которая должна либо обработать сообщение, либо передать его функции Def • WindowProc. Последняя использует для стирания фона манипулятор фоновой кисти, указанный в поле WNDCLASSEX. hbrBackground. Но если кисть не задана, считается, что стереть фон не удалось и эта задача должна быть решена самим приложением. Поле rcPaint содержит ограничивающий прямоугольник текущего системного региона контекста (то есть региона, нуждающегося в перерисовке). Существует несколько вариантов обработки сообщения WM_PAINT после вызова BeginPaint. Если вы пишете хоть сколько-нибудь нетривиальную программу, подумайте над тем, как оптимизировать обработку WM_PAINT. О В простейшем варианте функция окна выводит в окне все, что заблагорассудится, и перекладывает все хлопоты с отсечением на GDI. Если перерисовка связана со сложными вычислениями и большим количеством графических вызовов, могут возникнуть серьезные проблемы с быстродействием. О Нормальная реализация должна сама проверить прямоугольник rcPaint и перерисовать только те объекты, которые с ним пересекаются. При перерисовке небольших фрагментов изображения это приведет к существенному повышению быстродействия — особенно в ситуации, когда при перетаскивании рамки окна открываются новые участки. О Более изощренная реализация может напрямую работать с системным регионом. Поле rcPaint содержит ограничивающий прямоугольник системного региона, причем последний вовсе не обязан иметь прямоугольную форму. Системный регион может быть значительно меньше области, накрываемой прямоугольником rcPaint. Непосредственная прорисовка на уровне системного региона повышает быстродействие графического вывода. О Если вывод занимает много времени, стоит рассмотреть методику постепенного обновления окна. Например, на загрузку большого растрового изображения в web-браузере может потребоваться очень много времени. Обработчик сообщения WM_PAINT должен быстро отобразить информацию, имеющуюся на
Пример программы: графический вывод в контексте устройства 331 локальном компьютере и вернуть управление с последующим обновлением окна при поступлении новых данных. В промежутках пользователь может прокрутить окно, ознакомиться с отображаемой информацией и даже завершить просмотр. Системный регион контекста устройства в течение долгого времени оставался скрытым от программистов. В новых версиях заголовочных файлов Windows документируется функция GetRandomRgn, позволяющая получить информацию о системном регионе. Хотя эта функция давно экспортируется из GDI32.DLL, раньше она считалась недокументированной. int GetRandomRgn(HDC hDC, HRGN hrgn, INT iNum); Единственным документированным значением параметра iNum является значение SYSRGN, однако при вызове можно передать и другие недокументированные индексы для получения других регионов, связанных с DC (эта тема рассматривается в главе 7). Функция GetRandomRgn (hDC, hRgn, SYSRGN) копирует данные системного региона контекста устройства в данные региона, определяемого манипулятором hRgn; перед вызовом функции этот манипулятор должен соответствовать действительному объекту региона. Полученный регион раскладывается на прямоугольники функцией GetRegionData. Если все сказанное звучит слишком запутанно, не ломайте голову — весь процесс подробно рассматривается в главе 6. Перед возвращением из обработчика WM_PAINT функция окна должна вызвать функцию EndPaint, которая при необходимости освобождает ресурсы, связанные с контекстом устройства, или возвращает общий контекст в кэш. Наглядное представление сообщений перерисовки окна В нормальной реализации WM_PAINT обновляемый регион перерисовывается так, чтобы новое изображение идеально стыковалось с изображением, присутствующим на экране. Но нам как программистам хочется получить наглядное представление о сообщениях WM_PAINT — увидеть, когда они генерируются, какая часть изображения входит в системный регион и узнать, используется ли манипулятор контекста устройства многократно или каждый раз создается заново. Кроме того, нам хотелось бы понаблюдать за генерацией и обработкой других сообщений, связанных с перерисовкой (таких, как WM_NCCALCSIZE, WMJCPAINT, WMJRASEBKGND и WMJIZE). В листинге 5.1 приведена программа WinPaint, которая поможет вам лучше разобраться в использовании сообщения WM_PAINT. Программа построена на базе набора родовых классов окон, построенных в разделе «Пример: родовой класс рамочного окна». Листинг 5.1. Программа WinPaint: наглядное представление сообщений WM_PAINT // WinPaint.cpp #define STRICT #define WIN32 LEAN AND MEAN #include <windows.h> #include <assert.h> Продолжение &
332 Глава 5. Абстракция графического устройства Листинг 5.1. Продолжение #include <tchar.h> #include #include #include #include #include A. AincludeXwin.h" .\. .\include\Canvas.h" .\..\include\Status.h" A. AincludeXFrameWnd.h" A. Ainclude\LogWindow.hH #include "Resource.h" class KMyCanvas : public KCanvas { virtual void OnDrawCHDC hDC. const RECT * rcPaint); virtual LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam); int int HRGN KLogWindow DWORD mjiRepaint; m Red. m Green, m Blue m_hRegion; m_Log; m Redraw; public; BOOL OnCommand(WPARAM wParam. LPARAM IParam); KMyCanvasО { mjiRepaint = 0; m_hRegion = CreateRectRgn(0. 0. I. 1); m_Red = 0x4F m_Green = 0x8F m_Blue = OxCF m Redraw = 0; BOOL KMyCanvas:;OnCommand(WPARAM wParam, LPARAM IParam) switch ( LOWORD(wParam) ) { case IDM_VIEW_HREDRAW: case IDM VIEW VREDRAW: { HMENU hMenu = GetMenu(GetParent(m_hWnd)); MENUITEMINFO mii; memset(&mii. 0. sizeof(mii)): mii.cbSize - sizeof(mii); mii.fMask = MIIMJTATE: if ( GetMenuState(hMenu. LOWORD(wParam).
Пример программы: графический вывод в контексте устройства 333 MFJYCOMMAND) & MF_CHECKED ) mi i.fState = MFJJNCHECKED: else mii.fState - MF_CHECKED; SetMenuItemlnfoChMenu. LOWORD(wParam). FALSE. &mii); if ( LOWORD(wParam)==IDM_VIEW_HREDRAW ) m_Redraw A- WVR_HREDRAW; else m_Redraw A- WVR_VREDRAW; } return TRUE; case IDMJILEJXIT: DestroyWindow(GetParent(m_hWnd)); return TRUE; return FALSE; // Сообщение не обработано LRESULT KMyCanvas::WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM 1 Param) { LRESULT lr; switch( uMsg ) { case WM__CREATE: m_hWnd = hWnd; m_Log.Create(m_hInst. "WinPaint"); m_Log.Log("WM_CREATE\r\n"); return 0: case WMJCCALCSIZE: m_Log.Log(,,WM_NCCALCSIZE\г\n,,); lr » DefWindowProcChWnd. uMsg. wParam. 1 Pa ram); m_Log. Log ("WMJCCALCSIZE returns Xx\r\n\ lr): if ( wParam ) { lr &- - (WVRJREDRAW | WVRJREDRAW); lr |= m Jed raw; } break; case WM_NCPAINT: m_Log.Log("WM_NCPAINT HRGN X0x\r\n\ (HRGN) wParam); lr = DefWindowProc(hWnd. uMsg. wParam. IParam); m_Log.Log("WN_NCPAINT returns\r\n"); break; case WMJRASEBKGND: m_Log.Log("WM_ERASEBKGND HOC ^0x\r\n". (HOC) wParam); lr = DefWindowProc(hWnd. uMsg. wParam. IParam); Продолжение^
334 Глава 5. Абстракция графического устройства Листинг 5.1. Продолжение m_Log.Log("WM_ERASEBKGND returns\r\n"); break; case WM_SIZE: m_Log.Log("WM_SIZE type *d. width *d. height *d\r\n\ wParam, LOWORD(lParam), HIWORD(lParam)); Ir = DefWindowProc(hWnd. uMsg. wParam, IParam); m_Log.Log("WM_SIZE returns\r\n"); break; case WM_PAINT: { PAINTSTRUCT ps: m_Log.Log("WM_PAINT\r\nM); m_Log.Log("BeginPaint\r\n"); HDC hDC = BeginPaint(m_hWnd. &ps); m_Log.LogCBeginPaint returns HDC *8x\r\n". hDC); OnDraw(hDC, &ps.rcPaint); m_Log.Log("EndPai nt\r\n"); EndPaint(m_hWnd. &ps); m_Log.Log("EndPaint returns \ "GetObjectTypeU08x)=Ud\r\n", hDC. GetObjectType(hDO): m_Log.Log("WM_PAINT returns\r\n"); } return 0; default: lr - DefWindowProcChWnd. uMsg. wParam. IParam): } return lr; } void KMyCanvas::OnDraw(HDC hDC. const RECT * rcPaint) { RECT rect; GetClientRect(m_hWnd. & rect); GetRandomRgnChDC. mJiRegion. SYSRGN): POINT Origin; GetDCOrgEx(hDC. & Origin); if ( ((unsigned) hDC) & OxFFFFOOOO ) OffsetRgn(m_hRegion. - Origin.x. - Origin.y): mjiRepaint ++; TCHAR mess[64]; wsprintf(mess. _T("HDC 0x*X, OrgUd, *d)"). hDC. Origin.x. Origin.y);
Пример программы: графический вывод в контексте устройства 335 if ( m_pStatus ) m_pStatus->SetText(pane_l. mess); switch ( mjiRepaint % 3 ) { case 0: m_Red - (m_Red + 0x31) & OxFF; break case 1: m_Green= (m_Green + 0x31) & OxFF; break case 2: m Blue = (m Blue + 0x31) & OxFF; break SetTextAlign(hDC. TAJOP | TA_CENTER); int size = GetRegionData(m_hRegion, 0. NULL); int rectcount = 0; if ( size ) { RGNDATA * pRegion = (RGNDATA *) new char[size]: GetRegionData(m_hRegion, size. pRegion); const RECT * pRect - (const RECT *) & pRegion->Buffer; rectcount - pRegion->rdh.nCount; TEXTMETRIC tm; GetTextMetrics(hDC. & tm); int lineheight - tm.tmHeight + tm.tmExternalLeading; for (unsigned i=0; i<pRegion->rdh.nCount; i++) { int x = (pRect[i].left + pRect[i].right)/2; int у = (pRect[i].top + pRect[i].bottom)/2; wsprintf(mess. "WM__PAINT Xd. rect JKd". mjiRepaint. i+1): ::TextOut(hDC. x. у - lineheight. mess, _tcslen(mess)): wsprintf(mess. "(*d. *d. *d. *d)\ pRect[i].left. pRect[i].top. pRect[i].right. pRect[i].bottom); ::TextOut(hDC. x. y. mess. Jxslen(mess)); } delete [] (char *) pRegion; wsprintf(mess. _T("WM_PAINT message %6. %6 rects in sysrgn"). mjiRepaint. rectcount); if ( m_pStatus ) mj)Status->SetText(pane_2. mess); HBRUSH hBrush = CreateSolidBrush(RGB(m_Red. m_Green. mjlue)); FrameRgn(hDC. m_hRegion. hBrush. 4. 4); FrameRgn(hDC. m_hRegion. (HBRUSH) GetStockObject(WHITE_BRUSH). 1. 1); Продолжение^
336 Глава 5. Абстракция графического устройства Листинг 5.1. Продолжение DeleteObject(hBrush); } int WINAPI WinMainCHINSTANCE hlnst, HINSTANCE. LPSTR. int nShow) { KMyCanvas canvas; KStatusWindow status; KFrame frame(hlnst, NULL. 0. NULL. & canvas. & status); frame.CreateEx(0. JCClassName"). JC'WinPaint"). WS_OVERLAPPEDWINDOW. CW_USEDEFAULT. CW_USEDEFAULT. CWJJSEDEFAULT. CWJJSEDEFAULT. NULL. LoadMenu(hInst. MAKEINTRESOURCE(IDR_MAIN)). hlnst): frame.ShowWindow(nShow); frame.UpdateWindowO; frame.MessageLoopO; return 0: } Вероятно, вы ждете подробных объяснений. Длинный список включаемых файлов — верный признак того, что мы используем готовые классы. В программе задействованы классы KWindow, KCanvas, KToolbar, KFrame и новый класс KLogWindow. Класс KLogWindow управляет многострочным временным окном «EDIT», в котором хранится зарегистрированная информация. Эти и другие классы скомпонованы в библиотеку, которая подключается к программе. Класс KMyCanvas создается производным от KCanvas. В нем переопределяется функция окна, а также обработчики командных сообщений и сообщений перерисовки. Новая функция OnCommand обрабатывает две команды меню, переключающие состояние флагов перерисовки при вертикальном и горизонтальном изменении размеров. Выше уже упоминались флаги CSHREDRAW и CSVREDRAW структуры WNDCLASSEX, определяющие необходимость перерисовки клиентской области при изменении размеров окна. Функция KMyCanvas::OnCommand позволяет переключать внутренний флаг m_Redraw, учитываемый при обработке WMNCCALCSIZE. Новая функция окна обрабатывает ряд сообщений, связанных с прорисовкой окна, - WM_NCCALCSIZE, WM_NCPAINT, WM_NCPAINT, WMJRASEBKGND, WM_SIZE и, наконец, WM_PAINT. В данном случае обработка сводится к вызову стандартной функции окна DefWindowProc (исключение составляет сообщение WMPAINT, обрабатываемое методом OnDraw). Однако программа не ограничивается простой передачей управления, а еще регистрирует данные до и после обработки сообщения. При обработке WMPAINT сохраненные данные передаются до и после вызовов BeginPaint и EndPaint. При обработке сообщения WMNCCALCSIZE окну предоставляется возможность вычислить размер клиентской области. Его обработка имеет один полезный аспект — когда параметр wParam равен TRUE, функция окна должна возвращать WVR_HREDRAW и/или WVR_VREDRAW, если изменение размеров окна приводит к перерисовке всей клиентской области. Таким образом, это сообщение фактически свя-
Пример программы: графический вывод в контексте устройства 337 зывает флаги CSVREDRAW и CSHREDRAW с диспетчером окон. Программа модифицирует результат, полученный от DefWindowProc, с учетом режима, выбранного пользователем в меню программы. Таким образом, за последствиями установки этих флагов можно понаблюдать без перекомпиляции тестовой программы. Функция KMyCanvas: :0nDraw написана таким образом, чтобы сообщение WMPAINT наглядно представлялось в окне программы. Работа функции начинается с получения информации о размерах клиентской области, системного региона и базовой точке контекста устройства. Существует две разные интерпретации системного региона. В Windows NT/2000 системный регион задается в экранной (или физической) системе координат; в Windows 95/98 системный регион задается в клиентской системе координат. Программа проверяет, работает ли она в Windows NT/2000, и если проверка дает положительный результат — переходит к клиентским координатам при помощи функции Of f setRgn. Поскольку мы знаем, что 32-разрядные манипуляторы GDI используются только в Windows NT/2000, программа определяет версию операционной системы простой проверкой старшего слова манипулятора HDC. Затем программа выводит манипулятор и базовую точку контекста в первой панели строки состояния и вычисляет цвет для вывода системного региона. При обработке каждого сообщения WMPAINT программа изменяет одну из цветовых составляющих (красную, зеленую или синюю). После этого все готово к анализу региона, который может быть пустым, состоять из одного прямоугольника или из сотен прямоугольников. Программа дважды вызывает функцию GetRegionData. В первый раз функция вызывается для получения размера данных региона, а во второй — для получения самих данных. И снова не стоит подолгу вникать в смысл происходящего; подробности будут приведены в главе 6. Для каждого прямоугольника программа выводит номер и координаты центра. После обработки всех прямоугольников программа выводит номер сообщения WMPAINT и количество прямоугольников во второй панели строки состояния. Наконец, контур системного региона обводится белой рамкой толщиной один пиксел и цветной рамкой толщиной три пиксела. Теперь запустите программу и поэкспериментируйте с ней. Вы поймете, как генерируются сообщения WMPAINT и какую область они занимают. На рис. 5.11 показано, как выглядит программа при поочередном изменении размеров окна по обеим осям. Первое сообщение WMPAINT перерисовывает окно стандартных размеров. Затем мы уменьшаем размер окна; при этом генерируется второе сообщение WMPAINT, системный регион которого не содержит ни одного прямоугольника. Затем окно сворачивается и восстанавливается, в результате чего генерируется третье сообщение для перерисовки уменьшенной клиентской области (первый прямоугольник на рис. 5.11). При изменении размеров окна в одном направлении генерируются сообщения WMPAINT с системным регионом, состоящим из одного прямоугольника. Но при одновременном масштабировании окна в обоих направлениях генерируется сообщение WMPAINT с системным регионом из двух прямоугольников (прямоугольники 1 и 2 для сообщения WM_PAINT с номером 7). Если открыть и закрыть меню, сообщение WMPAINT не генерируется, поскольку система сохраняет изображение при выводе меню и автоматически восстанавливает его. Но если
338 Глава 5. Абстракция графического устройства накрыть окно программы другим окном или перетащить окно за край экрана и вернуть его на место, сообщения перерисовки обязательно появятся. Если установить флаги CSHREDRAW и CS_VREDRAW в меню View, при изменении размеров окна перерисовывается вся клиентская область, а не только вновь появившиеся участки. Если в приложении Display (Экран) панели управления установлен флажок Show window contents while dragging (Отображать содержимое окна при перетаскивании), при перетаскивании окна за рамку генерируются частые сообщения перерисовки. BeginPaint WM_NCPAINT HRGN 8( sWN_NCPflINT return; UM_ERflSEBKGND HOC JWM_ERASEBKGND reti BeginPaint return* EndPaint EndPaint returns ( WM_PftINT returns WM__NCCALCSIZE WM_NCCflLCSIZE reti WM_SIZE type 0, wj WM_SIZE returns WM PftINT й&5£&ФЛ" лэш У*** - f/M^PAINT 3, rect 'M_PAINT 4, rect (0,0,122,70) (122,0,238,70), _PAINT 6, re PAINT 7, if 38,0,328,121,0,399,1 WM_PAINT 5, rect 1 (0,70,238,124) WM_PAINT 7, rect 2 (0,124,399,181) |HDCМ&ШЩЩ>ЭД; ''ЩШlmmmtZщй^f^^^ Рис. 5.11. Последовательность отправки сообщений WM_PAINT при изменении размеров окна В окне, расположенном слева, также выводятся довольно интересные результаты. Ниже приведен протокол изменения размеров одного окна, для наглядности снабженный отступами. WM_NCCALCSIZE WM_NCCALCSIZE returns 0 WMJIZE type 0, width 581, height 206 WMJIZE returns WM_PAINT BeginPaint WMJCPAINT HRGN 9e040469 WMJCPAINT returns WMJRASEBKGND HDC 3b0105ae WMJRASEBKGND returns BeginPaint returns HDC 3b0105ae EndPaint EndPaint returns GetObjectType(3b0105ae)=0 WM_PAINT returns Когда пользователь завершает перетаскивание границы окна в новое положение, генерируется сообщение WMNCCALCSIZE, за которым следуют сообщения WMSIZE и WMPAINT. Во время обработки WMPAINT функция BeginPaint генерирует сообщение WM_NCPAINT для перерисовки неклиентских областей и сообщение WMERASEBKGND для стирания фона. При вызове WM_ERASEBKGND передается манипулятор контекста устройства, возвращенный функцией BeginPaint. Интересно заметить, что в
Итоги 339 Windows NT/2000 после выхода из EndPaint манипулятор контекста устройства, возвращенный BeginPaint, становится недействительным (GetObjectType возвращает 0), но после нескольких повторных вызовов этот манипулятор HDC появляется снова. Это доказывает, что графический механизм поддерживает глобальный кэш манипуляторов контекстов устройств. Итоги Эта глава посвящена одной из важнейших концепций графического программирования в среде Windows — контекстам устройств. Мы рассмотрели важный класс графических устройств — видеоадаптеры; узнали, как составить список экранных устройств с поддерживаемыми видеорежимами и как получить информацию о возможностях устройств. Кроме того, в этой главе описаны различные типы контекстов устройств и способы их создания. Особое внимание было уделено контекстам устройств, связанным с конкретными окнами. Также было рассмотрено управление графическим выводом в окне с использованием обновляемого региона окна. В конце главы были созданы классы C++, демонстрирующие концепции графического программирования Windows на примере наглядной обработки сообщений WM_PAINT. Однако весь материал этой главы представляет собой лишь общее описание контекстов устройств и их связи с управлением окнами. Применение контекстов устройств при графическом выводе будет подробно рассмотрено в последующих главах. Примеры программ В отличие от глав 3 и 4 примеры этой главы являются вполне обычными программами Windows. Они демонстрируют некоторые неочевидные особенности контекстов устройств и их связи с выводом в окне (табл. 5.7). Таблица 5.7. Программы главы 5 Каталог проекта Описание Samples\Chapt_05\Device Получение списка экранных устройств, видеорежимов, получение информации о возможностях устройств и атрибутах контекстов Samples\Chapt_05\EllJpse Демонстрация возможности создания прямоугольных и непрямоугольных окон Samples\Chapt_05\FrameWindow Пример программы для тестирования семейства классов рамочного окна Samples\Chapt_05\WinPaint Наглядное представление сообщений перерисовки окна, системного региона, а также флагов CS HREDRAW и CS VREDRAW
Глава 6 Системы координат и преобразования Информация обо всех объектах, представляемых приложением, хранится в структурах данных. Например, программа компьютерной верстки хранит в структурах описания абзацев текста, изображений, векторных рисунков, заголовков и колонтитулов страниц, а приложение для проектирования садовых участков работает с объектами, представляющими растения, заборы, тропинки, лужайки и т. д. Подобные структуры данных называются моделями. В этой главе нас интересует особая категория моделей — геометрические модели, описывающие размеры и местонахождение объектов, их форму, цвет, поверхность и другие свойства. Размеры и позиция объектов обычно задаются в подходящих физических единицах — например, в дюймах или метрах. При описании формы объектов могут использоваться графические примитивы (прямоугольники, круги, многоугольники и т. д.). Разные приложения моделируют окружающий мир в разных системах координат. Например, в программах компьютерной верстки при моделировании макета в качестве базовой единицы обычно выбирается пункт (1/72 дюйма), а в системе автоматизированного проектирования базовая единица может быть равна 0,1 мм. Когда пользователь пытается создать макет страницы, узор для вышивки или план садового участка, приложение должно предоставить ему средства для изменения масштаба изображения и перемещения отображаемых объектов. С точки зрения приложения было бы крайне неэффективно пересчитывать все данные о местонахождении и размере объектов, сохраненные до поступления запроса. Довольно часто объекты обладают определенным сходством, что позволяет ограничиться подробным описанием только одного из них и сконструировать остальные экземпляры при помощи операций зеркального отражения, поворота, искажения или их комбинаций. Например, изображение розового сада можно построить многократным повторением картинки с изображением розы.
Физическая система координат 341 По практическим соображениям в Win32 GDI была реализована поддержка нескольких уровней систем координат, настраиваемых при помощи матрицы преобразования и других атрибутов контекста устройства. Традиционно в GDI используется двумерная декартова система координат с двумя осями, позволяющими задать положение любой точки плоскости. Реализация Win32 API в Windows NT/2000 поддерживает четыре уровня координат. О Мировая система координат — обеспечивает аффинные преобразования в страничные координаты. Мировая система координат состоит из 232 единиц по горизонтали и 232 единиц по вертикали, поскольку в Win32 координаты представляются в виде 32-разрядных чисел. О Страничная система координат — обеспечивает ограниченные преобразования в систему координат устройства. Страничная система координат состоит из 232 единиц по горизонтали и 232 единиц по вертикали. О Система координат устройства — описывает отдельные пикселы контекста устройства; поддерживает отображение на прямоугольные области физической системы координат. Система координат устройства состоит из 227 единиц по горизонтали и 227 единиц по вертикали, поскольку во внутреннем представлении графического механизма Windows NT/2000 используются знаковые числа с фиксированной точкой, в которых 4 бита отводится под дробную часть. О Физическая система координат — состоит из пикселов графической поверхности физического устройства. Физическая система координат состоит из 227 единиц по горизонтали и 227 единиц по вертикали. ПРИМЕЧАНИЕ В Windows 95/98 используется совершенно иная реализация систем координат и преобразований. Работа Windows 95/98 GDI в значительной степени основана на 16-разрядной реализации GDI, унаследованной от Windows 3.1, которая не поддерживала мировых преобразований и усекала все координаты до 16-разрядных значений. Точнее говоря, хотя в Windows 95/98 при вызовах 32-разрядных графических функций GDI передаются 32-разрядные координаты, они усекаются до 16- разрядных величин при обращении gdi32.dll к 16-разрядной реализации GDI. Давайте рассмотрим эти системы координат в обратном порядке — от физических координат к мировым. Физическая система координат Физическая система координат используется драйвером графического устройства и представляет собой матрицу пикселов фиксированной высоты и ширины. В левом верхнем углу находится точка с координатами (0,0). Ось х направлена слева направо, а ось у — сверху вниз. В графическом механизме Windows NT/2000 координаты представляются знаковыми числами с фиксированной точкой, состоящими из 28-разрядной целой части и 4-разрядной дробной части. Точки с отрицательными координата-
342 Глава 6. Системы координат и преобразования ми, а также с координатами, превышающими ширину и высоту поверхности устройства, считаются отсеченными. Таким образом, максимальный размер физического устройства равен 227 х 227 пикселов, или примерно 1400 х 1400 мс.» при разрешении 2400 точек на дюйм (dpi). Физическую систему координат иллюстрирует рис. 6.1. (0,0) Рис. 6.1. Физическая система координат Физические координаты используются в интерфейсе DDI между графическим механизмом и драйверами графических устройств. Следует учитывать, что физические координаты могут и не соответствовать итоговой системе координат, определяющей местонахождение каждого выводимого пиксела; они являются таковыми лишь с точки зрения графической системы Windows. Драйвер устройства может дополнить графические примитивы дополнительными преобразованиями координат. Скажем, драйвер PostScript преобразует полученные физические координаты в вещественные величины, заданные в пунктах (1/72 дюйма). Сгенерированные данные PostScript могут печататься на разных принтерах в разных разрешениях. Как ни странно, в Windows не существует простых средств определения размеров физического устройства по манипулятору контекста. Вызовы GetDeviceCapsChDC, HORZRES) и GetDeviceCapsChDC, VERTRES) обычно работают нормально, но для совместимых и метафайловых контекстов они возвращают размеры эталонного контекста устройства. Для совместимого контекста устройства размеры физической поверхности определяются размерами выбранного в нем растра. Можно воспользоваться функцией GetObjectType и определить, что вы имеете дело с объектом 0BJJ1EMDC, а затем вызвать GetObject и получить копию структуры BITMAP или DIBSECTI0N растра, выбранного в совместимом контексте; в структуре хранятся размеры выбранного растра. Метафайловый контекст устройства во время построения вообще не привязывается к конкретному устройству, а его размеры могут увеличиваться и уменьшаться в процессе записи графических
Система координат устройства 343 примитивов. Заголовок расширенного метафайла (структура ENHMETAFILEHEADER) содержит информацию о размерах изображения как в логических, так и в физических координатах. Однако не все пикселы физической поверхности могут отображаться устройством. На устройствах создания жестких копий (принтерах и т. д.) существуют механические ограничения на вывод точек у края страницы. Приложение должно получить информацию о печатной части страницы при помощи функции GetDeviceCaps. Для экранного устройства физические координаты также называются экранными координатами (screen coordinates). Экранные координаты удобно использовать в операциях управления окнами. Например, функция GetWindowRect возвращает ограничивающий прямоугольник окна в экранных координатах; в параметрах таких сообщений, как WM_NCM0USEM0VE, тоже передаются экранные координаты. Система координат устройства Координаты устройства (device coordinates) используются при работе с контекстами устройств в Win32 GDI API. В обобщенном виде система координат устройства является подмножеством соответствующей физической системы координат. Для контекстов устройств, созданных функциями CreateDC, CreateIC и Create- CompatibleDC, система координат устройства идентична физической системе координат. Для контекстов устройств, связанных с конкретными окнами (то есть возвращаемых при вызове GetDC, GetWindowDC и BeginPaint), система координат устройства определяется прямоугольником окна или его клиентской области. Как и в физической системе координат, левый верхний угол системы координат устройства имеет координаты (0,0), ось х направлена слева направо, а ось у направлена сверху вниз. Зная манипулятор контекста устройства, вы можете узнать относительную позицию системы координат устройства в его физических координатах при помощи функции GetDCOrgEx. Для определения размеров системы координат устройства необходимо выяснить, соответствует ли она клиентской области окна или всему окну. После этого для манипулятора окна, возвращенного WindowFromDC, вызывается функция GetWindowRect или GetCLientRect. Рисунок 6.2 иллюстрирует систему координат устройства и ее связь с физическими координатами. Физическая система координат изображена в виде большой сетки на заднем плане, а координатам устройства соответствует маленький прямоугольник. Левый верхний угол прямоугольника соответствует точке (24,18) в физической системе координат. Возможности вывода в системе координат устройства со стороны приложения ограничиваются двумя факторами: системным регионом и метарегионом/ регионом отсечения. Как упоминалось в главе 5, системный регион окна представляет собой пересечение видимого региона окна с обновляемым регионом и находится под контролем системы управления окнами, тогда как метарегион и регион отсечения контролируются приложением. Пересечение системного -
344 Глава 6. Системы координат и преобразования региона контекста с метарегионом/регионом отсечения и определяет совокупность пикселов, с которыми приложение может работать через контекст устройства. (0,0) Физические координаты ■ (24,18) Координаты устройства X' Г St IK Рис. 6.2. Связь системы координат устройства с физической системой координат Базовая точка, размеры и системный регион контекста устройства автоматически обновляются системой; GDI ими управлять не может. Следовательно, отображение логической системы координат на физическую выполняется простым смещением (переносом базовой точки). В интерактивных графических приложениях, в которых сообщения мыши используются для выбора, перемещения и редактирования графических объектов или проверки принадлежности, возникает необходимость преобразования между физическими (экранными) координатами и координатами устройства (в системе координат окна или клиентской области). В Win32 API предусмотрено несколько функций для решения этой задачи. BOOL ClientToScreen(HWND hWnd. LPPOINT lpPoint); BOOL ScreenToClienKHWND hWnd. LPPOINT lpPoint): int MapWindowPointsCHWND hWndFrom. HWND hWndTo.LPPOINT IpPoints. UINT cPoints); Функция ClientToScreen преобразует точку (POINT) в координатах клиентской области в экранные координаты; функция ScreenToClient производит обратное преобразование. Функция MapWindowPoints преобразует массив точек из координатной системы одного окна в координатную систему другого окна. Координаты устройства широко используются в Win32 API. В области GDI регионы отсечения задаются именно в координатах устройства, а не в страничных или мировых координатах, из-за чего нередко возникают всевозможные недоразумения и проблемы. Процесс отсечения подробно рассматривается в главе 7. В области управления окнами координаты устройства обычно воплощаются в координатах, заданных по отношению к клиентской области окна. Они исполь-
Страничная система координат и режимы отображения 345 зуются для определения параметров функций CreateWindow и SetWindowPos, а также в сообщениях, связанных с местонахождением курсора мыши — таких, как WM M0USEM0VE и WM LBUTTONDBLCLICK. Страничная система координат и режимы отображения Обе рассмотренные системы координат (физическая и устройства) ограничиваются представлением в виде аппаратно-зависимого массива пикселов. Размер окна на экране с высоким разрешением обычно отличается от размера окна при низком разрешении, а толщина напечатанной линии из трех пикселов будет зависеть от разрешения принтера. Чтобы графическое программирование в меньшей степени зависело от устройства, Windows GDI позволяет приложениям создавать собственные логические системы координат, приближенные к их геометрическим моделям. В таких системах координат удобнее работать, к тому же они в значительно меньшей степени зависят от оборудования. Одной из двух логических систем координат, поддерживаемых в Win32 GDI, является страничная (page) система координат. Кстати говоря, это единственная логическая система координат, поддерживаемая 16-разрядными ОС семейства Windows и даже реализациями Win32 в Windows 95/98/CE. Вторая логическая система координат — мировые координаты — поддерживается только в Windows NT/2000. По историческим причинам в документации Windows и даже в именах функций под «логической» системой координат обычно понимается страничная система. Страничная система координат позволяет приложению строить свою геометрическую модель в произвольных 32-разрядных координатах с произвольно выбранным направлением осей и физическим масштабом. Например, в программе планирования садового участка можно выбрать базовую единицу измерения 1/8 дюйма (или один сантиметр в метрической системе), расположить базовую точку в левом нижнем углу участка, направить ось х слева направо, а ось у — снизу вверх. Такая система координат изображена на рис. 6.3. Например, если ваша лужайка имеет размеры 41 фут на 16 футов 6 дюймов, то, как показано на рисунке, ее размеры задаются парой чисел (328, 132). При отображении геометрической модели на графическом устройстве необходимо ответить на три вопроса — какую часть модели требуется отобразить, где она должна располагаться на поверхности устройства и какими должны быть ее размеры? Это позволит вам отображать разные фрагменты модели в произвольном масштабе и в произвольных точках поверхности. При отображении страничных координат в координаты устройства в Win32 API используются два понятия, часто встречающиеся в компьютерной графике, — окно (window) и область просмотра (viewport). Окном называется любая прямоугольная область в страничной системе координат — например, область, покрытая лужайкой, на рис. 6.3. Областью просмотра называется прямоугольная область в системе координат устройства. Таким образом, окно определяет отображаемую часть геометрической модели, а область просмотра — ее местона-
346 Глава 6. Системы координат и преобразования хождение на поверхности устройства. Соотношение между размерами определяет масштаб вывода. -4 f Рис. 6.3. Проектирование садового участка в логической системе координат Выражаясь точнее, окно определяется четырьмя переменными в страничных координатах: WOrgx Базовая точка окна, координата х WOrgy Базовая точка окна, координата у WExtx Горизонтальные габариты окна WExty Вертикальные габариты окна Область просмотра определяется четырьмя переменными в координатах устройства: VOrgx Базовая точка области просмотра, координата х VOrgy Базовая точка области просмотра, координата у VExtx Горизонтальные габариты области просмотра VExty Вертикальные габариты области просмотра Точка (х,у) в страничной системе координат отображается на точку (х',г/) в координатах устройства по следующим формулам: х' = (х - WOrgx) * VExtx / WExtx + VOrgx у' = (у - WOrgy) * VExty / WExty + VOrgy В этих формулах мы просто вычисляем разность между точкой (хуу) и координатами базовой точки окна, масштабируем ее в пространстве области просмотра и прибавляем к координатам базовой точки области просмотра. Преобра-
Страничная система координат и режимы отображения 347 зование точки из координат устройства в страничные координаты выполняется аналогично: х = (х1 - VOrgx) * WExtx / VExtx + WOrgx у = (у1 - VOrgy) * WExty / VExty + WOrgy Возможны следующие варианты отображений между этими системами координат. О Тождественное отображение. Окно и область просмотра задаются квартетами (0, 0, 1, 1); в этом случае х' = х, у' = у, а страничные координаты идентичны координатам устройства. О Смещение. Окно определяется квартетом (0, 0, 1, 1), а область просмотра — (dx, dy, 1, 1); в этом случае х' = х + dx, а у' = у + dy. Каждая точка страничного пространства при отображении в систему координат устройства смещается на величину (dx,dy). О Масштабирование. Окно определяется квартетом (0, 0, 1, 1), а область просмотра — (0, 0, тх, ту); в этом случае х' = х * тх, а у' = у * ту. Каждая точка страничного пространства при отображении в систему координат устройства масштабируется с коэффициентами (тх, ту). Масштаб может быть произвольным числом — целым или дробным, как большим, так и меньшим 1. Масштабирование по осям хиу выполняется независимо. О Отражение. Окно определяется квартетом (0, 0, ширина, высота), а область просмотра — (ширина,высота,-ширина,-высота)', в этом случае х' = ширина - х, а у' = высота - у. При отображении из страничной системы координат в координаты устройства рисунок может подвергаться зеркальному отражению относительно как горизонтальной, так и вертикальной осей. Отражение позволяет использовать в страничной системе координат направления осей, отличные от фиксированных направлений системы координат устройства. О Комбинированные операции. Любая комбинация перечисленных выше операций. В Win32 API поддерживаются следующие функции для настройки страничной системы координат посредством определения параметров окна и области просмотра: BOOL SetWindowOrgEx (HDC hDC. int X. int Y, LPPOINT pPoint); BOOL SetWindowExtEx (HDC hDC. int X, int Y, LPSIZE pSize); BOOL SetViewportOrgEx (HDC hDC. int X. int Y. LPPOINT pPoint); BOOL SetViewportExtEx (HDC hDC. int X. int Y. LPSIZE pSize): В последнем параметре этих четырех функций передается указатель на структуру POINT или SIZE, заполняемую данными исходного состояния контекста. Для каждой из перечисленных функций существует парная функция, возвращающая информацию об окне и области просмотра. См. описание функций GetWindowOrgEx, GetWindowExtEx, GetViewportOrgEx и GetViewportExtEx в документации Win32. На первый взгляд выглядит довольно запутанно, не правда ли? Для упрощения работы программиста в Win32 API поддерживается несколько заготовок страничных систем координат, называемых режимами отображения (mapping modes). В большинстве режимов отображения устанавливаются заранее выбранные габариты окна и области просмотра, определяющие размер единицы изме-
348 Глава 6. Системы координат и преобразования рения в страничной системе координат и коэффициент масштабирования при переходе к системе координат устройства. Впрочем, приложение может изменять положение базовой точки окна и области просмотра, что позволяет выводить разные фрагменты геометрической модели в разных частях экрана. Режим отображения контекста устройства выбирается следующей функцией: int SetMapMode(HDC hDC. int fnMapMode); Режим отображения ММ_ТЕХТ Простейший режим отображения MMJTEXT устанавливается вызовом SetMapModeChDC, ММ_ТЕХТ). Этот режим выбирается по умолчанию во вновь созданных контекстах устройств. В режиме отображения MMJTEXT используются фиксированные габариты окна и области просмотра (1,1), а базовые точки окна и области просмотра по умолчанию имеют координаты (0,0). Таким образом, по умолчанию страничные координаты в контексте устройства совпадают с координатами устройства. В режиме MMJTEXT приложение может изменять положение базовых точек окна и области просмотра, поэтому общие формулы для преобразования страничных координат в координаты устройства выглядят так: х' = х - WOrgx + VOrgx у' = у - WOrgy + VOrgy Настройка осей в режиме MMJTEXT хорошо подходит для вывода текста в стандартном направлении (слева направо, сверху вниз). Вероятно, именно этим и объясняется выбор названия режима. Простые графические приложения тоже часто используют его при работе с экраном. Если вы захотите выполнить печать в режиме MMJTEXT, вам придется самостоятельно пересчитывать координаты и масштабировать изображение, чтобы результат имел одинаковые размеры на принтерах с разным разрешением. Режим MMJTEXT не позволяет изменять относительный масштаб осей, поскольку пропорции размеров окна и области просмотра в нем жестко фиксируются. Режимы отображения MM_LOENGLISH и MMJHIENGLISH За основу физических единиц, используемых в режимах отображения MML0ENGLISH и MMHIENGLISH, взят дюйм — традиционная английская единица измерения. В режиме MML0ENGLISH одна единица в страничной системе координат соответствует 1/100 дюйма, тогда как в режиме MMHIENGLISH она соответствует 1/1000 дюйма. В режиме MML0ENGLISH один дюйм равен 100 единицам, полдюйма — 50 единицам, четверть дюйма — 25 единицам, а одну восьмую дюйма невозможно представить без потери точности. В режиме MM HIENGLISH один дюйм соответствует 1000 единиц, полдюйма — 500 единицам, четверть дюйма — 250 единицам, а одна восьмая дюйма — 125 единицам. Направление оси у в этих двух режимах совпадает с ее направлением в традиционной декартовой системе координат, то есть ось у направлена снизу вверх (см. рис. 6.3). В этом отношении режимы MML0ENGLISH и MMHIENGLISH отличаются от режима MMJTEXT, системы координат устройства и физической системы координат.
Страничная система координат и режимы отображения 349 Выбрать режим отображения MMLOENGLISH или MMHIENGLISH в приложении несложно — для этого достаточно вызвать функцию SetMapMode(hDC. MMLOENGLISH) или SetMapMode(hDC, MMHIENGLISH). GDI автоматически изменяет габариты окна и области просмотра. Ниже приведена примерная реализация этих двух режимов в функции SetMapMode: BOOL SetMapMode(HDC hDC. int fnMapMode) { // Установить в контексте режим отображения fnMapMode int mill; int div; switch ( fnMapMode) { case MMJIENGLISH: mul - 10000; div « 254: break; case MM_LOENGLISH: mul = 1000; div - 254; break; default: return FALSE; } SetWindowExtExChDC, GetDeviceCaps(hDC. HORSIZE) * mul / div. GetDeviceCaps(hDC. VERTSIZE) * mul /div. NULL); SetViewportExtEx(hDC. GetDeviceCaps(hDC. HORZRES). - GetDeviceCaps(hDC, VERTRES). NULL); return TRUE; } При установке этих двух режимов в контексте устройства используются данные о размерах устройства в физических единицах и пикселах. Скажем, при задании константы HORZRES функция GetDeviceCaps возвращает ширину поверхности физического устройства в пикселах. В режимах MMLOENGLISH и MMHIENGLISH ширина области просмотра совпадает с шириной поверхности устройства, а высота области просмотра равна высоте поверхности устройства с обратным знаком. Таким образом, ось х сохраняет то же направление, что и в системе координат устройства, а ось у направлена в обратную сторону. Ширина окна вычисляется умножением физического размера поверхности устройства на количество единиц в 1/10 дюйма и делением результата на 254. Обратите внимание: физические размеры устройства задаются в миллиметрах (один дюйм равен примерно 25,4 мм). Для экрана размером 1152 х 864 пиксела GetDeviceCaps возвращает физические размеры 320 х 240 мм. Следовательно, SetMapMode (hDC, MMHIENGLISH) устанавливает габариты окна (12 598,9449) и габариты области просмотра (1152,-864). Возможно, вас интересует, почему вместо этих величин не используется логическое разрешение, возвращаемое вызовами GetDeviceCaps(hDC.LOGPIXELSX) и GetDeviceCaps(hDC. LOGPIXELSY)? Использование логического разрешения изменило бы настройку страничной системы координат. Например, для того же экрана размером 1152 х 864 пиксела драйвер устройства возвращает логическое разре-
350 Глава 6. Системы координат и преобразования шение (96,96). Если считать, что физические размеры поверхности устройства составляют 12 х 9 дюймов, габариты окна в режиме MMHIENGLISH должны быть равны (12 000,9600). Термин «логический» в данном случае означает, что значения не являются абсолютно точными. Драйвер экрана обычно поддерживает разные размеры кадровых буферов, и видеоадаптер может подключаться к мониторам разных размеров. Пользователи обычно предпочитают, чтобы документ четко отображался на экране, а размеры изображения хорошо подходили для чтения и редактирования содержимого документа. Не так уж важно, отображается ли страница формата Letter с шириной ровно 8,5 дюйма. В нормальном разрешении драйвер экрана сообщает, что логическое разрешение равно 96 dpi, тогда как в высоком разрешении оно равно 120 dpi. А вот печатный вывод должен быть действительно точным — скажем, выходные данные бухгалтерской программы должны точно уместиться в полях готового бланка. Для устройств создания жестких копий величина логического разрешения существенна. В Windows NT/2000 интерфейс GDI при настройке режима отображения в большей степени полагается на размеры графического устройства, полученные от драйвера экрана. Драйвер экрана получает информацию о физических размерах экрана у драйвера видеопорта. Теоретически драйвер экрана мог бы сообщить точные размеры, если бы он получал информацию от монитора. Однако автору еще не приходилось видеть ни одного драйвера экрана, который бы сообщал что-то кроме 320 х 240 мм — стандартных размеров 17-дюймового монитора. Если вы работаете с режимом отображения, зависящим от физических размеров устройства, не используйте величину логического разрешения в приложении, чтобы избежать возможных несоответствий. Также следует помнить о том, что вызов SetMapMode не изменяет базовой точки окна и области просмотра. Исходные значения сохраняются, и приложение может изменять их по своему усмотрению. Если говорить о разрешении, режим MMHIENGLISH соответствует 1000 dpi, а режим MM_L0ENGLISH - 100 dpi. Режимы отображения MM_LOMETRIC и MM_HIMETRIC Метрические режимы отображения MML0METRIC и MMHIMETRIC похожи на английские режимы, рассмотренные в предыдущем разделе. В режиме MML0METRIC базовая единица равна 0,1 мм, а в режиме MM_HIMETRIC она равна 0,01 мм. Как и в двух предыдущих режимах, ось х направлена слева направо, а ось у направлена снизу вверх. Чтобы включить поддержку метрических режимов отображения, в приведенную выше псевдореализацию SetMapMode следует добавить фрагмент: case MMJIMETRIC: mul = 100; div = 1; break; case MM_L0METRIC; mul = 10; div = 1; break; Разрешение в режиме MMHIMETRIC соответствует 2540 dpi, а в режиме MM_L0METRIC - 254 dpi.
Страничная система координат и режимы отображения 351 Режим отображения MM__TWIPS Метрические режимы отображения предназначены для стран, использующих метрическую систему. Английские режимы используются в странах, продолжающих работать в классических единицах, однако для печати нужны другие единицы измерения. Традиционной единицей в типографском деле является пункт (point), равный примерно 1/72,228 (или 0,013835) дюйма. В современных системах компьютерной верстки 1 пункт нормализуется ровно до 1/72 (0,13889) дюйма, что превышает исходный размер на 0,4 %. В приложениях Windows пункты используются для измерения размера шрифта. Например, размер (кегль) стандартного типографского текста равен 10 пунктам, а межстрочные интервалы составляют 12 пунктов. В языке PostScript пункты являются основной единицей измерения, а все координаты и размеры выражаются в пунктах, заданных посредством вещественных чисел. Английские и метрические режимы не обеспечивают необходимой точности при форматировании текста, поэтому в Win32 API для подобных задач предусмотрен дополнительный режим отображения MMTWIPS. Логическая единица в MMJTWIPS равна 1/20 пункта, то есть 1/1440 дюйма; эти единицы называются тейпами (twips). Если не считать специфических единиц измерения, режим отображения MMTWIPS аналогичен другим режимам, основанным на физических единицах. Чтобы включить поддержку режима MMTWIPS, в приведенную выше псевдореализацию SetMapMode следует добавить фрагмент: case MMJTWIPS: mul = 14400; div = 254; break; He стоит и говорить о том, что режим MMTWIPS соответствует разрешению 1440 dpi. Этого разрешения обычно бывает достаточно для точного распределения интервалов при выравнивании, сжатии и расширении текста. Режимы отображения MM__ISOTROPIC В физике термин «изотропный» означает «обладающий одинаковыми свойствами по всем направлениям». В Win32 GDI режим отображения MM_IS0TR0PIC соответствует произвольному режиму отображения с одинаковым отношением габаритов окна/области просмотра по обеим осям без учета направления. В формальной записи это выглядит так: abs(WExtx / VExtx) = abs(WExty / VExty) или abs(WExtx / VExty) = abs(WExty / VExtx) Чтобы использовать изотропный режим отображения, сначала следует вызвать функцию SetMapModeC hDC, MMIS0TR0PIC). Как показали эксперименты, GDI заимствует параметры окна и области просмотра из режима отображения MML0METRIC. После этого сначала вызывается функция SetWindowExtEx, а затем — функция SetViewportExtEx; GDI следит за тем, чтобы по обеим осям выдерживался одинаковый масштаб. Реализация изотропного режима отображения в Windows NT/2000 не безупречна. Как показали наши эксперименты, в режиме MM_IS0TR0PIC функции SetWindowExtEx
352 Глава 6. Системы координат и преобразования и SetViewportExtEx сначала вызываются вполне обычным образом, после чего GDI выполняет нормализацию в соответствии с требованием изотропности. Для этого GDI выбирает среди WExtx, VExtx, WEtxy и VExty переменную с наибольшим абсолютным значением и вычисляет ее новое значение по трем оставшимся переменным. Некоторые результаты тестов приведены в табл. 6.1. Таблица 6.1. Настройка режима MMJSOTROPIC Вызов функции API (сокращенно) Габариты окна Габариты области просмотра Комментарии SetMapMode(MMJSOTROPIC) (3200,2400 (1152,-864) ) SetWindowExtEx(3,5) (3,5) SetViewportExtEx(5,3) (3,5) (518,-864) (2,3) По каким-то соображениям используются габариты MM_L0METRIC Наибольшее число 1152 заменяется величиной 864 х 3/5; погрешность составляет 0,07 % Наибольшее число 5 заменяется величиной 3x3/5 В этом примере последовательно вызываются функции SetWindowExtEx и SetViewportExtEx. Из таблицы ясно видно, что GDI пытается обеспечить изотропию, изменяя лишь число с наибольшим абсолютным значением — подобный упрощенный подход приводит к большой погрешности. Итоговые значения далеки от изотропии. В данном примере одно из возможных решений заключалось в том, чтобы присвоить окну габариты (9,15), а области просмотра — габариты (15,25); в этом случае отображение будет действительно изотропным. В GDI габариты окна и области просмотра представляются целыми числами. Для получения изотропных отображений иногда приходится выполнять аппроксимацию, которая, как показано в табл. 6.1, может привести к некоторым нарушениям изотропности. Автор рекомендует забыть о мелких удобствах, предоставляемых режимом MM_IS0TR0PIC, и работать непосредственно в режиме ММ_ ANISOTROPIC. Режим отображения MM_ANISOTROPIC Термин «анизотропный» означает «обладающий разными свойствами по разным направлениям». Впрочем, режим отображения MM_ANISOTROPIC на самом деле позволяет использовать любые габариты окна и области просмотра, изотропные и анизотропные. Все режимы отображения, упоминавшиеся до настоящего момента, в той или иной степени ограничивали настройку габаритов окна и области просмотра. В режимах MMJTEXT, MM_L0ENGLISH, MMJUENGLISH, MMJ.0METRIC, MMHIMETRIC и MMTWIPS используются фиксированные габариты окна и области просмотра, которые не могут изменяться приложением. Режим MMIS0TR0PIC позволяет менять габари-
Страничная система координат и режимы отображения 353 ты, но GDI автоматически следит за тем, чтобы масштабы по обеим осям совпадали или были достаточно близки. MM_ANISOTROPIC — единственный режим отображения, в котором приложение может произвольно менять габариты окна и области просмотра. При вызове SetMapMode(hDC,MM_ANISOTROPIC) в контексте устройства устанавливается анизотропный режим отображения без изменения других атрибутов. После этого приложение завершает настройку режима отображения, в произвольном порядке вызывая функции SetWindowExtEx и SetViewportExtEx. Режим MM_ANISOTROPIC позволяет имитировать все остальные режимы отображения, а также создавать ваши собственные режимы. Приложения Windows часто позволяют выбирать масштаб просмотра документа — 500 %, 200 % и т. д. до 25 % и 10 %. При масштабе 100 % один пиксел документа соответствует одному пикселу экрана, а один дюйм документа — одному дюйму экрана; при масштабе 500 % выполняется увеличение в пропорции 5:1, а при масштабе 25 % происходит уменьшение 1:4. Например, в графическом редакторе, где логической единицей является пиксел, изотропный режим отображения в масштабе т:п устанавливается следующим фрагментом: SetMapMode(hDC. MM_ANISOTROPIC); SetExtentsChDC. n. п. m. m); Ниже приведена функция SetExtents, которая исключает общие множители из параметров и устанавливает габариты: int gcdCint x, int у) // Наибольшее общее кратное { while (х!=у) if ( х > у ) х -= у; else у-= х: return x; } B00L SetExtents (HDC hDC. int wx. int wy, int vx. int vy) { int gx = gcd(abs(wx), abs(vx)); int gy = gcd(abs(wy). abs(vy)); SetWindowExtEx (hDC. wx/gx, wy/gy. NULL): return SetViewportExtEx (hDC. vx/gx. vy/gy. NULL): } Если в программе компьютерной верстки в качестве логической единицы выбран твип (1/20 пункта, или 1/1440 дюйма), масштаб т:п устанавливается следующим фрагментом: SetMapMode(hDC. MM_ANISOTROPIC): SetExtents(hDC. n * 1440. n * 1440. m * GetDeviceCaps(hDC. L0GPIXELSX). m * GetDeviceCaps(hDC. L0GPIXELSY)): В этом фрагменте используется логическое разрешение, возвращаемое драйвером устройства. Если вы предпочитаете вычислять разрешение по физическим размерам устройства, это делается так: SetMapMode(hDC. MM_ANIS0TR0PIC): SetExtents(hDC. n * 1440. n * 1440.
354 Глава 6. Системы координат и преобразования m * GetDeviceCapsChDC. HORZRES) * 254 / GetDeviceCapsChDC. HORZSIZE) / 10. m * GetDeviceCapsChDC. VERTRES) * 254 / GetDeviceCapsChDC, VERTSIZE) / 10); В этом фрагменте габариты задаются положительными числами, поэтому направление осей в страничной системе координат совпадает с направлением в системе координат устройства. Чтобы изменить направление осей, достаточно изменить знак габаритов области просмотра. Помимо фиксированных масштабов, в приложениях Windows часто поддерживается оперативное вычисление масштаба, позволяющего разместить определенную часть документа на всех поверхностях устройства. По размерам поверхности устройства могут масштабироваться ширина страницы, вся страница полностью или две соседние страницы. Обобщенная функция для решения подобных задач приведена в листинге 6.1. Листинг 6.1. Размещение в окне col x row страниц BOOL FitPagesCHDC hDC. int pagewidth. int pageheight. int dcwidth, int dcheight. int col, int row, int margin, int gap) { // Вычислить итоговые размеры col x row страниц int width = margin*2 + pagewidth *col + gap*(col-l); int height = margin*2 + pageheight*row + gap*(row-l); if (width <= 0) width = 1; // Избегаем нулевых значений if (height <= 0) height = 1; // Избегаем нулевых значений if ( dcheight * width > dcwidth * dcheight ) { dcheight = dcwidth; height = width; } else { dcwidth = dcheight; width = height; } return SetExtents (hDC, width, height, dcwidth. dcheight); } Эта функция решает общую задачу размещения col x row страниц, каждая из которых имеет размеры pagewidth x pageheight, в координатном пространстве размерами dcwidth x dcheight. На всех четырех краях документа присутствуют поля размером margin, а страницы разделяются интервалами gap. Программа сначала вычисляет итоговые размеры блока из col x row страниц с учетом всех факторов. Затем сравниваются отношения габаритов «область просмотра/окно» по двум осям, и меньшее отношение используется для регулировки габаритов области просмотра. Чтобы вы лучше поняли, как работает эта функция, мы рассмотрим пару примеров. Предположим, размеры каждой страницы документа равны 850 х 1100 еди-
Страничная система координат и режимы отображения 355 ниц, поверхность устройства состоит из 1024 х 768 пикселов, а размеры полей и межстраничных интервалов равны 0. Масштабирование по ширине страницы можно рассматривать как задачу размещения 1x0 страниц, то есть FitPagesChDC,850,1100,1024,768,1.0.0,0). Блок 1x0 страниц имеет размеры 850 х 1 единиц (с округлением, предотвращающим деление на 0), поэтому отношение по оси у (768:1) больше отношения по оси х (1024:850). Программа выбирает высоту области просмотра, равную 1024, и высоту окна, равную 850. Окончательные габариты окна равны (850,850), а габариты области просмотра — (1024,1024). Ширина страницы соответствует ширине пространства координат устройства. Перейдем к размещению двух страниц на поверхности устройства. Блок 2x1 имеет размеры 1700 х 1100, поэтому отношение габаритов области просмотра и окна по оси у (768:1700) оказывается меньше отношения по оси х (1024:1100). Программа выбирает ширину области просмотра, равную 768, и высоту окна, равную 1100. Теперь мы отображаем (1100,1100) единиц на (768,768) пикселов, что упрощается функцией SetExtents до (275,275) на (192,192). Настройка габаритов окна и области просмотра определяет, сколько единиц в страничной системе координат соответствует тому или иному количеству единиц в системе координат устройства. В Windows GDI окно и область просмотра описывают отображение страничной системы координат на систему координат устройства, а отсечение выполняется независимо в координатах устройства. Здесь важны лишь отношения габаритов, а не их конкретные значения. Например, в режиме MMJTEXT и окну, и области просмотра назначаются габариты (1,1) и базовые точки (0,0), но это вовсе не означает, что в системе координат отображается всего один пиксел. Базовые точки окна и области просмотра После настройки габаритов окна и области просмотра приложение задает положение базовых точек окна и области просмотра. После завершения настройки GDI отображает базовую точку окна в страничной системе координат на базовую точку области просмотра в системе координат устройства; остальные точки отображаются в соответствии с заданными параметрами. По умолчанию базовые точки окна и области просмотра имеют координаты (0,0); выбор режимов отображения и настройка габаритов не приводит к их изменению. Чтобы понять, нужно ли изменять координаты базовых точек окна и области просмотра, программист должен знать направления осей х и г/, использованные при настройке окна и области просмотра. В режимах MMJTEXT и в режиме MM_ANISOTROPIC (по умолчанию) ось х направлена слева направо, а ось у — сверху вниз. Следовательно, в страничной системе координат на координатное пространство устройства отображается только первый квадрант, определяемый положительными значениями по осям х и г/, а остальные квадранты не видны. Если вы хотите, чтобы базовая точка страничной системы координат отображалась в центр системы координат устройства, воспользуйтесь следующим фрагментом: SetWindow0rgEx(hDC. 0. 0. NULL); SetViewportOrgExChDC. dcHeight/2, dcWidth/2. NULL);
356 Глава 6. Системы координат и преобразования Изменения продемонстрированы на рис. 6.4. Ту- X- Х+ У+ т Рис. 6.4. Изменение базовой точки в режиме отображения ММ_ТЕХТ Следует помнить, что такое отображение может быть реализовано и иначе. Базовой точке области просмотра можно присвоить координаты (0,0), а базовой точке окна — координаты (-dcHeight*WExtx/VExtx/2,-dcWidth*WExty/VExty/2). С точки зрения математики эти два способы эквивалентны, но второй способ приводит к несколько большим погрешностям округления. В остальных режимах отображения направление оси у по умолчанию отличается от ее направления в режиме ММТЕХТ. В них используется традиционное для декартовой системы координат направление — снизу вверх. При этом в пространство координат устройства отображается только второй квадрант, с положительными значениями х и отрицательными значениями у. Для отображения базовой точки окна в центр пространства координат устройства по-прежнему можно воспользоваться приведенным выше фрагментом. Но если вы просто хотите отображать в пространство координат устройства первый квадрант, это делается так: SetWindowOrgEx(hDC. 0. 0. NULL); SetViewportOrgExChDC. dcHeight, 0, NULL); Аналогичная ориентация оси у используется и в языке PostScript. Отличия показаны на рис. 6.5. Рис. 6.5. Изменение базовой точки в других режимах отображения В режимах MMIS0TR0PIC и MM_AN ISOTROPIC приложение произвольно определяет направления осей. Впрочем, действовать нужно внимательно, поскольку GDI
Мировая система координат 357 учитывает настройки при реализации графических примитивов за одним исключением: GDI всегда выводит текстовые строки в одном направлении, если только контекст устройства не находится в расширенном графическом режиме. Даже если ось х направлена справа налево, текстовые строки все равно выводятся слева направо, без зеркального отражения глифов. Это может причинить немало хлопот, если приложение использует режимы отображения для зеркального отражения документов относительно оси у. Проблема решается либо имитацией отражения текста в совместимом контексте, либо мировыми преобразованиями в мировой системе координат. Другие функции окна и области просмотра В Win32 API предусмотрено несколько вспомогательных функций, упрощающих управление текущими настройками окна и области просмотра. Функция GetMapMode возвращает информацию о текущем режиме отображения. Функции OffsetWin- dowOrgEx и OffsetViewportOrgEx изменяют положение базовой точки окна или области просмотра. Они особенно удобны для пошагового смещения окна и области просмотра (например, при обработке сообщений прокрутки). Функции Scale- WindowExtEx и ScaleViewportExtEx масштабируют габариты окна и области просмотра с дробным коэффициентом, что может пригодиться при обработке запросов на масштабирование. Мировая система координат С точки зрения профессионального графического программирования отображение «окно/область просмотра» и различные режимы отображения являются компромиссом, глубоко укоренившимся в исходной архитектуре Win 16 GDI API, когда процессоры работали на тактовой частоте 8 Мгц, а память стоила дорого. Вследствие этого в архитектуре и реализации GDI приходилось искать как можно более простые и эффективные решения. Ниже перечислены некоторые недостатки архитектуры страничного координатного пространства. О Дробные коэффициенты при отображении окна на область просмотра. И окно, и область просмотра описываются целыми числами, поэтому при отображении окна на область просмотра используются дробные коэффициенты. Значения дробей легко вычисляются посредством целочисленного умножения, сопровождаемого делением. Однако итоговые целые числа выбираются из ограниченного набора, что может привести к потере точности. Например, как было показано выше, в режиме MMIS0TR0PIC может возникать расхождение масштабных коэффициентов по осям. О Неполная реализация. Вывод текста не соответствует семантике отражения относительно оси у. Другими словами, если приложение направляет ось х справа налево, текстовые строки все равно выводятся слева направо. О Ограниченный набор преобразований. Отображение окна на область просмотра позволяет выполнять преобразования смещения, масштабирования и зер-
358 Глава 6. Системы координат и преобразования кального отражения. Вращение и перекос не поддерживаются, а без прямой поддержки со стороны GDI реализовать их очень трудно. В Windows NT/2000 для решения этих проблем была создана новая логическая система координат — мировые координаты. В мировом координатном пространстве координаты по-прежнему задаются в виде 32-разрядных целых чисел, в отличие от других графических систем (например, PostScript), использующих вещественные числа. При отображении точек в мировой системе координат на страничное координатное пространство появляется возможность использования более общих преобразований. Аффинные преобразования Возможны разные виды преобразований из одной системы координат в другую. Скажем, преобразование перспективы отображает трехмерные объекты на двумерную поверхность, а преобразование «рыбьего глаза» имитирует искажение объектов, рассматриваемых через особую линзу. Преобразования, поддерживаемые в Windows NT/2000, относятся к классу двумерных аффинных преобразований. Аффинное преобразование отображает параллельные линии в параллельные линии, а конечные точки — в конечные точки. Двумерное аффинное преобразование определяется шестью числами, образующими матрицу 2 х 3. В Win32 API такие матрицы определяются структурой XF0RM. typedef struct _XF0RM { FLOAT eMll; FLOAT eM12: FLOAT eM21; FLOAT eM22; FLOAT eDx; FLOAT eDy; } XFORM; Аффинное преобразование, определяемое этими числами, преобразует точку (х,у) в (х\у% где х' - еМИ * х + еМ21 * у + eDx; у' - еМ12 * х + еМ22 * у + eDy; На первый взгляд похоже на формулы отображения окна на область просмотра, но в действительности аффинное преобразование обладает более широкими возможностями. Отображение окна на область просмотра, используемое в страничной системе координат, можно рассматривать как особый класс аффинных преобразований, в котором еМ21 и еМ12 равны нулю. Аффинные преобразования позволяют выполнять следующие операции. О Тождественное отображение. Определяется матрицей {1,0,0,1,0,0}; х = г, у' = у. О Смещение. Определяется матрицей {l,0,0,l,<ir,dz/}, х' = х + dx\ z/' = у + dy. О Масштабирование. Определяется матрицей {/тглт,0,0,/72г/,0,0}, х' = тх*х\ у' = = ту*у. О Зеркальное отражение. Определяется матрицей {-1,0,0,-1,0,0}, х' = -х\ у' - - -#•
Мировая система координат 359 О Поворот. Определяется матрицей {cos(6), sin(0), -sin(0), cos(0), 0, 0}. х' = = cos(0) xx - sin(0) x?/;z/'= sin(0) xi+ cos(0) xу. Точка (х,у) поворачивается на угол и относительно базовой точки в направлении против часовой стрелки. О Сдвиг. Определяется матрицей {1,5,0,1,0,0}. х' = .г + s x z/, у' = у. Координаты х смещаются на величину, пропорциональную у. О Комбинированные операции. Матрицы нескольких аффинных преобразований объединяются операцией матричного умножения и образуют новое аффинное преобразование. Шесть основных преобразований иллюстрирует рис. 6.6. Тождество TL OL Смещение Масштабирование Отражение Поворот Сдвиг Рис. 6.6. Простые двумерные аффинные преобразования Тождественное преобразование, смещение, масштабирование и отражение уже были продемонстрированы при отображении страничных координат в координаты устройства, хотя на этот раз мы свободно используем вещественные числа. Поворот — новая и очень полезная операция. Поворот системы координат вокруг базовой точки осуществляется по следующим формулам: х' = cos(theta) * х - sin(theta) * у у" = sin(theta) * х + cos(theta) * у Общая задача поворота вокруг произвольной точки (х0,у0) решается в три этапа. Сначала выполняется смещение (-х0,-у0), затем поворот и, наконец, обратное смещение (хО,уО). Итоговое преобразование выглядит следующим образом: х' - cos(theta) * (х-хО) - sin(theta) * (у-уО) + хО у* = sin(theta) * (х-хО) + cos(theta) * (у-уО) + уО При сдвиге (поперечной деформации) к одной координате прибавляется величина, пропорциональная значению другой координаты. Сдвиг также может осуществляться по обеим координатам, поэтому общие формулы сдвига выглядят так: х* = х + h * у у' - g * х + у Аффинные преобразования обладают рядом интересных свойств, из-за которых они получили широкое распространение в компьютерной графике. Понима-
360 Глава 6. Системы координат и преобразования ние этих свойств поможет вам лучше понять, как определяемая приложением геометрическая модель трансформируется при использовании этих преобразований. Кроме того, это дает некоторое представление о внутренней реализации преобразований графическим механизмом. О Аффинные преобразования сохраняют прямые линии. Прямая линия отображается в прямую линию, треугольник отображается в треугольник, а многоугольник отображается в многоугольник. Чтобы реализовать аффинные преобразования для линий и многоугольников, графическому механизму достаточно вычислить отображения их вершин, а затем провести линии или соединительные отрезки. О Аффинные преобразования сохраняют параллельность (параллельные линии отображаются в параллельные линии). Таким образом, параллелограмм отображается в параллелограмм, хотя прямоугольники не всегда отображаются в прямоугольники, а квадраты не обязательно отображаются в квадраты. О Аффинные преобразования сохраняют эллипсы. Эллипс в результате аффинного преобразования всегда отображается в эллипс, хотя круг не всегда отображается в круг. Средствами GDI API определяются только ортогональные круги и эллипсы, оси которых параллельны осям х и г/, но при помощи аффинных преобразований можно нарисовать на поверхности устройства произвольный эллипс. О Аффинные преобразования сохраняют кривые Безье. Как и в случае с линиями и многоугольниками, GDI остается лишь применить аффинные преобразования к вершинам, определяющим кривую Безье, а затем объединить их в преобразованную кривую Безье в координатах устройства. О Аффинное преобразование однозначно определяется тремя вершинами не- коллинеарных векторов р, q, г в исходной системе координат и тремя вершинами неколлинеарных векторов р\ q\ r' в результирующей системе координат. Другими словами, существует только одно аффинное преобразование, которое отображает р, q, r соответственно в р\ q\ r\ Обратите внимание: все отображения из страничной системы координат в систему координат устройства, поддерживаемые GDI, однозначно определяются двумя точками в каждой из систем координат. Перечисленные свойства аффинных преобразований отражены в реализации графических примитивов GDI, примененной в Windows NT/2000. Как было сказано выше, круг или эллипс в результате аффинного преобразования отображается в круг или эллипс, который может и не быть ортогонален осям. В компьютерной графике эффективно вывести произвольный эллипс очень трудно. Как графический механизм подходит к решению это задачи? Каждый эллипс разбивается на четыре кривые Безье, которые легко отображаются и воспроизводятся в системе координат устройства как кривые Безье. Поскольку аффинные преобразования определяются вещественными числами вместо дробей, используемых при отображении окна в область просмотра, во внутренних операциях графического механизма Windows NT/2000 применяются числа с фиксированной точкой, что делает вычисления более точными. С математической точки зрения аффинное преобразование представляет собой функцию t: R х R->R x R в форме t(x) = Ах + ft, где А — инвертируемая
Мировая система координат 361 матрица 2 х 2, а Ь — точка в R x R. Совокупность всех аффинных преобразований R х R обозначается Л(2). Можно доказать, что множество аффинных преобразований А(2) образует группу по отношению к множеству композиционных операций. Термин «группа» в данном случае является понятием абстрактной алгебры и определяется как произвольный набор операций над некоторым полем, обладающий свойствами замкнутости, существования тождественной (единичной) и обратной операции и ассоциативности. Для аффинных преобразований эти свойства определяются следующим образом. О Замкнутость. Композиция любых двух аффинных преобразований также является аффинным преобразованием. Если tl(x) = А\ х х + Ы и t2(x) = = Л2 х х + Ь2, то (tl х t2)(x) = (А1 х А2) х х + (Л1 х Ъ2 + М). О Наличие тождественного преобразования. Существует тождественное (единичное) аффинное преобразование i(x), при котором для любого аффинного преобразования t(x) справедливы утверждения (i x t)(x) = t(x) и (t x г)(лг) = = t(x). В действительности i(x) = I х х + О, где / — тождественная матрица 2x2. О Наличие обратного преобразования. Преобразование, обратное к аффинному, также является аффинным. Обратным к t(x) = А х х + Ъ является преобразование (1/Л) хх- (1/Л) х Ь. О Ассоциативность. Композиция аффинных преобразований ассоциативна; иначе говоря, для любых аффинных преобразований t1, t2 и t3 выполняется условие (t1 х t2) xt3 = t1 x (t2 x t3). На первый взгляд эти математические концепции кажутся абстракцией, но они приносят чрезвычайно большую пользу в компьютерной графике. Нередко приложению приходится определять несколько преобразований, объединяемых в одно итоговое преобразование. В частности, эта возможность используется во внутренних операциях графического механизма для объединения двух преобразований (из мировых координат в страничные, а из страничных — в координаты устройства). Помните, что отображение страничного координатного пространства в пространство координат устройства также является частным случаем аффинных преобразований. Обратные преобразования упрощают обратное отображение из страничных координат или координат устройства в мировые. В частности, это свойство используется для отображения координат событий мыши в мировое координатное пространство. Графический механизм задействует тот же программный код, но только для обратного преобразования. Функции мировых преобразований в Win32 API Довольно отвлеченных рассуждений об аффинных преобразованиях. Мы переходим к рассмотрению поддержки мировой системы координат и мировых преобразований в Win32 API. По умолчанию контекст устройства работает в так называемом совместимом графическом режиме (имеется в виду совместимость с 16-разрядной семантикой GDI). В совместимом режиме мировые координаты не поддерживаются, а единственной логической системой координат является страничная система. Если приложение захочет разрешить использование мировых координат, оно должно
362 Глава 6. Системы координат и преобразования переключить контекст устройства в графический режим вызовом функции Set- GraphicsMode(hDC, GM_ADVANCED), реализованной только в Windows NT/2000. В результате вызова обеспечивается поддержка контекстом устройства двух уровней логического координатного пространства — мировых и страничных координат, а также матрицы преобразования. Информацию о текущем графическом режиме возвращает функция GetGraphicsMode(hDC). Чтобы вернуться к совместимому режиму, заполните матрицу данными тождественного преобразования и вызовите SetGraphicsModeChDC, GMCOMPATIBLE). Кроме того, можно воспользоваться функциями SaveDC и RestoreDC. Переключение контекста устройства в режим GMADVANCED не ограничивается включением поддержки мировых координат. Оно также оказывает значительное влияние на реализацию графических примитивов, используемую в GDI. Различия между двумя режимами перечислены в табл. 6.2. Таблица 6.2. Различия между графическими режимами GDI Область GM COMPATIBLE GM ADVANCED Логические системы координат Платформа Направление вывода текста Масштабирование текста Прямоугольники Направление дуг Отображение дуг Страничные координаты Windows 95/98, Windows NT/2000 Текст всегда выводится слева направо сверху вниз, даже если направление осей было изменено путем смены режима отображения. Изменить направление текста можно только изменением угла наклона и ориентации логического шрифта или же совместимого контекста устройства Масштабируются только шрифты TrueType. Правая и нижняя граница исключаются из прямоугольника Дуги выводятся в направлении, заданном функцией SetArcDirection При выводе дуг отображения не учитываются Мировые и страничные координаты Windows NT/2000 Текстовые строки выводятся в соответствии с действующими преобразованиями и отображениями Масштабируются шрифты TrueType и векторные шрифты. GDI пытается обеспечить оптимальное качество вывода растровых шрифтов, но результат не гарантирован Правая и нижняя граница входят в прямоугольник В логических координатах дуги всегда выводятся против часовой стрелки Дуги выводятся в соответствии с преобразованиями и отображениями
Мировая система координат 363 В контексте устройства преобразование из мировых координат в страничные по умолчанию инициализируется тождественной матрицей. Для изменения текущего преобразования используются следующие функции: BOOL SetWorldTransformCHDC hDC. CONST XFORM * lpXform); BOOL ModifyWorldTransformCHDC hDC. CONST XFORM * IpXformm DWORD iMode); Функция SetWorldTransform просто заменяет атрибут преобразования в контексте устройства новым преобразованием, заданным структурой XFORM. Обратите внимание: не каждая шестерка чисел типа FLOAT определяет правильное аффинное преобразование. Формальное определение аффинных преобразований требует, чтобы матрица 2x2, образованная числами еМН, еМ12, еМ21 и еМ22, была обратимой; то есть должно выполняться условие еМП х еМ22 != еМ12 х еМ21. Например, следующая попытка завершится неудачей: XFORM xm = {1, 2. 1, 2, 3. 4}; SetGraphicsMode(hDC, GM_ADVANCED); BOOL result - SetWorldTransform(hDC. & xm); DWORD error = GetLastErrorO; Матрица xm определяет преобразование x' = x + z/ + 3hz/' = 2x + 2z/ + 4, поэтому у' - 2x' + 1. Получается, что все точки мировой системы координат отображаются в одну линию у = 2х + 1 страничной системы координат. Такое преобразование не является обратимым и не обеспечивает соответствия 1:1, поэтому оно относится к числу недопустимых. В данном примере SetWorldTransform, как и следовало ожидать, вернет FALSE, но как ни странно, GetLastError возвращает О (ERROR_SUCCESS) даже в Windows NT/2000. Впрочем, GDI вообще плохо справляется с объяснением причин ошибок. Вызов SetWorldTransform также завершается неудачей, когда контекст устройства находится в графическом режиме GM_SETCOMPATIBLE или программа работает в Windows 95/98. При вызове ModifyWorldTransform параметр iMode принимает одно из трех значений. Когда параметр iMode равен MTW_IDENTITY, преобразование преобразуется к тождественной форме. Если параметр iMode равен MTW_LEFTMULTIPLY, текущее преобразование умножается на *lpXform слева. Наконец, если параметр iMode равен MTW_RIGHTMULTIPLY, текущее преобразование умножается на *lpXform справа. В данном случае под умножением понимается последовательное выполнение двух преобразований, образующее новое преобразование. GDI различает левостороннее и правостороннее умножение, поскольку умножение преобразований не всегда коммутативно. В отличие от целочисленной математики, в области преобразований а х Ь не всегда равно b x а. Для получения информации о текущем преобразовании используется функция GetWorldTransform. Собственно, этим исчерпывается вся поддержка удивительного мира преобразований в Win32 API. В остальном вы можете полагаться на свой старый испытанный учебник по аналитической геометрии, книгу по теории компьютерной графики — или просто читать дальше. Использование мировых преобразований Мировые координаты й мировые преобразования благодаря двумерным аффинным преобразованиям приносят огромную пользу в компьютерной графике.
364 Глава 6. Системы координат и преобразования К сожалению, их поддержка в Win32 API очень ограничена. Для решения даже простых практических задач приходится изрядно поломать голову. Например, как повернуть объект относительно произвольной точки (х,у) или рассчитать преобразования, отображающие прямоугольное изображение на грани трехмерного куба? В этом разделе мы создадим класс C++ KAffine, содержащий немало полезных методов. Объявление класса KAffine приведено в листинге 6.2. Листинг 6.2. Объявление класса аффинных преобразований KAffine class KAffine { public: XFORM m_xm; KAffineО { ResetO: } void ResetO; BOOL SetTransform(const XFORM & xm); BOOL Combine(const XFORM & b); BOOL Invert(void); BOOL TranslateCFLOAT dx. FLOAT dy); BOOL Scale(FLOAT sx, FLOAT dy); BOOL Rotate(FLOAT angle. FLOAT x0=0, FLOAT y0=0); BOOL MapTri(FLOAT pxO. FLOAT pyO. FLOAT qxO. FLOAT qyO. FLOAT rxQ. FLOAT ryO); BOOL MapTri(FLOAT pxO. FLOAT pyO. FLOAT qxO. FLOAT qyO. FLOAT rxO. FLOAT ryO, FLOAT pxl, FLOAT pyl. FLOAT qxl, FLOAT qyl, FLOAT rxl. FLOAT ryl): }: Класс предназначен для работы с аффинным преобразованием, представленным структурой Win32 XFORM, которая хранится в единственной переменной класса m_xm. Первые три метода повторяют функциональность Win32 API: Reset сбрасывает матрицу в тождественное состояние, SetTransform копирует данные из структуры XFORM, a Combine объединяет последовательные преобразования. Метод KAffine:: Invert заменяет текущее преобразование обратным. Три метода, следующих после него, на самом деле являются операторами PostScript. Метод Translate дополняет текущее преобразование операцией смещения, метод Scale изменяет масштаб по двум осям, а метод Rotate добавляет к текущему преобразованию поворот вокруг произвольной точки (хО,уО). Можно считать, что каждый из этих трех методов выполняет простое преобразование (смещение, масштабирование или поворот) и объединяет его с текущим преобразованием. Два метода MapTri предназначены для решения общей задачи — поиска аффинного преобразования, которое отображает три вершины "неколлинеарных векторов рО, qO, rO в другой неколлинеарный триплет р1, q1 и г1. Делается это в два
Мировая система координат 365 этапа. Сначала необходимо найти два преобразования, отображающих точки (0,0), (1,0) и (0,1) в два триплета. Эта задача гораздо проще исходной, и она решается первым методом MapTri. Затем первое преобразование обращается и объединяется со вторым; результат представляет собой итоговое преобразование. Происходящее можно представить себе как отображение рО, qOnrOB (0,0), (1,0) и (0,1) с последующим отображением в р1} q1} r1. Реализация класса KAffine с проверкой ошибок приведена в листинге 6.3. Листинг 6.3. Реализация класса аффинных преобразований KAffine #define STRICT #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <math.h> #include "Affine.h" // Переход к тождественному преобразованию void KAffine: .-ResetО { m_xm.eMll = 1; m_xm.eM12 = 0; m_xm.eM21 = 0; m_xm.eM22 = 1; m_xm.eDx = 0; m_xm.eDy = 0; } // Если преобразование соответствует критерию проверки. // скопировать его B00L KAffine::SetTransform(const XF0RM & xm) { if ( xm.eMll * xm.eM22 «- xm.eM12 * xm.eM21 ) return FALSE; m_xm = xm: return TRUE: } // преобразование = преобразование * b BOOL KAffine::Combine(const XF0RM & b) { if ( b.eMll * b.eM22 — b.eM12 * b.eM21 ) return FALSE: XF0RM a - m_xm: // 11 12 11 12 // 21 22 21 22 m_xm.eMll - a.eMll * b.eMll + a.eM12 * b.eM21; m xm.eM12 = a.eMll * b.eM12 + a.eM12 * b.eM22:
366 Глава 6. Системы координат и преобразования Листинг 6.3. Продолжение m xm.eM21 - а.еМ21 * b.eMll + a.eM22 * Ь.еМ21: nfxm.eM22 - а.еМ21 * Ь.еМ12 + а.еМ22 * Ь.еМ22: mjcm.eDx - a.eDx * b.eMll + a.eDy * b.eM21 + b.eDx; nfxm.eDy - a.eDx * b.eM12 + a.eDy * b.eM22 + b.eDy; return TRUE; // преобразование - 1 / преобразование // M = A * x + В // Inv(M) - Inv(A) * x - Inv(A) * В BOOL KAffine::Invert(void) { FLOAT det = m_xm.eMll * m_xm.eM22 - m_xm.eM21 * m_xm.eM12; if ( det==0 ) return FALSE; XFORM old - m_xm; m_xm.eMll = old.eM22 / det m_xm.eM12 = - old.eM12 / det m_xm.eM21 = - old.eM21 / det m_xm.eM22 - old.eMll / det m_xm.eDx = - ( m_xm.eMll * old.eDx + m_xm.eM21 * old.eDy ): m_xm.eDy = - ( m_xm.eM12 * old.eDx + m_xm.eM22 * old.eDy ): return TRUE; BOOL KAffine::Translate(FLOAT dx. FLOAT dy) { m_xm.eDx +- dx; m__xm.eDy += dy: return TRUE; BOOL KAffine::Seale(FLOAT sx. FLOAT sy) { if ( (sx«-0) || (sy—0) ) return FALSE: m_xm.eMll *= sx; m_xm.eM12 *= sx; m_xm.eM21 *= sy; m_xm.eM22 *= sy; m_xm.eDx *= sx; m__xm.eDy *= sy; return TRUE;
Мировая система координат 367 BOOL KAffine -Rotate(FLOAT angle. FLOAT xO. FLOAT yO) { XFORM xm; Translate(-xO. -yO): // Перенести начало координат в (хО.уО) double rad - angle * (3.14159265359 / 180); xm.eMll - (FLOAT) cos(rad); xm.eM12 - (FLOAT) sin(rad); xm.eM21 - - xm.eM12; xm.eM22 - xm.eMll; xm.eDx =0; xm.eDy - 0; Combine(xm); // Повернуть Translate(x0. yO): // Вернуть начало координат на место return TRUE; } // Найти преобразование, которое отображает (0.0) (1.0) (0.1) // соответственно в p. q, г BOOL KAffine::MapTri(FLOAT pxO. FLOAT pyO. FLOAT qxO. FLOAT qyO. FLOAT rxO. FLOAT ryO) { // pxO - dx. qxO - mil + dx. rxO - m21 + dx // pyO = dy. qyO - ml2 + dy. ryO = m22 + dy m_xm.eMll - qxO - pxO; m_xm.eM12 e qyO - pyO; m_xm.eM21 - rxO - pxO; m_xm.eM22 - ryO - pyO; m_xm.eDx - pxO: m_xm.eDy = pyO; return m_xm.eMll * m_xm.eM22 != m_xm.eM12 * m_xm.eM21; } // Найти преобразование, которое отображает рО. qO. rO II соответственно в pi. ql. rl BOOL KAffine;:MapTri(FLOAT pxO. FLOAT pyO. FLOAT qxO. FLOAT qyO. FLOAT rxO. FLOAT ryO. FLOAT pxl. FLOAT pyl. FLOAT qxl. FLOAT qyl. FLOAT rxl. FLOAT ryl) { if ( ! MapTri(pxO. pyO. qxO. qyO. rxO. ryO) ) return FALSE; InvertO: // Преобразование рО. qO. гО в (0.0).(1.0).(0.1) KAffine mapl; if (! mapl.MapTri(pxl. pyl. qxl. qyl. rxl. ryl) ) return FALSE; return Combine(mapl.m_xm); // Затем в to pl.rl.ql }
368 Глава 6. Системы координат и преобразования Аффинные преобразования широко используются и в других графических системах (например, в PostScript). Базовый класс KAffine существенно упрощает преобразование эффектных примеров PostScript на язык GDI. Простой пример иллюстрирует рис. 6.7 — при выводе пунктирных линий с постоянной модификацией преобразования на экране возникает интересный рисунок. void Transform_DottedLine(HDC hDC. int width, int height) { KAffine af; // Декартова система координат с началом в центре SetMapMode(hDC. MM_ANISOTROPIC): SetViewportExtExChDC. 1. -1. NULL); SetViewportOrgExChDC. width/2, height/2. NULL); SetGraphicsMode(hDC. GM_ADVANCED); for (int i=0; i<=72*5; i++) { // Пунктирная линия (50.0) -> (248.0) for (int x=0; x<=200: x+=3) SetPixeKhDC. x+50. 0. 0): af.Translated, 5); af.ScaleC(FLOAT) 0.98. (FLOAT) 0.98); af.Rotate(5); SetWorldTransform(hDC. & af.m xm); // Смещение // Уменьшение // Поворот на 5 градусов '<^ШК^^ zm \ У, Щ W Рис. 6.7. Пунктирная линия в мировых преобразованиях Не правда ли, вызовы Translate, Scale и Rotate напоминают запись PostScript «5 pixel 5 pixel translate 0.98 0.98 scale 5 rotate»?
Мировая система координат 369 Рассмотрим более интересный пример — вывод трех прямоугольников, состоящих из пикселов разного цвета, и их отображение на три грани куба с использованием параллельной проекции (рис. 6.8). Решение приведено ниже. Рис. 6.8. Построение цветного куба путем преобразований void FaceCHDC hDC. COLORREF color) { for (int x=0; x<size; x++) for (int y=0; y<size; y++) SetPixeKhDC. x. y. color); void Draw_Cube(HDC hDC. int width, int height, int degree) { KAffine af; SetMapMode(hDC. MM_ANIS0TR0PIC); SetViewportExtExChDC. 1. -1. NULL); SetViewportOrgEx(hDC. width/2, height/2. NULL); SetGraphicsMode(hDC. GM_ADVANCED); const FLOAT dx = 100. dy = 30. h - 120; af.MapTri(0. 0. 100. 0. 0. 100. 0. 0. dx. dy. 0. h); SetWorldTransform(hDC. & af.m_xm); FaceChDC. RGB(0xFF. 0. 0)); af.MapTri(0. 0. 100. 0. 0. 100. 0. 0. -dx. dy. 0. h): SetWorldTransform(hDC. & af.m_xm); Face(hDC. RGB(0. OxFF. 0)); af.MapTri(0. 0. 100. 0. 0. 100. 0. h. dx. h + dy. -dx. h + dy); SetWorldTransformChDC. & af.m_xm); FaceChDC. RGB(0. 0. OxFF));
370 Глава 6. Системы координат и преобразования Функция Face выводит прямоугольный массив пикселов в мировой системе координат, не беспокоясь о том, где в итоге окажется выводимое изображение. Основная функция DrawCube при помощи метода KAffine: :MapTri отображает прямоугольную область, выведенную функцией Face, на три поверхности куба в страничной системе координат. В страничной системе координат, как и в декартовой системе, ось у направлена вверх. Благодаря мировым преобразованиям один и тот же фрагмент кода можно использовать для вывода в разных местах и с разными пропорциями — остается лишь рассчитать правильное преобразование. Кстати, при рисовании на гранях куба ваши возможности отнюдь не ограничиваются выводом пикселов. Здесь приведен лишь простейший вариант, но вы можете самостоятельно реализовать вывод линий, эллипсов, растров и даже текста. Использование систем координат Мы довольно подробно рассмотрели четыре системы координат, поддерживаемых графической системой Windows, — мировую, страничную, систему координат устройства и физическую. Мировое преобразование отображает мировое координатное пространство в физическое. Отображение окна в область просмотра выполняется из страничных координат в координаты устройства. Пространство координат устройства представляет собой обычный прямоугольный регион в физическом координатном пространстве, поэтому отображение между ними сводится к простому смещению. В терминологии Win32 мировая и страничная системы координат называются «логическими». Отображения между четырьмя системами координат независимы друг от друга, то есть при изменении одного отображения остальные не изменяются. Однако в совокупности они обеспечивают отображение геометрической модели приложения в участки поверхности физического устройства. При помощи функций GDI приложение определяет мировое преобразование и параметры отображения окна в область просмотра. Отображение из системы координат устройства и физической системы координат находится под управлением операционной системы. По умолчанию мировые преобразования не используются, поскольку контекст работает в режиме совместимости с Win 16 GDI. Чтобы включить поддержку мировых преобразований, приложение должно переключиться в расширенный графический режим GM_ADVANCED. По умолчанию для отображения мировых координат в страничные используется тождественное преобразование. Впрочем, отображение страничных координат в координаты устройства по умолчанию также является тождественным — выбирается режим ММТЕХТ с базовыми точками окна и области просмотра (0,0). Приложение получает информацию об отображениях между системами координат при помощи специальных функций. Функция GetWorldTransformation возвращает описание отображения из мировых координат в страничные. Функции GetWindowOrgEx, GetWindowExtEx, GetViewportOrgEx и GetViewportExtEx возвращают сведения об отображении из страничных координат в координаты устройства. Функ-
Использование систем координат 371 ция GetDCOrgEx возвращает описание смещения между координатами устройства и физическими координатами. Как правило, отображение из логической системы координат верхнего уровня в физические координаты выполняется графической системой. Однако приложение время от времени может получать данные из разных координатных систем, и тогда преобразования приходится выполнять вручную. В Win32 существует несколько функций для решения этой задачи: BOOL LPtoDPCHDC hDC. LPPOINT lpPoints. int nCount): BOOL DPtoLP(HDC hDC. LPPOINT lpPoints, int nCount); BOOL ClientToScreen(HWND hWnd, LPPOINT IpPoint); BOOL ScreenToCllent(HWND hWnd. LPPOINT IpPoint); Функция LPtoDP отображает массив структур POINT из мировых координат в координаты устройства; функция DPtoLP осуществляет обратное преобразование. Отображение определяется параметрами контекста устройства: графическим режимом, мировым преобразованием, режимом отображения и настройкой отображения окна в область просмотра. Функции работают не с отдельными точками, а с целым массивом структур POINT. Следовательно, при вызове им можно передать структуру RECT или даже массив структур RECT, поскольку раскладка структуры RECT в памяти в точности совпадает с раскладкой двух структур POINT (координаты левого верхнего и нижнего правого угла). Код приведенного ниже примера отображает два угла прямоугольника клиентской области в мировое пространство: RECT rect; GetClientRect(WindowFromDCChDC). & rect); DPtoLP(hDC, (POINT *) & rect. sizeof(RECT)/sizeof(POINT)); В некоторых ситуациях приложение берет на себя управление преобразованием логических координат в координаты устройства вместо того, чтобы использовать функции LPtoDP и DPtoLP. Причины могут быть разными — например, приложение хочет выполнить отображение без контекста устройства, считает затраты на использование функций GDI неприемлемыми или желает прибегнуть к аппаратной поддержке вещественных вычислений с ее повышенным быстродействием. Средства GDI не позволяют легко получить объединенное преобразование из мировых координат в координаты устройства. Ниже приведен новый метод класса KAffine для расчета объединенного преобразования. // Расчет объединенного преобразования из мировых координат // в координаты устройства BOOL KAffine::GetDPtoLP(HDC hDC) { if ( ! GetWorldTransform(hDC. & m_xm) ) return FALSE; POINT origin; GetWindowOrgEx(hDC. & origin); Translate( - (FLOAT) origin.x. - (FLOAT) origin.y); SIZE sizew. sizev; GetWindowExtEx (hDC. & sizew); GetViewportExtEx(hDC, & sizev);
372 Глава 6. Системы координат и преобразования Scale( (FLOAT) sizew.cx/sizev.cx, (FLOAT) sizew.cy/sizev.cy); GetViewportOrgEx(hDC. & origin); Translate( (FLOAT) origin.x, (FLOAT) origin.y); return TRUE; } Как видно из приведенного фрагмента, отображение из логического пространства координат в пространство устройства представляет собой мировое преобразование, за которым следует смещение к базовой точке окна, масштабирование в соответствии с изменениями габаритов и еще одно смещение к базовой точке области просмотра. Отображение из пространства координат устройства в пространство мировых координат представляет собой преобразование, обратное по отношению к предыдущему. Обычно контекст устройства соответствует клиентской области окна. В этом случае для преобразования из координат устройства (клиентской области) в физические (экранные) координаты можно воспользоваться функцией ClientToScreen, тогда как обратное преобразование выполняется функцией ScreenToClient. Впрочем, вы также можете самостоятельно выполнить сложение или вычитание, используя данные базовой точки контекста. Реализация преобразований в GDI Инженер всегда следит за тем, чтобы система делала то, что требуется, с приемлемым быстродействием. Хорошее понимание реализации помогает обрести уверенность, а в сомнительных случаях — разработать альтернативное решение. В этом разделе мы поговорим о том, что нам известно о реализации мировых преобразований и отображения «окно/область просмотра» в Windows NT/2000. Графический механизм Windows NT/2000 работает в адресном пространстве ядра. На старых процессорах операции с плавающей точкой считались ненадежными или слишком медленными, поэтому графический механизм имитирует вещественные вычисления. Каждое вещественное число преобразуется в структуру FL0AT0BJ, состоящую из 32-разрядной экспоненты и 32-разрядной знаковой мантиссы. Структура XF0RM представляется структурой MATRIX, состоящей из шести полей типа FL0AT0BJ для eMU, eM12, eM21, eM22, eDx и eDy, двух целочисленных полей для целых частей eDx и eDy, а также флага. В контексте устройства хранятся три структуры MATRIX. Первая структура определяет преобразование мировых координат в страничные; конечно, именно с этой структурой работают функции API SetWorldTransform и GetWorldTransform. Две другие структуры определяют отображение мировых координат в координаты устройства, и наоборот. Вы можете не сомневаться в том, что функции LPtoDP и DPtoLP проходят только через одну матрицу преобразования. В контексте устройства хранятся флаги следующего вида: WORLD_TO_PAGE_IDENTITY PAGE_TO_DEVICE_IDENTITY PAGE_TO_DEVICE_SCALE_IDENTITY XFORMJJNITY XFORM NO TRANSLATION
Пример программы: прокрутка и масштабирование 373 Имена этих флагов позволяют предположить, что в простых случаях преобразование полностью или частично пропускается. Для отображения окна в область просмотра базовая точка и габариты окна/ области просмотра хранятся в контексте устройства в исходной целочисленной форме. В расширенном графическом режиме они наверняка включаются в преобразования из мировых координат в координаты устройства, и наоборот. Матрицы мирового преобразования и отображения окна в область просмотра хранятся в пользовательском адресном пространстве, что ускоряет обращения к ним. Простые случаи отображения (в частности, LPtoDP и DPtoLP) обрабатываются в gdJ32.dll в пользовательском режиме, а в более сложных случаях генерируются вызовы системных функций, обрабатываемые графическим механизмом в режиме ядра. Также следует помнить о том, что графический механизм Windows NT/2000 для повышения точности использует для хранения координат устройства и физических координат числа с фиксированной точкой в формате 28.4. За дополнительной информацией о внутренней структуре данных контекста устройства обращайтесь к главе 3. Пример программы: прокрутка и масштабирование Все программы, которые мы создавали до настоящего момента, выводили данные во всей клиентской области окна, причем клиентской областью весь вывод и ограничивался. Такой подход не годится даже для простых задач типа редактирования текста, не говоря уже о компьютерной верстке или систем автоматизированного проектирования. Все эти программы обычно выводят данные на воображаемом «холсте», размеры которого значительно превышают размеры клиентской области окна. В любой момент времени в окне отображается лишь часть «холста». При помощи полос прокрутки пользователь выбирает относительную позицию текущего экрана в «холсте». Помимо прокрутки, в профессиональных приложениях предусматривается возможность масштабирования, чтобы пользователь мог оценить общий вид всего «холста» или рассмотреть мельчайшие подробности. В этом разделе мы создадим класс KScroll Canvas, производный от класса KCanvas из главы 5. Класс KScroll Canvas позволяет определять размер «холста» на уровне приложения, полосы прокрутки и масштабирование. В основе реализации класса лежит преобразование страничных координат в координаты устройства. Кроме того, мы рассмотрим простой пример программы, созданной на базе нового класса. Объявление класса KScroll Canvas приведено в листинге 6.4. Листинг 6.4. Объявление класса KScrollCanvas (поддержка прокрутки и масштабирования) class KScrollCanvas : public KCanvas { virtual LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam):
374 Глава 6. Системы координат и преобразования Листинг 6.4. Продолжение public: int m_width. mjieight: int mjinedx. mjinedy; i nt m_zoommul. m_zoomdi v; virtual void OnZoom(int x, int y. int mul. int div); virtual void OnTimer(WPARAM wParam. LPARAM IParam); virtual void OnMouseMove(WPARAM wParam. LPARAM IParam); virtual void OnCreate(void); virtual void OnDestroy(void); KScrollCanvas(void) { m_width - 0; m_height = 0; mjinedx - 0: mjinedy = 0; m_zoommul = 1; m_zoomdiv = 1; } void SetSize(int width, int height, int linedx. int linedy) { m_width = width; m_height - height; mjinedx = linedx; mjinedy - linedy; } void SetScrollBar(int side, int maxsize, int pagesize); void OnScrolKint nBar. int nScrollCode. int nPos); }: Класс KScrollCanvas объявлен производным от KCanvas. Он переопределяет функцию WndProc, чтобы обрабатывать дополнительные сообщения — об этом наглядно свидетельствует появление новых виртуальных функций, обрабатывающих сообщения создания окна, уничтожения окна, перемещения мыши, прокрутки и таймера. В новых переменных класса m_width и m_height хранятся размеры холста; переменные mjinedx и mjinedy управляют величиной прокрутки, а переменные m_zoomdiv и m_zoommul определяют дробный масштабный коэффициент. Реализация класса частично приведена в листинге 6.5. Метод OnZoom реализует простой, но эффективный способ масштабирования при помощи мыши. Если щелкнуть левой кнопкой мыши в некоторой точке окна, изображение увеличивается, а точка по возможности перемещается в центр экрана. Щелчок правой кнопкой уменьшает изображение. Функция масштабирования написана по возможности более обобщенной. При вызове ей передаются четыре параметра — новые координаты центра, а также числитель и знаменатель дроби, определяющей коэффициент масштабирования. Функция обновляет масштаб, прибавляет текущую позицию полос прокрутки к соответствующим координатам, масштабирует и вычисляет новую позицию. Затем происходит обновление размера холста и полос прокрутки. Программа вычисляет новую позицию полос прокрутки и перемещает точку щелчка в центр, если это возможно. В конце своей работы функция выдает запрос на полную перерисовку.
Пример программы: прокрутка и масштабирование 375 Листинг 6.5. Реализация KScrollCanvas: масштабирование и обработка сообщений void KScrollCanvas::0nZoom(int x. int y. int mul. int div) { m_zoommul *= mul; m__zoomdiv *= div; int factor - gcd(m_zoommul. m_zoomdiv); m_zoommul /= factor; m_zoomdiv /= factor: // Прибавить смещение полос прокрутки и вычислить новую позицию // после масштабирования х = ( х + GetScrolIPos(m_hWnd. SBJiORZ) ) * mul / div: у - ( у + GetScrol 1 Pos(mJiWnd, SBJ/ERT) ) * mul / div: // Обновить параметры холста m_width = m_width * mul /div: mjieight - mjieight * mul /div: RECT rect; GetClientRectCmJiWnd. & rect): // Изменить состояние полос прокрутки SetScrol1Bar(SB_HORZ, m_width, rect.right): SetScrol1 Bar(SBJ/ERT, mjieight, rect.bottom); // Постараться расположить х в центре окна х -= rect.right/2; if ( x<0 ) x - 0; if ( x > m_width - rect.right ) x = m_width - rect.right; SetSc roll Pos (mJiWnd. SBJORZ. x. FALSE); у -= rect.bottom/2; if ( y<0) у - 0; if ( у > mjieight - rect.bottom ) у = mjieight - rect.bottom; SetScrol 1 Pos(m_hWnd. SBJ/ERT. y. FALSE); // Перерисовать InvalidateRect(m_hWnd. NULL. TRUE); ::UpdateWindow(m_hWnd); } LRESULT KScrollCanvas::WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam) { switch( uMsg ) {
376 Глава 6. Системы координат и преобразования Листинг 6.5. Продолжение case WM_CREATE: m_hWnd = hWnd; OnCreateO: return 0; case WM_SIZE: SetScro11Bar(SB_H0RZ. m_width. LOWORD(lParam)); SetScrollBar(SB_VERT. m_height. HIWORD(lParam)); return 0; case WM_PAINT: { PAINTSTRUCT ps; HDC hDC = BeginPaint(m_hWnd, &ps); SetWindowOrgEx(hDC. 0. 0. NULL): SetViewportOrgEx(hDC- GetScrollPos(hWnd. SB_H0RZ). - GetScrollPos(hWnd, SBJERT). NULL); OnDraw(hDC. & ps.rcPaint); EndPaint(m_hWnd. &ps); } return 0; case WM_RBUTT0ND0WN: OnZoom( LOWORD(lParam). HIWORD(lParam). 1. 2); return 0; case WM_LBUTTONDOWN: OnZoom( LOWORD(lParam). HIWORD(lParam). 2. 1); return 0; case WM_HSCROLL: OnScroll(SB_HORZ. LOWORD(wParam). HIWORD(wParam)); return 0; case WMJSCROLL: OnScroll (SBJERT. LOWORD(wParam). HIWORD(wParam)); return 0; case WMJIMER: OnTimer(wParam. IParam); return 0; case WM_MOUSEMOVE: OnMouseMove(wParam. IParam); return 0; case WM_DESTROY: OnDestroyO; return 0;
Пример программы: прокрутка и масштабирование 377 default: return KCanvas::WndProc(hWnd. uMsg. wParam, IParam); } } Функция KScrollWindow::WndProc управляет обработкой сообщений окном. Для некоторых сообщений обработка сводится к вызову виртуальной функции, что позволяет производным классам обработать эти сообщения без переопределения функции WndProc. Для сообщения WMSIZE полосы прокрутки обновляются в соответствии с изменениями в размерах окна. Для сообщения WMPAINT программа читает позиции полос прокрутки и использует полученные значения для перемещения базовой точки области просмотра в позицию за левым верхним углом экрана. Обратите внимание: когда позиции полос прокрутки отличны от нуля, часть виртуального холста находится за пределами экрана слева и сверху. Исходя из этого, мы перемещаем базовую точку области просмотра во внеэкранную позицию, заданную координатами (-позиция вертикальной полосы прокрутки, -позиция горизонтальной полосы прокрутки). После правильного выбора методу OnDraw уже не придется беспокоиться о прокрутке. При обработке сообщения WM_LBUTT0ND0WN изображение в окне увеличивается в точке щелчка, а при обработке WMRBUTT0ND0WN изображение уменьшается. Полоса прокрутки генерирует сообщения WM_VSCROLL и WMHSCROLL, обрабатываемые одной функцией OnScroll. Эта функция (отсутствующая в приведенном листинге) вычисляет новую позицию прокрутки в соответствии с кодом, переданным в LOWORD(wParam), нормализует ее в допустимом интервале, обновляет позицию бегунка и затем прокручивает окно функцией Scroll Window. Функция Win32 Scroll Window прокручивает содержимое окна сдвигом экранного буфера. Открывшаяся непрорисованная часть добавляется в обновляемый регион окна и перерисовывается при последующей обработке WMPAINT. Игра го в классе KScrollCanvas Использование класса KScrollCanvas будет продемонстрировано на примере простой программы, которая рисует доску для игры го1. Кстати, го — японское название интереснейшей и очень древней китайской игры «вэйчи» (в буквальном переводе — «игра в окружение»). В листинге 6.6 приведено объявление класса KWeiQi Board. Производный класс реализует виртуальные методы OnDraw и OnCommand, обеспечивающие специализированный вывод и обработку команд меню. Листинг 6.6. Объявление класса KWeiQiBoard — вариант использования класса KScrollCanvas class KWeiQiBoard : public KScrollCanvas { virtual void OnDraw(HDC hDC, const RECT * rcPaint); virtual BOOL OnCommand(WPARAM wParam. LPARAM IParam); int m_grids ; 1 Cm. http://www.go.sp.ru. — Примеч. перев.
378 Глава 6. Системы координат и преобразования Листинг 6.6. Продолжение int mjjnitsize ; char * m_stones; int margin(void) const; // Поля с четырех краев холста int pos(int n) const; // Позиция n-ro пересечения public; KWeiQiBoardO { m_grids =19; // Доска 19 x 19 mjjnitsize = 20; // 20 пикселов между пересечениями m_stones = "B20212223241404W3031323334251505"; // Пример SetSize(pos(m_grids-l)+margin(), pos(m_grids-l)+margin(). mjjnitsize. mjjnitsize); } }: Результат показан на рис. 6.9. Изображение было увеличено и прокручено к правому нижнему углу доски. fite $utfd, Рис. 6.9. Доска для игры го, выведенная с использованием класса KScrollCanvas Итоги Эта глава посвящена четырем системам координат, поддерживаемым в Win32 API, — мировой, страничной, системе координат устройства и физической системе координат. Мы рассмотрели мировые преобразования, отображающие ко-
Итоги 379 ординаты из мировой системы координат в страничную; различные режимы отображения, управляющие преобразованием координат из страничной системы в систему координат устройства; кроме того, было описано отношение между системой координат устройства и физической системой координат. Глава завершается подробным описанием аффинных преобразований, их свойств и некоторых операций, включая композицию и обращение. Изложенный материал иллюстрирует класс KScrollView, поддерживающий масштабирование и прокрутку. Глава завершается простым примером использования этого класса. Примеры программ В этой главе рассматриваются всего два примера программ (табл. 6.3). Таблица 6.3. Программы главы б Каталог проекта Описание Samples\ChaptJ)6\CoordinateSpace Исследование систем координат и аффинных преобразований Samples\ChaptJ)6\WeiQi Тестовая программа для класса KScrollView с поддержкой масштабирования и прокрутки
Глава 7 Пикселы Из всех операций с контекстами устройств в Win32 GDI самая трудная — это вывод отдельного пиксела. Конечно, речь идет не о простом изменении цвета пиксела, а скорее о полном понимании всех факторов, влияющих на процесс вывода. При условии такого понимания вывод линий, кривых, фигур, растров и текста уже не вызовет особых затруднений. Глава 6 была посвящена системам координат, режимам отображения и преобразованиям; в этой главе рассматриваются объекты GDI, манипуляторы, отсечение, цвет и, наконец — вывод отдельного пиксела. Объекты GDI, манипуляторы и таблица объектов В Win32 API используются десятки всевозможных объектов (файловые объекты, объекты синхронизации, объекты GDI и т. д.), хотя интерфейс API не основан ни на одном из современных объектно-ориентированных языков программирования. Windows 1.0 API был выпущен в 1985 году, когда на C++ писали всего 500 программистов — это было задолго до стремительного роста популярности объектно-ориентированных языков в 1990-х годах. Объектом в объектно- ориентированном языке называется экземпляр класса, члены которого (переменные и функции класса) определяют данные объекта и его поведение. Новые объекты инициализируются специальными функциями класса, которые называются конструкторами. Для уничтожения объектов используются другие специальные функции, называемые деструкторами. Таким образом, с объектом в объектно-ориентированном языке связывается некоторая совокупность данных и функций, выполняющих некоторые операции. В определении класса указано, какие из переменных и функций являются открытыми, защищенными или закрытыми. Тем самым достигается одна из важных целей — маскировка реализации.
Объекты GDI, манипуляторы и таблица объектов 381 Хотя Win32 API и не является объектно-ориентированным, этот интерфейс по-своему пытается решить те же проблемы, для решения которых создавались объектно-ориентированные языки — а именно маскировку реализации и абстрактные типы данных. Win32 API маскирует свои объекты в большей степени, чем объектно-ориентированные языки. Работая с объектами Win32 API, прикладная программа не знает их размера или местонахождения в памяти. В Win32 API поддерживаются специальные функции для создания объектов разных типов, отличающиеся от конструкторов языка C++. Объекты C++ создаются за два этапа: сначала для объекта выделяется память, а затем объект инициализируется конструктором. Следовательно, приложение, использующее объект, должно точно знать, сколько памяти занимает объект и где он находится в памяти. Функции Win32 для создания объектов Win32 скрывают и размер, и адрес объекта. Более того, приложение даже не получает указателя на объект; ему лишь предоставляется манипулятор объекта. Манипуляторы Win32 API представляют собой числа, однозначно идентифицирующие oбъeктыWin32, причем способ идентификации известен только операционной системе. Концепция абстрактных типов данных представлена в C++ абстрактными классами, конкретными классами и виртуальными функциями. Абстрактный класс определяет общее поведение класса при помощи виртуальных функций. Один и тот же абстрактный класс может быть по-разному реализован несколькими конкретными классами, каждый из которых предоставляет свою реализацию виртуальных функций. Объекты конкретных классов могут интерпретироваться как объекты абстрактного класса, у которых вызовы функций осуществляются через таблицу виртуальных функций. При внимательном рассмотрении оказывается, что в Win32 используется немало абстрактных типов объектов. Например, тип файлового объекта является абстрактным типом, на базе которого создаются различные типы конкретных объектов. Функция CreateFile может использоваться для создания файлов, каналов, почтовых слотов, коммуникационных портов, консолей, каталогов и устройств, причем во всех случаях возвращается один и тот же тип манипулятора. Трассировка функции WriteFile показывает, что завершающая операция выполняется разными фрагментами, относящимися к разным частям операционной системы и даже к драйверам устройств, что очень похоже на использование виртуальных функций в C++. В области GDI контекст устройства можно рассматривать как абстрактный тип объекта. При создании или получении контекста устройства для принтера или экрана, совместимого или метафайлового контекста вы всегда получаете один и тот же тип манипулятора контекста. Конечно, общие графические вызовы по конкретному манипулятору обрабатываются разными функциями, предоставленными GDI или драйверами графических устройств через таблицу указателей на функции в структуре физического устройства. Короче, существуют достаточно веские причины для того, чтобы называть Win32 API «объектно-базированным». А теперь давайте посмотрим, как в Windows NT/2000 организовано хранение объектов GDI и как устанавливается соответствие между манипуляторами и объектами. Заодно вы познакомитесь с конкретным примером реализации Win32 GDI — конечно же, далеко не единственной из возможных.
382 Глава 7. Пикселы Хранение объектов GDI Объекты C++ обычно хранятся в стеке, в куче или в другом месте, определяемом перегруженным оператором new. Как правило, этим местом является адресное пространство пользовательского режима, если только речь не идет о драйвере устройства режима ядра. Графическая система Windows NT/2000 делится на три части: клиентскую библиотеку DLL пользовательского режима (gdi32.dll), графический механизм режима ядра (win32k.sys) и различные драйверы устройств, также обычно работающие в режиме ядра. Разделение реализации на два режима несколько усложняет архитектуру хранения объектов GDI. Объект GDI, целиком хранящийся в адресном пространстве пользовательского режима, доступен лишь в то время, когда активен создавший его процесс, поскольку каждый процесс обладает собственным адресным пространством пользовательского режима. После переключения процесса адрес, по которому хранится объект, становится недействительным. При таком подходе операции GDI в графическом механизме режима ядра могли бы выполняться лишь в контексте процесса, из которого поступил вызов. Конечно, это затруднило бы процесс быстрого переключения задач, необходимый для современных многозадачных систем. С другой стороны, объект GDI, полностью хранящийся в адресном пространстве режима ядра, доступен только из пространства режима ядра. При выполнении простейших операций (например, присваивании значений атрибутам контекстов устройств) системе пришлось бы вызывать системную функцию для переключения процессора в режим ядра, выполнять несколько строк ассемблерного кода, а затем переключаться обратно в пользовательский режим. В Windows NT/2000 объект GDI обычно хранится в виде двух частей — объекта пользовательского режима и объекта режима ядра. Объект пользовательского режима обеспечивает быстрое выполнение операций, а в объекте режима ядра хранится информация, не зависящая от процесса. Некоторые объекты режима ядра (например, объект контекста устройства) содержат полные копии своих объектов пользовательского режима, синхронизируемые при помощи какого-либо механизма. Для большинства объектов GDI хранит в памяти некоторую структуру данных фиксированного размера. В этом случае использование памяти не вызывает особых проблем. Однако для объектов регионов и аппаратно-зависимых растров объем данных, хранимых GDI, может увеличиться до значительных размеров. Структуры данных GDI режима ядра хранятся в так называемом выгружаемом пуле. В однопользовательской системе архитектуры Windows NT/2000 объем выгружаемого пула ядра не превышает 192 Мбайт. Учитывая, что внутренняя память GDI имеет ограниченный размер и совместно используется всеми приложениями системы, приложения должны умеренно пользоваться ресурсами системы и избегать создания больших регионов и аппаратно-зависимых растров.
Объекты GDI, манипуляторы и таблица объектов 383 Таблица объектов GDI Информация об объектах GDI хранится в системной таблице фиксированного размера, которая называется «таблицей объектов GDI». Здесь необходимо обратить внимание на ряд моментов. Во-первых, таблица объектов GDI имеет фиксированный размер и не расширяется динамически, как можно было бы предположить. Такое решение отличается простотой и эффективностью, но ему присущи некоторые ограничения. В настоящее время для Windows NT/2000 таблица объектов GDI рассчитана на 16 384 манипулятора. Во-вторых, таблица объектов GDI совместно используется всеми процессами и системными DLL. Ваш рабочий стол, браузер, текстовый редактор и игры DirectX — все они соревнуются за общий набор манипуляторов GDI. В Windows 2000 интерфейс DirectX использует отдельную таблицу манипуляторов. Таблица объектов GDI хранится в адресном пространстве ядра, что упрощает доступ к ней со стороны графического механизма. В адресных пространствах всех процессов, использующих GDI, создается копия этой таблицы, доступная только для чтения. ПРИМЕЧАНИЕ На терминальных серверах каждый сеанс обладает собственной копией графического механизма Windows и собственной копией диспетчера окон (win.32k.sys), поэтому в системе может присутствовать несколько таблиц объектов GDI. Элементы таблицы манипуляторов GDI представляют собой 16-байтовые структуры: typedef struct { void * pKernel; unsigned short nPid; unsigned short nCount; unsigned short nUnique; unsigned short nType; void * pUser; } GdiTableEntry; Для каждого объекта GDI в таблице хранится указатель на объект режима ядра, указатель на объект пользовательского режима, идентификатор процесса, некий счетчик, уникальный код и идентификатор типа. Какое изящное, элегантное решение! В поле nPid хранится идентификатор процесса, создавшего объект (значение, возвращаемое при вызове GetCurrentProcessIdO). Каждый объект GDI, созданный пользовательским процессом, помечается идентификатором процесса, что предотвращает использование манипуляторов GDI другими процессами. Получая манипулятор объекта, GDI может легко проверить, был ли этот объект создан текущим процессом. Попытки использования объектов GDI, созданных другими процессами, завершаются неудачей. Исключение составляют стандартные объекты GDI вроде черного пера, белой кисти и системного шрифта, по умолчанию выбираемых в новых контекстах устройств. Было бы слишком расточительно создавать копии стандартных объектов в каждом процессе. Вместо этого
384 Глава 7. Пикселы стандартные объекты создаются в системе всего один раз, и им присваивается нулевой идентификатор процесса. Диспетчер задач сообщает, что нулевой идентификатор соответствует процессу пассивного ожидания (idle). Объекты GDI с нулевыми идентификаторами доступны всем процессам. Поле nCount содержит счетчик выбора (или счетчик ссылок), который предотвращает удаление задействованных объектов или гарантирует, что некоторые объекты могут выбираться в контекстах лишь один раз. К сожалению, использование поля nCount в значительной степени ограничено, и в настоящее время пользовательские приложения должны сами следить за тем, когда объекты можно удалять. Возможно, наибольший интерес представляет поле nUnique. Как говорилось выше, объекты GDI хранятся в одной таблице. После создания, использования и удаления объекта соответствующий элемент таблицы освобождается и позднее выделяется для другого объекта. Допустим, программа сохранила манипулятор первого объекта и решила воспользоваться им; что при этом произойдет? В Windows NT/2000 такая попытка почти наверняка завершится неудачей благодаря полю nUnique. Это поле делится на 8-разрядный счетчик многократного использования и 8-разрядный код типа. Счетчик инициализируется нулем и увеличивается каждый раз, когда в данном элементе таблицы создается новый объект GDI. Существует специальный механизм, обеспечивающий равномерное использование элементов таблицы. Следовательно, манипулятор пройдет проверку уникальности лишь при условии, что количество элементов, созданных в этом элементе таблицы, кратно 256 и типы объектов совпадают. В поле пТуре хранится внутренний признак типа, который преобразуется в тип объекта GDI, возвращаемый функцией GetObjectType. Манипулятор объекта GDI В MSDN манипулятор определяется как переменная, однозначно определяющая объект, или косвенная ссылка на ресурс операционной системы. В наши дни считается, что программист должен довольствоваться подобным абстрактным определением и писать отличные программы. Но при диагностике проблем, связанных с совместимостью 16- и 32-разрядного кода в Windows NT/2000, а также при написании низкоуровневых утилит желательно точно представлять себе смысл каждого бита манипулятора Win32 API. Манипулятор объекта GDI в Windows NT/2000 состоит из двух 16-разрядных компонентов — уникального кода и индекса в таблице объектов GDI. Чтобы получить адрес объекта в таблице, достаточно замаскировать младшие 16 бит манипулятора, умножить их на 16 и прибавить к начальному адресу таблицы объектов GDI. Начальный адрес таблицы объектов GDI хранится в глобальных переменных библиотек win32k.sys и gdi32.dll. Выше уже упоминался уникальный код, обеспечивающий дополнительную защиту. Уникальный код также включается в манипуляторы объектов GDI. Чтобы GDI разрешил обращение к манипулятору, уникальный код манипулятора GDI должен совпадать с кодом, хранящимся в таблице объектов GDI. После получения индекса в таблице объектов GDI выполняется дополнительная про-
Объекты GDI, манипуляторы и таблица объектов 385 верка идентификатора процесса. Это позволяет легко отвергнуть недействительные, устаревшие и принадлежащие внешним процессам манипуляторы. В текущей реализации максимальное количество манипуляторов объектов GDI уровня системы (или уровня сеанса на терминальном сервере Windows) равно 16 384. Это значение легко увеличивается до 65 536, поскольку в манипуляторах GDI из 16 бит, выделенных для индексной части, используется всего 12. Пользовательские приложения не должны полагаться па знание внутреннего формата манипуляторов GDI или структуры таблицы объектов GDI, поскольку они изменялись раньше и могут измениться в будущих версиях. С другой стороны, в Windows NT/2000 для манипуляторов GDI устанавливаются дополнительные ограничения и меры защиты, помогающие в отладке кода. Следите за тем, чтобы манипуляторы GDI не передавались за пределы процесса, и тестируйте свои приложения во всех современных версиях Windows. За дополнительной информацией о внутренних структурах данных GDI обращайтесь к главе 3. API объектов GDI Объекты GDI делятся на несколько категорий. Наиболее распространенными типами объектов GDI являются логические кисти, логические перья, логические шрифты, логические палитры, регионы, аппаратно-зависимые растры, DIB-сек- ции, расширенные метафайлы и контексты устройств. Для каждого типа объектов создаются специальные функции, предназначенные для создания объектов этого типа. При создании объекта интерфейс GDI возвращает приложению манипулятор. При вызове многих функций GDI передается HGDI0BJ — обобщенный тип манипулятора объекта GDI. HGDIOBJ SelectObjectCHDC hDC. HGDIOBJ hgdiobj); BOOL DeleteObjectCHGDIOBJ hObject); DWORD GetObjectType(HGDIOBJ h); int GetObject(HGDIOBJ hgdiobj. int cdBuffer. LPVOID lpvObject); Некоторые типы объектов GDI (кисти, перья, шрифты, палитры, аппаратно-зависимые растры и DIB-секции) могут использоваться в качестве атрибутов контекста устройства. Такие объекты связываются с контекстом устройства при помощи функции SelectObject. При вызове эта функция возвращает манипулятор предыдущего объекта GDI, относящегося к тому же типу. Чтобы восстановить в контексте устройства старый объект, достаточно снова вызвать Select- Object для значения, полученного при предыдущем вызове. Логические палитры выбираются в контекстах устройств специальной функцией SelectPalette. Когда объект GDI становится ненужным, его следует удалить функцией DeleteObject. Перед удалением объекта приложение должно проследить за тем, чтобы он не был выбран ни в одном контексте устройства. Подходы к удалению объектов GDI в Windows 95/98/Ме и Windows NT/2000 несколько различаются. В Windows 95/98/Ме функция DeleteObject не удаляет объекты, выбранные в контекстах устройств, что может привести к утечке объектов. В Windows NT/2000 объект GDI удаляется даже в том случае, если он остается выбранным. Дальнейшие попытки вывода с использованием удаленного объекта GDI приводятся к возникновению ошибок, что упрощает диагностику проблемы программистом.
386 Глава 7. Пикселы Если программа разрабатывалась и нормально работала на компьютере с Windows NT/2000, но отказывается работать в Windows 95/98/Ме, одно из возможных объяснений кроется в некорректном удалении объектов. Приведенный ниже класс KGDIObject представляет собой простую оболочку для выбора, исключения из контекста и удаления объектов GDI. class KGDIObject { HGDIOBJ m_h01d; HDC m_hDC: public: HGDIOBJ m_hObj; KGDIObject(HDC hDC. HGDIOBJ hObj) { m_hDC = hDC: m_hObj - hObj: m_h01d - SelectObject(hDC. hObj): assert(m_hDC): assert(m_hObj); assert(m_h01d): } -KGDIObjectО { HGDIOBJ h = SelectObject(m_hDC. m_h01d): assert(h-=j): DeleteObject(mJiObj): // assert(GetObjectType(m_hObj)==0): } }: Объект KGDIObj содержит три переменные, в которых хранятся манипулятор выбираемого объекта GDI, манипулятор контекста устройства и манипулятор исходного объекта в этом контексте. Конструктор выбирает объект GDI в контексте устройства. Три директивы assert проверяют правильность параметров и успешность выполнения операции. Деструктор класса исключает объект GDI из контекста и удаляет его. Первая директива assert убеждается в том, что исключение прошло нормально. Вторая директива проверяет результат удаления объекта. В приведенном коде она закомментирована, поскольку GDI иногда кэши- рует объекты для ускорения создания объектов того же типа. ПРИМЕЧАНИЕ В MFC оболочка для вызова SelectObject возвращает указатель на экземпляр CGdiObject — класс объекта GDI в MFC. Но если MFC не удается установить соответствие между манипулятором объекта GDI и указателем на объект MFC, то возвращается указатель на временный объект. Если приложение воспользуется временным указателем для исключения неиспользуемого объекта из контекста, может оказаться, что контекст уже был изменен другим вызовом SelectObject, что приведет к утечке объектов GDI.
Объекты GDI, манипуляторы и таблица объектов 387 Простой пример использования класса KGDIObject: void OnDraw(HDC hDC) { KGDIObject blue(hDC. CreateSolidBrush(RGB(O.O.OxFF)); Rectangle(hDC. 0. 0. 100. 100); } При завершении процесса все созданные им объекты GDI автоматически удаляются из таблицы (вероятно, по идентификатору процесса, связанному с каждым объектом GDI). И все же приложение должно само обеспечивать правильное удаление объектов, не рассчитывая на то, что весь мусор после завершения процесса уберет система. Постоянная утечка ресурсов GDI быстро нарушает нормальную работу всей системы. Функция GetObjectType получает манипулятор объекта GDI и возвращает целое число, обозначающее тип объекта GDI. Например, для контекста устройства возвращается константа 0BJ_DC, для объекта логической кисти — константа OBJJJRUSH, для аппаратно-зависимого растра или DIB-секции — константа OBJ BITMAP и т. д. Если функция возвращает 0, значит, переданный ей манипулятор объекта GDI либо недействителен, либо принадлежит другому процессу. Функция GetObject может использоваться для получения информации об исходной структуре, передаваемой при создании некоторых типов объектов GDI. Для аппаратно-зависимого растра она заполняет структуру BITMAP, для DIB-секции — структуру DIBSECTION, для расширенного пера — структуру EXTLOGPEN, для пера — структуру L0GPEN, для кисти — структуру L0GBRUSH, для шрифта — структуру L0GF0NT, а для палитры — структуру WORD. При вызове Gdi Object передается манипулятор объекта GDI, предполагаемый размер структуры и указатель на блок данных, размер которого достаточен для хранения структуры. Если вызывающая сторона не уверена в том, сколько байт потребуется для хранения структуры, она может получить количество байт, вызывая функцию GetObject с указателем NULL. Функция GetObject позволяет отличить аппаратно-зависимый растр от DIB- секции (функция GetObjectType их не различает). Для этого достаточно вызвать GetObject со структурой DIBSECTION; если вызов завершится успешно, значит, объект GDI является DIB-секцией. Все типы объектов GDI будут подробно рассматриваться по мере необходимости. Обнаружение утечки объектов GDI При проявлении симптомов утечки объектов GDI — например, при сбоях во время вывода или нарушениях внешнего вида системных интерфейсных элементов — очень трудно определить, какое приложение вызывает проблему, какие именно ресурсы теряются и где это происходит. Вероятно, существует всего одна достойная программа для обнаружения утечки памяти и ресурсов — BoundsChecker компании Numega. В процессе работы BoundsChecker перехватывает практически все функции Win32 API для последующего сохранения, проверки и анализа параметров и возвращаемых значений. Например, при регистрации всех вызовов функций API, создающих и удаляю-
388 Глава 7. Пикселы щих объекты, программа типа BoundsChecker сравнивает созданные объекты с удаляемыми перед завершением программы и находит все утечки объектов GDI с точной информацией о вызывающей стороне. В главе 4 описаны некоторые утилиты для отслеживания вызовов функций GDI API, системных функций и функций DDL Эти утилиты нетрудно усовершенствовать для поиска утечек ресурсов GDI. Зная внутренние структуры данных GDI, можно без особого труда написать программу, которая следит за использованием объектов GDI всеми процессами Windows NT/2000. Такая программа выведет сведения обо всех ресурсах GDI в системе, хотя она и не располагает информацией, необходимой для поиска утечек. На рис. 7.1 изображено окно программы GDIObj, написанной специально для этой главы. Программа регулярно просматривает содержимое таблицы объектов GDI, сортирует записи по идентификатору процесса и типу, после чего отображает в табличном представлении. fM^fK^A 4S*SJ \т 912 18 212 164 184 1948 2336 224 392 440 480 536 852 944 908 928 lixL Х.?ш$$$ >. unknown 0SA.EXE unknown services.exe unknown winlogon.exe MSDEV.EXE IEXPLORE.EXE lsass.exe svchost.exe spoolsv.exe svchost.exe MSTask.exe Explorer.exe internat.exe tgsched.exe zm32nt.exe JIafot 707 25 5 4 22 14 466 256 4 4 8 4 4 126 15 4 5 Ш 10 3 5 2 3 2 48 25 2 2 2 2 2 20 6 2 2 ,Jl..^e^, 38 0 0 0 4 1 5 8 0 0 1 0 0 23 1 0 0 JjBiJmaf 357 5 0 1 1 4 269 160 1 1 1 1 1 33 5 1 1 ffietfe 175 0 0 0 0 1 5 3 0 0 0 0 0 5 0 0 0 T*w 16 0 0 0 12 5 73 28 0 0 0 0 0 20 0 0 1 J 8iSi 45 17 0 1 2 1 66 32 1 1 4 1 1 25 3 1 1 |ЩЩ ""б™ | 0 0 о • 0 0 о • 0 ' 0 0 0 0 0 J 0 0 0 0 J J"jT Рис. 7.1. Программа наблюдения за объектами GDI Как видно из рисунка, MS Developer Studio использует 466 объектов GDI, 2,8 % от максимального количества. Если число манипуляторов GDI, используемых приложением, продолжает расти, это является верным признаком утечки объектов. Для отслеживаемого процесса GDIObj выводит общее количество объектов GDI и отдельные данные по нескольким распространенным категориям. При возникновении утечки вы будете знать, какие объекты GDI теряются. На рисунке показано, что первый процесс (PID = 0) использует 66 объектов, не относящихся ни к однорИхз категорий. В основном это объекты физических шрифтов, задействованные GDI. Кроме того, из рисунка видно, что процессы
Объекты GDI, манипуляторы и таблица объектов 389 Win32 с графическим интерфейсом используют минимум четыре объекта GDI: два контекста устройства, один растр и одну кисть. Эти объекты могут создаваться в процессе инициализации user32.dll или gdi32.dll. Следовательно, в системе может одновременно работать не более 4096 процессов, поскольку таблица рассчитана всего на 16 384 манипулятора. В Windows 2000 появилась новая функция, при помощи которой приложения получают информацию об использовании ресурсов GDI и USER. DWORD GetGuiResources(HANDLE hProcess. DWORD uiflags): Функция GetGui Resources сообщает, сколько объектов GDI или USER в настоящее время используется приложением. В первом параметре GetGui Resources передается манипулятор интересующего вас процесса. Второй параметр принимает значения GRGDI0BJECTS и GRUSEROBJECTS. Функция возвращает текущее количество используемых объектов. Функция GetResources является «законным» средством для поиска утечки ресурсов. Например, ее можно вызвать до и после выполнения некоторого фрагмента, сравнить возвращаемые значения и узнать, создает ли этот фрагмент новые объекты. Хотя различающиеся значения не всегда свидетельствуют об утечке ресурсов из-за возможного кэширования объектов приложением и GDI, устойчивый рост числа объектов является верным признаком их утечки. Ниже приведен простой класс-оболочка KGUIResource и пример его использования при обработке сообщения WMPAINT: class KGUIResource { int m_gdi. mjjser; public: KGUIResourceO { m_gdi - GetGuiResources(GetCurrentProcess(). GR_GDIOBJECTS); m_user = GetGuiResources(GetCurrentProcess(). GRJJSEROBJECTS): } -KGUIResourceO { int gdi = GetGuiResources(GetCurrentProcess(). GR_GDIOBJECTS); int user = GetGuiResources(GetCurrentProcess(). GRJJSEROBJECTS); if ( (m_gdi==gdi) && (m_user==user) ) return; char temp[64]; wsprintf(temp. "ResourceDifference: gdi(%d->%d) userUd->$d)\n". m_gdi. gdi. m_user. user); OutputDebugString(temp); } }: case WM_PAINT: { KGUIResource res;
390 Глава 7. Пикселы PAINTSTRUCT ps; HDC hDC - BeginPaint(m_hWnd. &ps); OnDraw(hDC. &ps.rcPaint): EndPaint(m_hWnd. &ps); } Отсечение В компьютерной графике отсечением (clipping) называется часть алгоритма графического вывода, обеспечивающая избирательное исключение некоторых частей изображения из процесса вывода. Например, если вы читаете документ в текстовом редакторе при большом увеличении, в окне отображается лишь малая часть страницы, а все остальное отсекается. А если вы в графическом редакторе заключаете рисунок в овальную рамку, отсекается все, что находится за пределами овала. Традиционно отсечение определяется в логическом адресном пространстве. Скажем, при выводе в окне отображаются только те графические примитивы, которые попадают в это окно; все остальное отсекается. Существуют специальные алгоритмы, вычисляющие пересечение графических примитивов с окном, чтобы в вывод включались только неотсеченные участки. Отсечение принадлежит к числу базовых возможностей Windows GDI. Например, приложение может провести линию от начала координат в псевдобесконечную точку 32-разрядного координатного пространства (maxint,maxint). При достижении границы клиентской области окна или контекста устройства вывод немедленно прекращается. Такой подход существенно упрощает проектирование графических алгоритмов. Конвейер отсечения С концептуальной точки зрения каждый графический вызов проходит через несколько уровней отсечения, образующих конвейер отсечения (clipping pipeline). Документация Microsoft на эту тему весьма туманна, а иногда и недостоверна — как, впрочем, и немногочисленные книги, написанные на эту тему. Приведу конкретный пример: «При получении манипулятора контекста устройства функцией BeginPaint DC содержит заранее определенный прямоугольный регион отсечения, который соответствует недействительному прямоугольнику, нуждающемуся в перерисовке». Это описание содержит целых три ошибки. Ниже перечислены известные нам уровни отсечения, поддерживаемые в Microsoft Windows. О Прямоугольник окна. У каждого окна имеется прямоугольная область, которая изначально определяется при вызове CreateWindow/CreateWindowEx и в дальнейшем может изменяться. Все, что находится за пределами прямоугольника окна, отсекается.
Отсечение 391 О Регион окна. Приложение может изменить регион окна и придать окну произвольную форму при помощи функции SetWindowRgn. Все, что находится за пределами региона окна, отсекается. О Видимость. Окна могут перекрывать друг друга; у окна могут быть дочерние или соседние окна. Любая часть окна, закрытая другим окном, отсекается. Области, закрытые дочерними и соседними окнами, также могут отсекаться при указании флагов WS_CLIPCHILDREN и WS_CLIPSIBLINGS. О Клиентская область. Если контекст устройства соответствует клиентской области окна, все, что находится за пределами клиентской области, отсекается. О Обновляемый регион. Win32 поддерживает API для определения обновляемого региона (update region) окна — региона, нуждающегося в обновлении. Описание обновляемого региона можно получить при помощи функции GetUpdate- Region. Для контекста устройства, возвращаемого функцией BeginPaint, все, что находится за пределами обновляемого региона, отсекается. О Системный регион. Комбинированный регион, построенный с учетом перечисленных выше факторов, называется системным регионом (system region). Информацию о системном регионе контекста устройства можно получить при помощи функции GetRandomRgn(hDC, hRgn, SYSRGN). О Метарегиои. Метарегион (meta region) образует первый уровень отсечения в контексте устройства, находящийся под управлением приложения. Все, что находится за пределами метарегиона, отсекается. О Регион отсечения. Регион отсечения (clip region) образует второй уровень отсечения в контексте устройства, находящийся под управлением приложения. Все, что находится за пределами этого региона, отсекается. А теперь давайте перефразируем приведенное выше описание региона отсечения, в котором упоминается функция BeginPaint. При получении манипулятора контекста устройства функцией BeginPaint DC содержит заранее определенный системный регион, который может и не быть прямоугольным; он генерируется на основании обновляемого региона окна с учетом других факторов. Метарегион и регион отсечения всегда начинаются с состояния NULL-регионов; они позволяют приложению управлять процессом отсечения. Системный регион находится под управлением операционной системы и автоматически обновляется при изменении размеров или перемещении окна. Метарегион и регион отсечения находятся под управлением приложения. Пиксел выводится лишь в том случае, если он принадлежит пересечению системного региона, метарегиона и региона отсечения. В каком-то смысле термин «отсечение» в названии «регион отсечения» сбивает с толку, поскольку этот регион определяет остающиеся, а не отсекаемые точки. Отсекается лишь то, что находится за пределами этого региона. Простые регионы Регион представляет собой множество точек в координатном пространстве. Это множество может быть пустым либо состоять из точек, образующих прямоугольник, круг или фигуру произвольной формы или же занимающих всю коорди-
392 Глава 7. Пикселы натную поверхность. В Win32 предусмотрен богатый набор функций API для работы с регионами как с одним из типов объектов GDI. В этом разделе рассматриваются некоторые простые возможности, которые позволят нам двигаться дальше, а более сложный материал будет изложен в дальнейших главах. В Win32 регион представляет собой такой же объект, находящийся под управлением GDI, как контекст устройства, логическое перо, логическая кисть и т. д. Когда приложение вызывает функцию создания региона, система создает объект региона, инициализирует его нужными данными и возвращает манипулятор региона приложению. Манипулятор региона (тип HRGN) позднее передается GDI при выполнении операций с регионом. Простейший способ создания региона: HRGN CreateRectRgn( int hLeftRect, int nTopRect. int nRightRect. int nBottomRect); Функция создает прямоугольный регион, содержащий все точки прямоугольника, определяемого вершинами (nLeftRect, nTopRect) и (nRightRect, nBottomRect), за исключением нижнего и правого края. Учтите, что относительное расположение вершин не фиксируется; GDI автоматически упорядочивает точки так, чтобы они образовывали прямоугольник. Рассмотрим несколько примеров: HRGN hRgnl = OeateRectRgn(0. 0. 0. 0): HRGN hRgnl = CreateRectRgnCO. 0. 1. 1); HRGN hRgnl = CreateRectRgn(-0x7FFFFFF, -0x7FFFFFF. -0x7FFFFFF. -0x7FFFFFF); HRGN hRgnl = CreateRectRgnCl. 1. 0, 0); Первый регион пуст, а второй содержит всего одну точку (0,0). Вероятно, третий вызов создает самый большой регион, поддерживаемый 32-разрядной реализацией GDI в Windows NT/2000. Последний регион идентичен второму. Исключение правого и нижнего края нередко приводит к недоразумениям. При создании прямоугольного региона {0, 0, 1, 1} GDI сохраняет объект региона с прямоугольником {0, 0, 1, 1} вместо {0, 0, 0, 0}. Правый и нижний край исключаются только на завершающей стадии вывода или обработки некоторых запросов на получение информации. Такой подход упрощает выполнение операций с регионами. Например, при увеличении региона {0, 0, 1, 1}вп раз он превращается в регион {0, 0, п, п}, содержащий п х п точек. А как масштабировать регион, представленный квартетом {0, 0, 0, 0}? Во что он должен превращаться — в {О, О, О, 0} или в {0, 0, п-1, п-1}? Когда объект региона становится ненужным, освободите связанные с ним ресурсы функцией DeleteObject. Регион отсечения Одним из атрибутов контекста устройства является регион отсечения. В этом атрибуте хранится объект региона, определяемый приложением и описывающий границы области, в которой осуществляется вывод. Для контекстов устройств, возвращаемых функциями BeginPaint, GetDC или CreateDC, регион отсечения пуст (атрибут равен NULL). В этом случае говорят, что у приложения нет региона отсечения. NULL-регион отсечения не следует путать с пустым регионом в смысле теории множеств; наоборот, это его полная противоположность. При пустом регио-
Отсечение 393 не отсечения (например, CreateRectRgnCO, 0, 0, 0)) не выводится ничего, то есть все изображение отсекается. NULL-регион отсечения означает, что выводится все, что находится в системном регионе. Таким образом, пустой регион отсечения представляет собой пустое множество точек, а NULL-регион можно рассматривать как полный набор точек на поверхности устройства (в этом случае также говорят об отсутствии региона отсечения в контексте устройства). Ниже перечислены базовые функции для работы с регионами отсечения. int GetClipRgnCHDC hDC, HRGN hrgn); int SelectClipRgn(HDC hDC. HRGN hrgn); int ExtSelectClipRgn(HDC hDC. HRGN hrgn. int fnMode); int OffsetClipRgnCHDC hDC. int nXOffset. int nYOffset): int ExcludeC1ipRect(HDC hDC. int nLeftRect. int nTopRect. int nRightRect. int nBottomRect); int IntersectClipRect(HDC hDC, int nLeftRect. int nTopRect. int nRightRect. int nBottomRect); int GetClipBox(HDC hDC. LPRECT lprc): Многие функции регионов отсечения возвращают целочисленный код сложности региона. Другие функции (например, GetClipRgn) возвращают код завершения (0, 1 или -1). Ниже перечислены некоторые из допустимых кодов сложности. NULLREGION Пустой регион (не содержащий ни одной точки) SIMPLEREGION Регион состоит из одного прямоугольника C0MPLEXREGI0N Регион имеет более сложную структуру ERROR Произошла ошибка (предыдущее состояние региона не меняется) Код NULLREGION означает, что регион пуст (например, был получен в результате пересечения двух несмежных регионов). Как было сказано выше, пустой регион не следует путать с NULL-регионом. Код SIMPLEREGION означает, что множество точек региона образует прямоугольник. Кодом C0MPLEXREGI0N описывается любой действительный регион, который не может быть представлен простым прямоугольником. Код ERROR обычно означает, что при вызове функции GDI были переданы недопустимые или равные NULL значения. Если вы знаете, как организовано взаимодействие с контекстами устройств других объектов GDI (например, перьев, кистей или шрифтов), API регионов отсечения может показаться странным и непонятным. Функция GetCurrentObject возвращает информацию о текущем пере, кисти или шрифте, выбранном в контексте устройства, а функция SelectObject заменяет его новым объектом GDI. Объект, выбранный в контексте устройства, считается используемым и может быть удален лишь после исключения его из контекста. Взаимодействие объекта региона с контекстом устройства в большей степени основано на данных, определяющих регион, нежели на манипуляторе региона. Выражаясь точнее, для контекста устройства нельзя получить манипулятор текущего региона отсечения, а после выбора региона отсечения в контексте устройства его манипулятор уже не считается используемым в этом контексте. Чтобы получить текущий регион отсечения для контекста устройства, приложение должно создать действительный объект региона и передать его манипулятор функции GetClipRgn в параметре hrgn. Таким образом, hrgn ссылается на вполне действительный, хотя и реально не используемый объект региона. Если
394 Глава 7. Пикселы контекст устройства содержит регион отсечения, GetClipRgn освобождает объект региона, на который ссылается hrgn, создает копию региона отсечения из контекста устройства и помещает ссылку на новый регион отсечения в hrgn. Результат, возвращаемый GetClipRgn, представляет собой код сложности региона (пустой, прямоугольный или сложный регион). Если регион отсечения в контексте устройства не задан, возвращается значение О (ERROR), а параметр hrgn не изменяется. При вызове SelectClipRgn в параметре hrgn может передаваться манипулятор действительного объекта региона. В этом случае GDI создает копию данных региона и связывает ее с контекстом устройства. Обратите внимание: переданный манипулятор не закрепляется за контекстом устройства; приложение может удалить его после вызова. Параметр hrgn также может быть равен NULL; в этом случае объект региона отсечения, хранящийся в контексте устройства, освобождается, а в контексте устройства устанавливается NULL-регион отсечения. Такие атрибуты контекста, как логическое перо, в определенном смысле задаются своими манипуляторами. После того как манипулятор объекта будет выбран в контексте устройства, он считается используемым в этом контексте и не может быть удален до тех пор, пока в контексте не будет выбран манипулятор другого объекта того же типа. С другой стороны, регион отсечения задается своими данными. При передаче манипулятора региона функции SelectClipRgn создается копия данных региона, а не манипулятора. Когда приложение захочет получить текущий регион отсечения, оно предоставляет действительный манипулятор региона, и данные этого региона заменяются данными региона отсечения. Если в контексте устройства отсутствует регион отсечения, функция GetClipRgn возвращает 0, в этом случае параметр-регион не изменяется. Вообще говоря, в только что созданных контекстах устройств, возвращаемых функцией BeginPaint или CreateDC, регион отсечения отсутствует, поэтому GetClipRgn всегда возвращает 0. Еще раз напоминаем — отсутствие региона отсечения означает, что выводится все содержимое системного региона. Приложение всегда должно проверять результат, полученный при вызове GetClipRgn, и действовать по ситуации, не полагаясь на один лишь манипулятор объекта региона. Например, следующий фрагмент проверяет, вернула ли функция GetClipRgn значение 0; в этом случае она удаляет объект региона и присваивает его манипулятору значение NULL. По этому манипулятору, равному NULL, приложение может узнать, присутствует ли в контексте устройства регион отсечения. HRGN hRgn = CreateRectRgrUO. 0. 1, 1); if ( GetClipRgnChDC. hRgn)==0) { DeleteObjectChRgn); hRgn - NULL; } Как упоминалось выше, регион представляет собой множество точек. Следовательно, операции с регионами легко моделируются на основе операций с множествами. В табл. 7.1 приведена сводка таких операций, поддерживаемых в GDI.
Отсечение 395 Таблица 7.1. Бинарные операции с регионами Режим Результат RGN_AND Регион, соответствующей области перекрытия регионов 1 и 2 RGNC0PY Копия региона 1 RGNDIFF Регион, точки которого принадлежат региону 1, но не принадлежат региону 2 RGN0R Регион, точки которого принадлежат хотя бы одному из регионов 1 и 2 RGN_X0R Регион, точки которого принадлежат либо региону 1, либо региону 2, но не одновременно Когда объект региона выбирается в качестве региона отсечения или метаре- гиона в контексте устройства, предполагается, что он определен в системе координат устройства этого контекста. В этом отношении функции регионов отличаются от функций GDI, которым обычно передаются логические координаты контекста устройства. Для преобразования координат из логической системы в систему координат устройства можно воспользоваться функцией GDI LPtoDP. Кроме того, вы должны хорошо разбираться в пустых и абсолютных регионах. Пустой регион не содержит ни одной точки, поэтому функция CreateRectRgnCO, О, О, 0) создает пустой регион. Абсолютный регион содержит все точки координатного пространства. Впрочем, попытка передать функции CreateRectRgn минимальные и максимальные 32-разрядные числа завершается неудачей. Похоже, регион максимального размера создается при следующих параметрах: {-0x7FFFFFF, -0x7FFFFFF. 0x7FFFFFF, 0x7FFFFFF} Несомненно, это связано с тем, что графический механизм использует в системе координат устройства числа с фиксированной точкой в формате 28.4, содержащие 28-разрядную целую часть со знаком. Впрочем, для практических целей можно сгенерировать «абсолютный» регион по размерам поверхности физического устройства в пикселах. Функция ExtSelectClipRegion позволяет лучше управлять процессом объединения региона hrgn с существующим регионом отсечения в контексте устройства для получения нового региона отсечения с использованием операций, перечисленных в табл. 7.1. В этом случае первый операнд является текущим регионом отсечения контекста устройства, а второй операнд задается параметром hrgn. Для функции ExtSelectClipRegion режим RGN_C0PY назначает текущим регионом отсечения копию hrgn, как и для функции SelectClipRegion. Выше уже упоминалось о том, что в только что созданных контекстах устройств, возвращаемых функциями BeginPaint и GetDC, регион отсечения отсутствует; как же в этом случае работает функция ExtSelectClipRegion? При вызове ExtSelectClipRegion для контекстов устройств без региона отсечения RGN_AND интерпретируется как RGN_C0PY. Для RGNJDIFF, RGNJJR или RGNX0R используется размер физического устройства. Рассмотрим следующий фрагмент: PAINTSTRUCT ps; HDC hDC = BeginPaint(hWnd. & ps);
396 Глава 7. Пикселы HRGN hRgn = CreateRectRgnCO. 0. 200. 200); int rslt = ExtSelectClip(hDC. hRgn. RGN_DIFF); rslt = GetClipRgnChDC. hRgn); Этот фрагмент создает прямоугольный регион 200 х 200 и пытается изменить текущий регион отсечения с помощью операции RGNDIFF. В контексте устройства отсутствует регион отсечения, поэтому в экранном режиме 1152 х 864 графический механизм использует прямоугольный регион {0,0,1152,864}, а функция GetClipRgn возвращает регион, состоящий из двух прямоугольников {200,0,1152,200} и {0,200,1152,864}. Следующие три функции для работы с регионами отсечения просты. Для контекста устройства, обладающего регионом отсечения, функция OffsetClipRgn смещает все точки объекта на величину (nXOffset, nYOffset). Функция Exclude- ClipRgn удаляет прямоугольник из текущего региона отсечения по аналогии с режимом RGNDIFF функции ExtSelectClip. Функция IntersectClipRect вычисляет пересечение текущего региона отсечения с прямоугольником по аналогии с режимом RGN_AND функции ExtSelectClip. По сравнению с ExtSelectClip функции ExcludedipRect и IntersectClipRect предоставляют более простой способ модификации региона отсечения. Функция GetClipBox возвращает наименьший ограничивающий прямоугольник для пересечения текущего системного региона и региона отсечения. Будьте внимательны: речь идет именно о пересечении этих двух регионов! По умолчанию в контексте устройства нет региона отсечения, поэтому GetClipBox возвращает ограничивающий прямоугольник системного региона, совпадающий с прямоугольником rcPaint в структуре PAINTSTRUCT, заполняемой функцией BeginPaint. По мере построения региона отсечения вызовами SelectClipRgn и ExtSelectClipRgn механизм GDI отслеживает его пересечение с системным регионом и его ограничивающий прямоугольник, который и возвращается функцией GetClipBox. Если в процессе обработки сообщения WMPAINT приложение изменяет регион отсечения, вызов GetClipBox дает более точную информацию, чем прямоугольник rcPaint. Метарегион Метарегионы относятся к числу практически не документированных возможностей GDI. Они не упоминаются среди атрибутов контекста устройства, для них не указывается значение по умолчанию и не объясняется связь с системным регионом и регионом отсечения. В основе дальнейшего материала лежат самостоятельные исследования автора. Метарегион представляет собой «регион отсечения первого уровня», управляющий отсечением на другом уровне. Вспомним принцип отсечения в GDI: в контексте устройства вывод ограничивается областью пересечения системного региона, метарегиона и региона отсечения. Все, что лежит за пределами этой области, отсекается. Если выясняется, что работать с одним уровнем отсечения на уровне приложения слишком неудобно, в вашем распоряжении оказывается второй уровень (по аналогии с двумя уровнями логических систем координат GDI). Если вам хватает одного уровня отсечения, определяемого приложением, вы можете забыть о метарегионах.
Отсечение 397 В только что созданном контексте устройства метарегион отсутствует. Даже после выбора региона отсечения метарегион все равно не существует до тех пор, пока не будет вызвана функция SetMetaRgn. Ниже перечислены функции API для работы с метарегионами. int SetMetaRgn(HDC hDC): int GetMetaRgn(HDC hDC, HRGN hRgn); В отличие от других функций с префиксом Set, функция SetMetaRgn получает всего один параметр — манипулятор контекста устройства. Другим, неявным параметром является текущий регион отсечения. Функция SetMetaRgn заменяет текущий метарегион и его пересечение с текущим регионом отсечения, а затем сбрасывает контекст устройства в состояние, при котором у него отсутствует регион отсечения. Поскольку метарегион отсекает графические примитивы так же, как и регион отсечения, непосредственно после вызова SetMetaRgn общее отсечение в контексте устройства не изменяется. Но теперь, когда приложение переместило старый регион отсечения на уровень метарегиона, оно может построить новый регион отсечения, который обеспечит дополнительные ограничения при выводе. Функция GetMetaRgn работает вполне нормально; она (по аналогии с GetClipRgn) возвращает данные текущего метарегиона через манипулятор существующего региона. В только что созданном контексте устройства нет региона отсечения, поэтому GetMetaRgn в этом случае возвращает 0, не обновляя hRgn. Интересно заметить, что при многократном вызове SetMetaRgn метарегион контекста только уменьшается и никогда не увеличивается в размерах, причем после определения метарегион уже невозможно сбросить в состояние NULL- региона. Одним из обходных путей является использование функций SaveDC и RestoreDC. Рассмотрим пример использования метарегиона. Следующий фрагмент создает метарегион и регион отсечения с размерами 100 х 100, но со смещением 50 х 50, поэтому весь вывод ограничивается областью 50 х 50. HRGN hRgn - CreateRectRgn(0, 0, 100. 100); SelectClipRgn(hDC. hRgn): // Мета: нет. регион отсечения: 100x100 SetMetaRgn(hDC); // Мета: 100x100. регион отсечения: нет SelectClipRgn(hDC. hRgn): // Мета: 100x100. регион отсечения: совпадает OffsetClipRgn(hDC. 50. 50); // Мета: 100x100. регион отсечения: 100x100 Rectangle(0. 0. 150, 150); // Рисует прямоугольник 50x50 DeleteObject(hRgn); Вероятно, вы уже поняли, что метарегионы не относятся к числу обязательных возможностей. Если приложение управляет всем отсечением на одном уровне, оно может легко имитировать метарегионы и даже что-нибудь посложнее. Но если в приложении используется многоуровневая схема вывода, то метарегион позволяет управлять отсечением в двух местах. Допустим, приложение осуществляет вывод при помощи библиотеки DLL, разработанной независимой фирмой, и в коде вывода используется регион отсечения GDI. Приложение не сможет изменить чужой исходный текст, чтобы ограничить вывод определенной областью, но оно может установить метарегион и добиться того же эффекта. Существование малоизвестных возможностей Win32 API, к числу которых принадлежат и метарегионы, всегда объясняется практическими причинами. Метарегионы используются GDI при воспроизведении метафайлов.
398 Глава 7. Пикселы Пять регионов контекста устройства Итак, у нас имеется системный регион, метарегион и регион отсечения в контексте устройства. Их пересечение фактически и определяет ту область, в которой происходит вывод. Системный регион находится под управлением диспетчера окон; метарегион и регион отсечения контролируются пользовательским приложением. Если бы для каждого графического вызова GDI приходилось заново вычислять пересечение и передавать его драйверу устройства, работа графического механизма была бы крайне неэффективной. Как нетрудно предположить, в контексте устройства содержатся еще два региона, повышающих быстродействие вывода: регион API и регион Рао. Регион API представляет собой пересечение метарегиона с регионом отсечения. Конечно, название связано с тем, что этот регион находится под управлением GDI API. Регион Рао является пересечением региона API с системным регионом. Он был назван по имени программиста Microsoft, который предложил хранить этот регион в контексте устройства. При изменении метарегиона или региона отсечения система пересчитывает заново регион API и регион Рао. Регионы хранятся в контексте устройства в виде указателей на объекты ядра, а не в виде манипуляторов. Становится понятно, почему функция SetClipRgn создает копию региона вместо того, чтобы использовать манипулятор GDI, а функции GetClipRgn в качестве параметра должен передаваться действительный манипулятор региона. Из этих пяти регионов данные системного региона, метарегиона, региона отсечения и региона API могут быть получены вызовом одной функции API GetRandomRgn. Вы когда-нибудь задумывались, почему эта функция называется GetRandomRgn1? Какую пользу способен принести случайный регаон? Функция GetRandomRgn предоставляет произвольный доступ к четырем регионам, хранящимся в контексте устройства. В последнем параметре GetRandomRgn передается целочисленный индекс, для которого документировано всего одно значение SYSRGN (4). Другие приемлемые значения: #define CLIPRGN 1 // GetClipRgn #define METARGN 2 // GetMetaRgn #define APIRGN 3 #define SYSRGN 4 При помощи функции GetRandomRgn приложение может получить данные региона отсечения, метарегиона, региона API и системного региона. Регион Рао нетрудно вычислить по данным региона API и системного региона. Наглядное представление регионов в контексте устройства В разделе «Пример программы: графический вывод в контексте устройства» главы 5 мы создали программу для наглядного представления сообщений прорисовки окна и системного региона. Если вам кажется, что подобные програм- 1 То есть «Получить произвольный регион», однако возможен и другой перевод — «получить случайный регион». — Примеч. перев.
Отсечение 399 мы написаны «для чайников» и профессионалам не годятся, в этом разделе мы напишем новую программу ClipRegion, обеспечивающую наглядное представление региона отсечения, метарегиона и региона API вместе с системным регионом. Прежде всего нам понадобится функция для получения всех четырех регионов и вывода информации о них в текстовом окне. Функция DumpRegions приведена ниже. void KMyCanvas::DumpRegions(HDC hDC) { for (int i-1: i<-4: i++) { m_bValid[i] « false; int rslt - GetRandomRgn(hDC, m_hRandomRgn[i]. i); switch ( rslt ) { case 1: m_bValid[i] - true; mJjDg.DumpRegion("RandomRgn(fcd)\ m_hRandomRgn[i]. false, i); break; case -1: m_Log.Log("RandomRgn(*d) Error\r\n". i); break; case 0: m_Log.Log("RandomRgn($d) no region\r\n". i); break; default: m_Log.Log("Unexpected\r\n"); } } } Функция вызывает GetRandomRgn для получения информации о регионе отсечения, метарегионе, регионе API и системном регионе контекста устройства и проверяет возвращаемое значение. Данные каждого региона выводятся в текстовом окне при помощи класса KLogWindow. Манипуляторы регионов сохраняются в переменных класса для последующего использования функцией DrawRegions. void KMyCanvas::DrawRegions(HDC hDC) { HBRUSH hBrush; SetBkMode(hDC. TRANSPARENT); if ( m_bValid[l] ) // Регион отсечения { hBrush - CreateHatchBrush(HS_VERTICAL. RGB(0xFF. 0. 0)); FillRgnChDC, m_hRandomRgn[l]. hBrush); DeleteObject(hBrush); }
400 Глава 7. Пикселы if ( m_bValid[2] ) // Метарегион { hBrush « CreateHatchBrush(HS_HORIZONTAL. RGB(0, OxFF. 0)); FillRgnChDC, m_hRandomRgn[2]. hBrush); DeleteObject(hBrush); } } } Функция DrawRegions вызывается после возврата из EndPaint. Она использует новый контекст устройства, возвращаемый функцией GetDC, и поэтому может рисовать во всей клиентской области, а не только в системном регионе. При выводе региона отсечения и метарегиона используются разные штриховые кисти. Регион API должен представлять собой пересечение этих двух регионов. Мы знаем, что в только что созданном контексте региона отсечения, метарегиона и региона API быть не должно, поэтому для получения осмысленных результатов необходимо подготовить эксперимент при помощи функции TestClipMeta, приведенной ниже. В программе ClipRegion определяются четыре режима, выбираемые в главном меню. Первый режим не устанавливает региона отсечения и метарегиона, поэтому вы можете увидеть ситуацию по умолчанию. Во втором режиме устанавливается регион отсечения, в третьем — метарегион, а в четвертом — регион отсечения вместе с метарегионом. В качестве региона отсечения используется эллиптический регион, находящийся в левых трех четвертях клиентской области. Метарегион также имеет форму эллипса и находится в верхних трех четвертях клиентской области. void KMyCanvas::TestC1ipMeta(HDC hDC. const RECT & rect) { HRGN hRgn; switch ( m_test ) { case IDM_TEST_DEFAULT: break; case IDM_TEST_SETCLIP: hRgn = CreateEllipticRgnCO. 0. rect.right*3/4. rect.bottom); SelectClipRgn(hDC. hRgn); DeleteObject(hRgn); break; case IDM_TEST_SETMETA: hRgn = CreateEl1ipticRgn(0. 0, rect.right. rect.bottom*3/4); SelectClipRgn(hDC. hRgn): SetMetaRgn(hDC); break; case IDM_TEST_SETMETACLIP; hRgn = CreateEllipticRgnCO, 0, rect.right. rect.bottom*3/4); SelectC1ipRgn(hDC. hRgn);
Отсечение 401 SetMetaRgn(hDC); DeleteObject(hRgn); hRgn = CreateEllipticRgnCO, 0. rect.right*3/4. rect.bottom): SelectClipRgn(hDC. hRgn); break; } Del eteObject(hRgn); // При установке метарегиона и региона отсечения // вывод происходит только в пересечении системного региона // с метарегионом и регионом отсечения HBRUSH hBrush « CreateSolidBrush(RGB(0. 0, OxFF)); FillRectChDC. & rect. hBrush); DeleteObject(hBrush); DumpRegions(hDC); } Функция TestClipMeta вызывается главной функцией вывода KMyCanvas: :0nDraw после вывода системного региона. Таким образом, после установки региона отсечения и метарегиона при выводе учитываются все три региона. Программа пытается закрасить всю клиентскую область однородной синей кистью. Если наши выкладки верны, закрашено будет только пересечение системного региона, региона отсечения и метарегиона, а все остальное отсекается. На рис. 7.2 показано, как выглядит окно программы при одновременной установке региона отсечения и метарегиона. Рис. 7.2. Регионы в контексте устройства
402 Глава 7. Пикселы Прямоугольник рамки окна изображает системный регион. Вертикальными линиями закрашивается регион отсечения, а горизонтальными — метарегион. Регион API закрашен сеткой из линий, а область сплошной закраски обозначает пересечение регионов (то есть область вывода). Если провести все четыре опыта и просмотреть содержимое окна выходных данных, можно получить довольно интересные результаты. Пример: // IDMJESTJDEFAULT RandomRgn(l) no region RandomRgn(2) no region RandomRgnO) no region RandomRgn(4) SIMPLEREGION RgnBox«[464, 247, 922. 590) 1 rects // IDMJEST_SETCLIP RandomRgn(l) C0MPLEXREGI0N RgnBox=[0. 0. 342. 342) 201 rects RandomRgn(2) no region RandomRgn(3) C0MPLEXREGI0N RgnBox-[0. 0. 342. 342) 201 rects RandomRgn(4) SIMPLEREGION RgnBox«[464. 247. 922. 590) 1 rects // IDMJESTMETA RandomRgn(l) no region RandomRgn(2) COMPLEXREGION RgnBox=[0, 0. 457. 256) 189 rects RandomRgn(3) COMPLEXREGION RgnBox=[0. 0. 457. 256) 189 rects RandomRgn(4) SIMPLEREGION RgnBox=[464. 247. 922. 590) 1 rects // IDMJESTMETACLIP RandomRgn(l) COMPLEXREGION RgnBox=[0. 0. 342. 342) 201 rects RandomRgn(2) COMPLEXREGION RgnBox=[0. 0. 457. 256) 189 rects RandomRgn(3) COMPLEXREGION RgnBox=[2. 2. 342. 256) 191 rects RandomRgn(4) SIMPLEREGION RgnBox=[464. 247. 922. 590) 1 rects В протоколе приведены значения по умолчанию для трех регионов. Системный регион (RandomRgn[4]) обеспечивает независимое отсечение; пересечение с ним региона отсечения и метарегиона образует регион API (RandomRgn[3]). Чтобы сгенерировать более интересный системный регион, расположите поверх главного окна программы ClipRegion какое-нибудь маленькое окно, а затем отодвиньте его в сторону. При этом генерируется сообщение WM_PAINT для перерисовки вновь открывшейся области, в результате чего может возникнуть сложный системный регион. Цвет Цвет возникает в наших глазах как восприятие света, отраженного объектами. Чтобы использовать цвета при программировании компьютерной графики, мы должны уметь описывать их в числовой форме, легко реализуемой на обычном компьютерном оборудовании. Кроме того, эти описания должны быть как-то связаны с нормальными представлениями о цветах, доступными для человека. Цвет обычно описывается несколькими атрибутами, принимающими значения из определенных интервалов. Эти атрибуты можно рассматривать как координаты некоторого пространства, где каждый цвет представлен отдельной точ-
Цвет 403 кой. Такое координатное пространство для описания цветов называется цветовым пространством (color space). В компьютерной графике используются десятки всевозможных цветовых пространств. Экраны мониторов обычно используют цветовое пространство RGB с тремя основными цветами — красным, зеленым и синим. На цветных принтерах чаще используется цветовое пространство CMYK, в котором каждый цвет является комбинацией голубой, малиновой, желтой и черной составляющей. Художники предпочитают описывать цвета в терминах оттенка, насыщенности и яркости. Наиболее распространенные цветовые пространства рассматриваются в следующих подразделах. Цветовое пространство RGB В графической системе Windows для описания цветов обычно используется цветовое пространство RGB. Система координат в этом пространстве состоит из трех осей: красной, зеленой и синей составляющей. Каждый цвет является точкой этого трехмерного пространства и описывается триплетом (красный, зеленый, синий). В литературе и в описании алгоритмов компьютерной графики для упрощения математических операций обычно используются нормализованные компоненты, представленные вещественными числами в интервале от 0 до 1. Однако интерфейсы графического программирования (такие, как GDI) должны быть практичными и эффективными, поэтому цвета в них представляются дискретными величинами, удобными для компьютерного хранения и обработки. В Windows API каждая цветовая составляющая представляется одним байтом, что позволяет использовать до 256 разных уровней интенсивности (0-255). Таким образом, цвет в RGB-пространстве Windows представляется тремя байтами (24 битами); получается 224 комбинаций, или 16,7 миллиона возможных цветов. Цветовое пространство RGB обладает свойством аддитивности. Начало координат (0,0,0) соответствует черному цвету. Прибавление к нему полной красной составляющей дает красный цвет (255,0,0), прибавление полной зеленой составляющей превращает его в желтый (255,255,0) и, наконец, прибавление полной синей составляющей дает белый цвет (255,255,255). В GDI существует несколько макросов для объединения трех составляющих RGB в одно 32-разрядное значение типа C0L0RREF и для разделения данных C0L0RREF на составляющие RGB. Эти макросы можно представить в виде следующих подставляемых (inline) функций: C0L0RREF RGBCBYTE ByRed, BYTE byGreen, BYTE byBlue); BYTE GetRValue(COLORREF rgb); BYTE GetGValue(C0L0RREF rgb); BYTE GetBValue(C0L0RREF rgb): Ниже перечислены некоторые удобные определения для часто используемых цветов: const C0L0RREF black = RGB( 0. 0. 0); const C0L0RREF darkred = RGB(0x80. 0, 0); const C0L0RREF darkgreen - RGB( 0.0x80. 0); const C0L0RREF darkyellow - RGB(0x80.0x80. 0); const COLORREF darkblue - RGB( 0. 0,0x80); const COLORREF darkmagenta - RGB(0x80. 0.0x80):
404 Глава 7. Пикселы const COLORREF darkcyan const COLORREF darkgray const COLORREF moneygreen const COLORREF skyblue const COLORREF cream const COLORREF mediumgray const COLORREF lightgray const COLORREF red const COLORREF green const COLORREF yellow const COLORREF blue const COLORREF magenta const COLORREF cyan const COLORREF white - RGB( 0.0x80.0x80); - RGB(0x80.0x80.0x80); = RGB(OxCO.OxDC.OxCO) - RGB(0xA6.0xCA.0xF0) - RGB(0xFF.0xFB.0xF0) - RGB(0xA0.0xA0.0xA4) - RGB(0xC0.0xC0.0xC0) - RGBCOxFF. 0. 0) = RGB( O.OxFF. 0) - RGBCOxFF.OxFF. 0) - RGB( 0. O.OxFF) - RGBCOxFF. O.OxFF) - RGB( O.OxFF.OxFF) = RGBCOxFF,OxFF.OxFF) В GDI API организовано аппаратно-независимое использование значений в формате RGB. Обычно приложение не занимается преобразованием цветов перед их сохранением в памяти видеоадаптера — эта задача решается драйвером экрана. В некоторых режимах пользовательское приложение управляет содержимым системной палитры для улучшения качества изображения. Системная палитра рассматривается вместе с растрами в одной из последующих глав книги. Для экспериментов с изменением цвета проще всего воспользоваться функцией SetPixel, изменяющей цвет одного пиксела. Функция SetPixel определяется следующим образом: COLORREF SetPixelChDC HDC. int x. int y. COLORREF crColor); Функция SetPixel выводит на поверхности один пиксел цвета crColor в точке с координатами (х, у), с учетом настройки логического координатного пространства и отсечения. Впрочем, один пиксел — это слишком тривиально, поэтому в следующем примере мы нарисуем цветовой куб RGB (то есть куб, образованный 256 уровнями красной, зеленой и синей составляющих в трехмерном пространстве). Код программы RGBCube приведен в листинге 7.1. Листинг 7.1. Вывод трехмерного куба RGB без использования мировых преобразований void RGBCube(HDC hDC) { int r, g. b; // Нарисовать и пометить оси // Красный - OxFF for (g-0: g<256; g++) for (b-0: b<256: b++) SetPixeHhDC. g. b. RGB(0xFF. g, b)); // Синий = OxFF. верхняя грань, со сдвигом for (g-0: g<256; g++) for (r-0: r<256; r+=2) SetPixel(hDC. g+128-r/2, 255+128-Г/2. RGB(r. g. OxFF));
Цвет 405 // Зеленый = 255. правая грань, for (b-0; b<256; b++) for (r=0; r<256; r+=2) SetPixeTV(hDC. 255+128-Г/2. со сдвигом b+128-r/2. RGB(r. OxFF. b)); Программа рисует три грани объемного куба, у которых красная, синяя и зеленая составляющие равны 255. Первая грань имеет прямоугольную форму, а две других выводятся со сдвигом для имитации объема. В принципе сдвиг можно было бы выполнить путем мировых преобразований, но эта задача легко решается вручную простым пропусканием половины строк развертки и небольшим смещением выводимых пикселов. В нарисованном цветном кубе видны все вершины, кроме черного начала координат. Небольшой объем вспомогательного кода обеспечивает отображение области просмотра и вывод осей. Окончательный результат показан на рис. 7.3. Синий COLORREF (0,0,255) Зеленый COLORREF (0,255,0) Красный COLORREF (255,0,0) Рис. 7.3. Программа наблюдения за объектами GDI К сожалению, на рисунке наш красивый цветной куб окрашен в оттенки серого цвета. Возникает другой вопрос — как цвет, заданный в формате RGB, преобразуется в оттенки серого? Ниже приведены простые формулы. Grayscale = (Red*30 + Green*59 + B1ue*ll + 50) / 100 Grayscale = (Red*77 + Green*151 + Blue*28 + 50) / 256 Цветовые составляющие вносят разный вклад в уровень серого цвета, и этот факт отражен в весовых коэффициентах. Чистый синий цвет выглядит достаточно темным, поэтому ему присвоен наименьший вес, за которым по возрастанию следуют веса красного и зеленого цвета. Прибавление 50 или 128 обеспечивает округление в верхнюю сторону. Если ваш компилятор или процессор плохо справляется с делением, воспользуйтесь второй формулой, чтобы компилятору хватило операции сдвига. Современные компиляторы творят настоящие чудеса в области оптимизации. Не удивляйтесь, если из вашего двоичного файла пропадают операции умножения или деления на константу — компилятор
406 Глава 7. Пикселы может заменить их более быстрыми инструкциями. Из тех же соображений при написании оптимизирующего ассемблерного кода не следует использовать инструкции умножения на такие константы, как 3 (например, при вычислении 24- разрядных адресов). Компилятор лучше справится с этой задачей, заменяя умножение фиксированным числом сложений. Цветовое пространство HLS Хотя цветовое пространство RGB хорошо подходит для хранения и обработки данных при программировании компьютерной графики, оно плохо соответствует нашему восприятию цветов. В цветовом пространстве HLS цвета описываются оттенком (hue, H), насыщенностью (saturation, S) и яркостью (lightness, L). Эти характеристики гораздо лучше соответствуют нашим представлениям о цветах. Цветовое пространство HLS можно рассматривать как результат поворота цветового куба RGB. Давайте развернем цветовой куб RGB в трехмерном пространстве так, чтобы белый угол находился в верхней точке, а черный угол — в нижней точке. Если смотреть вдоль линии, проходящей от белого угла (255,255,255) к черному углу (0,0,0), вы увидите шесть углов: красный, желтый, зеленый, голубой, синий и малиновый; все остальные цвета расположены между ними. Компонент оттенка в пространстве HLS измеряется в угловых величинах от 0 до 360 градусов; 0 соответствует красному цвету, 60 — желтому, 120 — зеленому, 180 — голубому, 240 — синему, 300 — малиновому, а 360 — снова красному. Оттенок определяет угловое смещение цвета относительно красного угла куба RGB при взгляде вдоль диагонали от белого угла к черному. Яркость определяет относительную высоту точки в развернутом кубе; 1 соответствует белому цвету, а 0 — черному. Насыщенность определяет расстояние цветовой точки от диагонали, проведенной от белого угла к черному. Функция, приведенная в листинге 7.1, рисовала трехмерный куб RGB без обращения к мировым преобразованиям GDI. В листинге 7.2 показано, как использовать мировые преобразования для отображения каждой из трех граней в соответствующую треть шестиугольника HLS. Помимо всего прочего, этот фрагмент призван проиллюстрировать технику мировых преобразований. Листинг 7.2. Вывод развернутого куба RGB в виде сверху void ColorRectCHDC hDC. C0L0RREF cO. C0L0RREF dx, C0L0RREF dy) { for (int x=0; x<256; x++) for (int y=0: y<256; y++) SetPixeKhDC. x, y. cO + x * dx + у * dy): MoveToEx(hDC. 0. 0. NULL); LineTo(hDC. 0. 255); LineTo(hDC. 255. 255); MoveToExChDC. 0. 0, NULL); LineTo(hDC. 255. 0); LineToChDC. 255. 255); // LineToChDC. 0. 0): } }
Цвет 407 void RGBCube2HLSHexagon(HDC hDC) { KAffine affine; SetGraphicsMode(hDC. GM_ADVANCED); FLOAT г = 254; // Четное число number < 255 FLOAT x = г / 2; // cos(60); FLOAT у - (FLOAT) (r * 1.732/2); // sin(60); // Задать положение центра шестиугольника с небольшими полями SetViewportOrgExChDC. (int)r + 40. (int)y + 40. NULL); // Красный - 255 affine.MapTriCO.O. 255.0. 0.255. г.О. х.у. х.-у); SetWorldTransformChDC. & affine.m_xm); ColorRect(hDC. RGB(0xFF. 0. 0). RGB(0. 1. 0). RGB(0. 0. D); // Зеленый = 255 affine.MapTriCO.O. 255.0. 0.255. -x.y. x.y. -r.O); SetWorldTransform(hDC. & affine.m_xm); ColorRecKhDC. RGB(0. OxFF. 0). RGBd. 0. 0). RGB(0. 0. I)); // Синий = 255 affine.MapTri(0.0. 255.0. 0.255. -x.-y. -r.0. x.-y); SetWorldTransformChDC. & affine.m_xm); ColorRectChDC. RGB(0. 0. OxFF). RGB(0. I. 0). RGBd. 0. 0)): } Программа рисует каждую из трех граней как прямоугольник в мировой системе координат. Прямоугольники отображаются на параллелограммы, образующие шестиугольник. Преобразование из мировых координат в страничные выполняется классом KAffine с привязкой по трем точкам. Цветовое пространство HLS изображено на рис. 7.4. Рис. 7.4. Куб RGB в направлении от белого угла к черному
408 Глава 7. Пикселы Цветовое пространство HLS образует коническую фигуру, которую иногда изображают при помощи двух шестиугольников. В центре фигуры яркость равна 0,5. В вершине фигуры яркость равна 1 (белый цвет), а в нижней точке — 0 (черный цвет). Оттенок определяется угловым расстоянием, причем в углах О, 60, 120, 180, 240 и 300 градусов расположены соответственно красный, желтый, зеленый, голубой, синий и малиновый цвета. Насыщенность определяет глубину цвета (от тусклого к интенсивному); точки с максимальной интенсивностью 1 находятся на краях шестиугольника, а точки с нулевой интенсивностью расположены в центре. Яркость 0 соответствует черному, а яркость 1 — белому цвету. В цветовом пространстве HLS оттенок обычно представляется вещественным числом из интервала [0..360], а яркость и насыщенность лежат в интервале [0..1]. В листинге 7.3 приведен класс C++ для преобразования цветов между моделями RGB и HLS. Листинг 7.3. Класс KColor: преобразование между RGB и HLS class KColor { typedef enum { Red, Green. Blue }; public: unsigned char red, green, blue; double lightness, saturation, hue; void ToHLS(void); void ToRGB(void); void KColor::ToHLS(void) { double mn, mx; int major; if ( red < green ) { mn = red; mx = green; major = Green: } else { mn = green; mx = red; major = Red; } if ( blue < mn ) mn = blue; else if ( blue > mx ) { mx - blue; major = Blue: } if ( mn==mx ) {
lightness = mn/255: saturation = 0: hue = 0; } else { lightness » (mn+mx) / 510; if ( lightness <= 0.5 ) saturation = (mx-mn) / (mn+mx); else saturation = (mx-mn) / (510-mn-mx); switch ( major ) { case Red : hue = (green-blue) * 60 / (mx-mn) + 360; break; case Green; hue = (blue-red) * 60 / (mx-mn) + 120; break; case Blue : hue = (red-green) * 60 / (mx-mn) + 240: } if (hue >= 360) hue = hue - 360: } } unsigned char Value(double ml. double m2. double h) { if (h >= 360) h -= 360; else if (h < 0) h +- 360; if (h < 60) ml = ml + (m2 - ml) * h / 60; else if (h < 180) ml = m2: else if (h < 240) ml = ml + (m2 - ml) * (240 - h) / 60; return (unsigned char)(ml * 255): } void KColor::ToRGB(void) { if (saturation == 0) { red = green = blue = (unsigned char) (lightness*255); } else { double ml. m2; if ( lightness <= 0.5 )
410 Глава 7. Пикселы Листинг 7.3. Продолжение m2 - lightness + lightness * saturation; else m2 - lightness + saturation - lightness * saturation; ml - 2 * lightness - m2; red - ValueCml, m2. hue + 120); green - ValueCml, m2. hue); blue - ValueCml, m2. hue - 120): } } Цветовое пространство HLS часто используется для выбора цвета. Например, в стандартном диалоговом окне выбора цвета в ОС Windows цветовая модель HLS управляет выбором цвета. Плоскость «оттенок/насыщенность» отображается в виде прямоугольника. Пользователь выбирает цвет, перемещая курсор мыши в прямоугольной области, а затем регулирует яркость цвета на отдельной полосе прокрутки. Листинг 7.4 показывает, как имитировать такое диалоговое окно средствами класса KColor. Результат иллюстрирует рис. 7.5. Рис. 7.5. Цветовая палитра модели HLS Листинг 7.4. Вывод цветовой палитры HLS void HLSColorPa1ette(HDC hDC. int scale. KColor & selection) { KColor c; for (int hue=0; hue<360; hue++) for (int sat=0: sat<=scale: sat++)
Цвет 411 { с.hue * hue; с.lightness * 0.5 ; с.saturation - ((double) sat)/scale; c.ToRGBO: SetPixeKhDC. hue. sat, RGB(c.red. c.green, c.blue)); } for (int 1-0; l<»scale; 1++) { с * selection; c.lightness - ((double)l)/scale; c.ToRGBO: for (int x=0; x<64; x++) SetPixeKhDC. scale+20+x. 1. RGB(c.red. c.green. c.blue)); } } Первая часть этой функции демонстрирует преобразование цвета из модели HLS в RGB и вывод на экран. В трехмерной модели имитируется разная освещенность объектов, при этом яркость изменяется в зависимости от расстояния и угла между объектом и источником света. Вторая часть функции показывает, как решить эту задачу в модели HLS изменением яркости при постоянном оттенке и насыщенности. Эта методика очень полезна при создании градиентных заливок, когда простого смешения цветов RGB оказывается недостаточно. Индексируемые цвета и палитры Помимо задания цветов в модели RGB, в Win32 API также поддерживается возможность их задания в виде индексов палитры — цветовой таблицы, содержащей значения RGB. У каждого контекста устройства имеется такой атрибут, как логическая палитра. Логические палитры принадлежат к числу объектов GDI, и для ссылок на них используются манипуляторы типа HPALETTE. Ниже перечислены основные функции для работы с палитрами. HPALETTE CreateHalftonePaletteCHDC hDC); COLORREF GetNearestColor(HDC hDC. COLORREF crColor); UINT GetNearestPalettelndexCHPALETTE hpal. COLORREF crColor); UINT GetPaletteEntries(HPALETTE hPal. UINT iStartlndex. UINT nEntries. LPPALETTEENTRY Ippe): UINT RealizePaletteCHDC hDC); HPALETTE SelectPaletteCHDC hDC. HPALETTE hPal. BOOL bForceBackground): Функция CreateHalftonePalette создает палитру из 256 цветов, равномерно распределенных в кубе RGB. Такая палитра позволяет отображать многоцветную графику полутоновыми методами в видеорежимах, использующих палитру. Функция GetNearestColor ищет в текущей логической палитре контекста устрой-
412 Глава 7. Пикселы ства цвет, ближайший к заданному. Функция GetNearestPalettelndex возвращает индекс в палитре цвета, ближайшего к заданному. Функция GetPaletteEntries загружает из логической палитры определения элементов из заданного интервала. Функция RealizePalette готовит системную палитру к отображению цветов из логической палитры. Функция SelectPalette присоединяет логическую палитру к контексту устройства и возвращает исходную логическую палитру. Манипулятор текущей палитры также можно получить функцией GetCurrentObject(hDC, 0BJ_PAL). Для работы с палитрой существуют следующие макросы: COLORREF PALETTEINDEXCWORD wPalettelndex): COLORREF PALETTERGBCBYTE bRed. BYTE bGreen. BYTE bBlue); Макрос PALETTEINDEX получает индекс и возвращает 32-разрядное описание элемента палитры. Когда такое описание используется в контексте устройства, оно интерпретируется как элемент логической палитры контекста. Макросу PALETTERGB, как и макросу RGB, передаются значения красной, зеленой и синей составляющих. При использовании этих макросов в контексте устройства без системной (аппаратной) палитры их возвращаемые значения интерпретируются одинаково. Но если макрос PALETTERGB используется в контексте с системной палитрой, входящие в него значения составляющих RGB позволяют найти ближайшее совпадение в логической палитре устройства, словно приложение указало индекс в палитре. Реализация PALETTERGB в виде функции может выглядеть так: COLORREF PALETTERGBCHDC hDC. BYTE bRed. BYTE bGreen. BYTE bBlue): { COLORREF rslt = RGB(bRed. bGreen. bBlue): if ( GetDeviceCaps(hDC. RASTERCAPS) & RC_PALETTE) { HPALETTE hPal - GetCurrentObjectChDC. 0BJ_PAL): int indx = GetNearestPalettelndexChPal. rslt): return PALETTEINDEX(indx): } else return rslt: } Выше уже упоминалось о том, что в каждом контексте устройства (даже в режимах High Color и True Color) имеется логическая палитра. Из всех перечисленных функций обязательное присутствие аппаратной палитры необходимо лишь для работы RealizePalette; другие функции могут свободно использоваться и в режимах, не требующих палитру. В листинге 7.5 показано, как с помощью макроса PALETTEINDEX можно отобразить все цвета в логической палитре. Листинг 7.5. Вывод содержимого логической палитры void ShowLogicalPalette(HDC hDC. bool bHalftone) { HPALETTE hPalette = (HPALETTE) GetCurrentObjectChDC. 0BJ_PAL): if ( bHalftone ) hPalette - CreateHalftonePalette(hDC);
Цвет 413 PALETTEENTRY entry[256]; int num = GetPaletteEntries(hPalette. 0. 256. entry); HPALETTE hOld = SelectPalette(hDC. hPalette, FALSE); if ( GetDeviceCapsChDC. RASTERCAPS) & RC_PALETTE ) RealizePalette(hDC); for (int j=0; j<(num+15)/16; j++) for (int i=0; i<16 for (int y=0; y<24 for (int x=0; x<24 У++) x++) SetPixeKhDC. i*25+x. j*25+y. PALETTEINDEX(j*16+i)); SelectPaletteChDC. hOld. FALSE); if ( bHalftone ) DeleteObject(hPalette); } Эта программа работает как для текущей логической палитры, так и для полутоновой палитры. Функция GetPaletteEntries возвращает количество цветов в логической палитре; по ее возвращаемым значениям также можно вывести значения составляющих RGB каждого цвета. Затем программа реализует палитру, если это необходимо, и отображает ее содержимое рядами из 16 цветов при помощи макроса PALETTEINDEX. На рис. 7.6 показано расположение 256 цветов полутоновой палитры. Рис. 7.6. Полутоновая палитра, выведенная с использованием макроса PALETTEINDEX Палитра, создаваемая по умолчанию в контексте устройства, содержит всего 20 цветов — 16 цветов старого видеоадаптера VGA и еще 4 цвета, определяю-
414 Глава 7. Пикселы щих текущую цветовую схему Windows. Конечно, этого недостаточно даже для изображения среднего качества. Полутоновая палитра состоит из 256 цветов, равномерно распределенных в кубе RGB. Но если приложение захочет изобразить закат солнца, вероятно, ему понадобится больше теплых цветов, а холодные цвета окажутся лишними. Win32 содержит функции, позволяющие приложениям определять собственные палитры и управлять их взаимодействием с системной палитрой и другими приложениями системы, конкурирующими за общий ресурс системной палитры. Управление палитрой рассматривается после обсуждения обработки растров в GDI. Вероятно, область применения макросов RGB и PALETTEINDEX вам уже ясна. Макрос RGB лучше всего подходит для режимов High Color и True Color. Макрос PALETTEINDEX предназначен для режимов, требующих палитру; впрочем, он работает в режимах High Color и True Color при условии, что в контексте используется действительная логическая палитра. А что получится, если испытать макрос RGB в режиме с палитрой? Ничего хорошего. Слева на рис. 7.7 наш красивый RGB-куб изображен в 256-цветном режиме, причем результат не зависит от выбора в контексте устройства полутоновой палитры. Рис. 7.7. Цветовой куб RGB, выведенный в 256-цветном режиме с полутоновой палитрой (слева использован макрос RGB, справа — макрос PALETTERGB) Весьма своеобразный трехмерный объект, не правда ли? Однако это совсем не то, что требовалось. Для вывода куба, который на самом деле состоит из 3 х 256 х 256 разных цветов, используется всего 9 цветов! Чтобы улучшить качество изображения, необходимо создать, выбрать и реализовать в контексте устройства полутоновую палитру (см. листинг 7.5). Есть и другой, не менее важный аспект — заменить макрос RGB макросом PALETTERGB. В правой части рис. 7.7 видны волшебные последствия такой замены. Из рисунка видно, что куб, выведенный при помощи макроса PALETTERGB, не обладает идеальной симметрией. Это объясняется неравномерностью распределения цветов полутоновой палитры. Но даже улучшенный вариант по сравнению с версией для режима True Color смотрится весьма уродливо. Дело в том, что при выводе куба каждый пиксел
Вывод пикселов 415 выводится независимо от других, без полутоновой обработки всей поверхности. Чтобы улучшить результат без написания собственного алгоритма полутонирования, следует сохранить пикселы в 24-разрядном растре и воспользоваться командами вывода растров с полутоновой поддержкой. Нетривиальные возможности Даже после чтения всего десятка страниц можно уверенно сказать, что работа с цветом — непростая тема. В Win32 API предусмотрены дополнительные средства создания логических палитр и операции с системной палитрой, которые будут рассматриваться ниже в этой книге. Microsoft также предоставляет в ваше распоряжение специальный интерфейс API управления цветом — ICM 2.0, но эта тема выходит за рамки GDI. Полное описание возможностей ICM 2.0 в книге не приводится, хотя отображение и регулировка цветов будут дополнительно рассматриваться при подробном описании палитр в главе 13. Windows GDI поддерживает две разновидности цветовых пространств: цветовое пространство RGB и пространство индексов палитры, соответствующее базовым возможностям видеоадаптера. Поддерживаемый современными видеоадаптерами альфа-канал не является самостоятельным компонентом цветового пространства GDI. Он поддерживается только в DirectX и в новой функции GDI AlphaBlending. На рис. 7.8 показано, как 32-разрядная величина C0L0RREF представляется в форматах RGB, PALETTERGB и PALETTEINDEX. В GDI эти форматы различаются по первому байту 32-разрядного числа. 0 Red Green Blue RGB(Red, Green, Blue) 1 0 index PALETTEINDEX(index) 2 Red Green Blue PALETTERGB(Red, Green, Blue) | | | I | 32 бита 24 16 8 0 Рис. 7.8. Три способа задания цветов в GDI Вывод пикселов Функции вывода пикселов Win32 неоднократно встречались в этом разделе. После изложения теоретических обоснований пришло время для более точного и формального описания этих функций. В Win32 API предусмотрены следующие функции для работы с пикселами:
416 Глава 7. Пикселы COLORREF GetPixel (HDC hDC. int X. int Y); COLORREF SetPixelVCHDC hDC. int X. int Y. COLORREF crColor); COLORREF SetPixel (HDC hDC. int X. int Y. COLORREF crColor); В параметре hDC передается манипулятор контекста устройства. Прежде всего следует помнить, что не все устройства поддерживают работу с пикселами, а выражаясь точнее — не все драйверы устройств поддерживают непосредственные операции с пикселами. На уровне DDI не существует функции, которая бы обеспечивала вывод отдельных пикселов. Вместо этого GDI преобразует команды вывода пикселов в команды DDI, выполняющие блиттинг растров. Следовательно, в сомнительных случаях приложение должно проверить значение Get- DeviceCapsChDC, RASTERCAPS)&RC_BITBLT и узнать, поддерживается ли устройством блиттинг растров, частным случаем которого является вывод отдельного пиксела. Параметры (X,Y) определяют позицию пиксела в логической системе координат — мировой для расширенного графического режима или страничной для совместимого графического режима. Перед определением окончательной позиции пиксела координаты проходят мировое преобразование, отображение окна в область просмотра и отображение координат устройства в физические координаты. Непосредственный вывод пиксела также зависит от того, входит ли пиксел в фактическую область отсечения контекста устройства, также называемую регионом Рао. Границы региона Рао определяются пересечением системного региона, метарегиона и региона отсечения данного контекста. Если точка находится за пределами фактической области отсечения, возвращается код ошибки (CLRJNVALID, то есть OxFFFFFFFF, или FALSE для SetPixelV): Параметр crColor функций SetPixel и SetPixelV может существовать в трех разных формах. В нем может передаваться результат, возвращаемый макросом RGB для одного из цветов в 24-разрядном пространстве RGB. Если контекст относится к устройству без поддержки палитры (например, экрану в режиме High Color и True Color), значение RGB используется непосредственно или после небольшого усечения по размерам кадрового буфера. В противном случае графический механизм или драйвер устройства находит ближайший соответствующий цвет и связывает с пикселом индекс этого цвета в системной палитре. Если параметр crColor находится в формате PALETTEINDEX, то по логической палитре контекста находится индекс в системной палитре, который используется в качестве значения пиксела в кадровом буфере. Если параметр crColor находится в формате PALETTERGB, то для устройства без палитры результат будет тем же, как если бы параметр хранился в формате RGB; в противном случае в текущей логической палитре ищется ближайший цвет и пикселу присваивается результат поиска. Обратите внимание: в контекстах устройств с палитрой макросы RGB и PALETTERGB могут приводить к разным результатам. В документации Microsoft отсутствует четкое описание того, как цветовое значение в формате RGB преобразуется в индекс палитры, но, похоже, при этом используется палитра из 20 системных статических цветов. Цветовое значение, заданное при помощи макроса PALETTERGB, ищет совпадение в логической палитре контекста устройства, из которой можно выбрать гораздо больше цветов. Функции SetPixel и SetPixelV отличаются типом возвращаемого значения. Функция SetPixelV возвращает логическую величину — признак успешного за-
Вывод пикселов 417 вершения операции, а функция SetPixel возвращает реально использованный цвет. Функция GetPixel возвращает цветовое значение пиксела с заданными координатами. Следует помнить, что функции SetPixel и GetPixel возвращают результаты в формате RGB, а не в формате PALETTE INDEX или PALETTERGB, даже в контекстах устройств с поддержкой палитры. Это может вызвать проблемы в контекстах с палитрой. Например, приведенная ниже функция копирует пикселы в новую позицию. Если применить ее к кубу в правой части рис. 7.7, результат будет напоминать левый куб за исключением того, что в этом случае используется только 20 цветов. void CopyPixeKHDC hDC. int xO. int yO. int xl. int yl) { SetPixel(hDC. xl. yl. GetPixel(hDC. xl. yl)); } Чтобы эта функция нормально работала, последний параметр SetPixel должен иметь вид GetPixel (hDC, xl. yl)|PALETTERGBCO,0,0) или GetPixel(hDC, xl, yl)| 0x02000000. Разобраться в том, как реализованы функции вывода пикселов, особенно интересно, поскольку речь идет о самой простой графической операции. Кроме того, это поможет вам лучше понять, с какими затратами связано выполнение некоторых графических команд в GDI. В Windows NT/2000 обе функции, SetPixel и SetPixelV, обслуживаются одной и той же системной функцией _NtGdiSetPixel@16, вызываемой после проверки параметров по манипулятору контекста устройства. Имя _NtGdiSetPixel@16 означает, что при вызове функции передаются четыре параметра. При этом инициируется программное прерывание, которое обрабатывается одноименной функцией механизма GDI режима ядра (win32k.sys). Функция ядра NtGdiSetPixel блокирует контекст устройства, отображает логические координаты в физические, выполняет простую проверку границ, при необходимости преобразует C0L0RREF в индекс и вызывает функцию драйвера DrvBitBlt (если она поддерживается) или функцию EngBitBlt. При необходимости цветовое значение транслируется в формат RGB. Перед возвращением из функции контекст устройства разблокируется. Функция GetPixel обрабатывается системной функцией _NtGdiGetPixel@12. Эта функция создает временный растр и копирует в него пиксел вызовом DrvCopyBits/ EngCopyBits. Главное, на что необходимо обратить внимание в этой процедуре — это быстродействие. Для каждого вызова GetPixel, SetPixel или SetPixelV графическая система должна инициировать программное прерывание, переключиться в режим ядра и обратно, отобразить координаты, преобразовать индекс палитры, построить временный растр и затем вызвать функцию блиттинга драйвера устройства. Для одного пиксела объем работы получается довольно большим. В главе 1 была описана методика хронометража некоторых операций с использованием специальной инструкции процессора Pentium. Ею можно воспользоваться и для измерения быстродействия функций работы с пикселами. Некоторые результаты представлены в табл. 7.2.
418 Глава 7. Пикселы Таблица 7.2. Быстродействие функций работы с пикселами: Pentium 200 МГц Функция SetPixel(RGBO) SetPixeKPALETTERGBO) SetPixeKPALETTEINDEX) SetPixelV(RGBO) GetPixeK) Такты (256 цветов) 1850 4897 1345 1880 6362 Такты (32-разрядный цвет) 1286 1284 1295 1284 6499 Наивысшая скорость (пикселов/с) 152 881 153 374 153 115 153 115 30 251 Хронометраж показывает довольно интересные результаты. Во-первых, SetPixel и SetPixelV обладают похожим быстродействием, хотя документация Microsoft утверждает, что SetPixelV работает быстрее, поскольку ей не приходится возвращать цветовое значение. Преобразование данных RGB в индекс палитры — очень медленный процесс, на который тратится около 500 тактов, причем преобразование PALETTERGB в индекс полутоновой палитры обходится еще в 3000 тактов. Время обратного преобразования индекса палитры в RGB пренебрежимо мало, поскольку преобразование сводится к простой выборке элемента таблицы. Как ни странно, функция GetPixel работает гораздо медленнее SetPixel. В целом функции пикселов Win32 API работают очень медленно, и это вполне объяснимо, если учесть огромные затраты на обработку одного пиксела. Впрочем, если скорость от 30 до 150 тысяч пикселов в секунду вас устраивает, этими функциями можно пользоваться. Если понадобится более высокое быстродействие, операции с пикселами на растрах легко реализуются в коде C/C++ с использованием аппаратно-независимых растров или DIB-секций. В главах 10, 11 и 12 рассматриваются три разных типа растров, поддерживаемых GDI. Прямой доступ к пикселам позволяет обрабатывать миллионы пикселов в секунду. Пример: множество Мандельброта Множеством Мандельброта называется множество точек плоскости, определяемых простой итеративной формулой. Для точки (х, у) ее позиция на комплексной плоскости СО = х + yi определяет последовательность СО, С1, С2,...} Сп, где Сп+1 = Сп2 + СО. Точка (х}у) принадлежит множеству Мандельброта, если эта последовательность сходится (то есть элементы последовательности приближаются друг к другу и не уходят в бесконечность). Несмотря на простоту определения, не существует простой математической формулы, позволяющей проверить принадлежность точки (х,у) к множеству Мандельброта. Единственный способ проверки — выполнение итераций несколько сотен или даже тысяч раз. Самое интересное заключается в том, что само множество определяет количество итераций, необходимых для выяснения того, принадлежит ли точка этому множеству. Если раскрасить точки по числу необходимых итераций, получается очень затейливая и красивая картинка.
Пример: множество Мандельброта 419 Графическое представление множества Мандельброта невозможно точно описать массивом пикселов фиксированного размера. При увеличении части изображения не существует формулы, по которой можно было бы вычислить цвета открывшихся точек; вам придется снова провести итерации для нового уровня детализации. Следовательно, множество Мандельброта лучше всего представляется динамически сгенерированным массивом пикселов, хотя для ускорения вывода желательно воспользоваться растром. Вычисления занимают очень много времени, поэтому по практическим соображениям число итераций приходится ограничивать фиксированными величинами вроде 128, 1024 или 16 384. После проведения заданного количества итераций т возможно получение нескольких разных результатов. Если после п < m итераций расстояние от точки (х,у) от начала координат (0,0) больше 2, значит, последовательность уходит в бесконечность. Другой возможный вариант — если после р < m итераций выясняется, что последовательность сходится к одной фиксированной точке или перемещается между двумя, тремя, четырьмя и т. д. фиксированными точками в пределах допустимой погрешности. Третий вариант — когда после т итераций мы не можем принять обоснованного решения; элементы последовательности лежат в достаточно малом интервале, но критерий сходимости не выполняется. Мы можем раскрасить точки схождения одной последовательностью цветов в зависимости от значения п, точки расхождения — другой последовательностью цветов в зависимости от значения р, а неопределенные точки раскрасить одним фиксированным цветом. Цветовое пространство HLS хорошо подходит для построения цветовых последовательностей посредством изменения оттенка при фиксированных насыщенности и яркости или изменения яркости при фиксированных оттенке и насыщенности. На рис. 7.9 показано полное изображение множества Мандельброта после 128 итераций. На рис. 7.10 показана крошечная часть изображения после 1024 итераций с увеличением 64:1. Программа Mandelbrot создана на основе класса KScrollView, обеспечивающего базовые средства прокрутки и масштабирования. Прежде чем начинать длинные вычисления, реализация метода OnDraw запрашивает данные системного региона и проверяет, не отсекается ли текущая точка. Функция вычисления возвращает положительные числа для точек схождения, отрицательные числа для точек расхождения и 0 для неопределенных точек. Число итераций преобразуется в C0L0RREF по цветовым таблицам, после чего пиксел выводится функцией SetPixel. При рассмотрении других графических примитивов GDI будет показано, как повысить скорость вывода за счет нетривиальных графических команд. Пример программы Mandelbrot наглядно покажет, насколько хорошо вы разобрались в API режимах отображения, прокрутки, отсечения, цветовых пространств и вывода пикселов.
420 Глава 7. Пикселы Рис. 7.9. Полное множество Мандельброта (128 итераций) Рис. 7.10. Подмножество Мандельброта в увеличении 64:1 (1024 итерации)
Итоги 421 Итоги Главы 5 и 6 были посвящены контекстам устройств и координатным пространствам. В этой главе описаны другие базовые концепции, используемые в самой примитивной операции GDI — выводе отдельных пикселов. В главе 8 мы поднимемся на более высокий уровень и посмотрим, как пикселы соединяются в более интересные линии и кривые. В Windows GDI поддерживается специальный интерфейс API управления цветом — ICM (последняя версия — ICM 2.0). Описание ICM выходит за рамки этой книги. Дополнительную информацию можно найти в документации MSDN. Немало данных о цветовых пространствах и преобразованиях цветов можно найти в Интернете. Проведите поиск по таким ключевым словам, как «color space», «color-space conversion» и «color-space FAQ». Примеры программ К этой главе прилагается пять примеров программ (табл. 7.3). Таблица 7.3. Программы главы 7 Каталог проекта Описание Samples\Chapt_07\GDIObj Samples\Chapt_07\ClipRegion Samples\Chapt_07\ColorSpace Samples\Chapt_07\PixelSpeed Samples\Chapt_07\Mandelbrot Мониторинг таблицы объектов и получение информации об использовании объектов GDI процессом, позволяющей своевременно узнать о возможных утечках ресурсов Наглядное представление системного региона, ме- тарегиона и региона отсечения Демонстрация цветовых пространств RGB и HLS и цветов полутоновой палитры Хронометраж функций вывода пикселов Графическое представление множества Мандельб- рота с использованием функций вывода пикселов
Глава 8 Линии и кривые При соединении отдельных пикселов возникают линии и кривые. Следовательно, если вы умеете рисовать отдельные пикселы, рисование линий и кривых превращается в стандартную задачу из области математики и программирования. Впрочем, на практике линии и кривые могут обладать разными цветами, стилями, шириной, узором и прочими атрибутами, поэтому процедура рисования кривых бывает весьма нетривиальной. В этой главе рассматриваются некоторые концепции и средства GDI, связанные с рисованием линий и кривых, — бинарные растровые операции, режимы заполнения фона, перья, линии, кривые и траектории. Бинарные растровые операции При вызове функции SetPixel для вывода пиксела на поверхности устройства описатель цвета преобразуется в цветовой формат (физический цвет), соответствующий формату кадрового буфера, а затем значение соответствующего пиксела приемника заменяется преобразованным цветом. Если интерпретировать кадровый буфер как массив пикселов D, то операцию SetPixel можно рассматривать как присваивание D[x,y] = Р, где Р — преобразованный цвет (или физический цвет). Обобщая эту операцию, можно определить функцию /, объединяющую исходный цвет пиксела D[x,y] с цветом Р и порождающую новое цветовое значение, которое присваивается соответствующему пикселу приемника. Другими словами, D[x,y] = /(D[x,y],P) или D =/(D,P). Функция / получает два параметра, то есть является бинарной функцией. Теоретически число таких функций бесконечно, однако в GDI поддерживается лишь одна их разновидность: поразрядные логические операции. В этих операциях к битам двух аргументов, находящихся в одинаковых позициях, применяются логические операции. Для бинарных логических операций существует 16 бинарных функций (22х2). В GDI эти функции называются бинарны-
Бинарные растровые операции 423 ми растровыми операциями (binary raster operations), или сокращенно ROP2. В табл. 8.1 приведен перечень бинарных растровых операций, поддерживаемых в GDI. В данном случае буквой Р обозначается цвет пера, поскольку операции ROP2 используются для рисования линий. Таблица 8.1. Бинарные растровые операции ROP2 Формула Описание R2_BLACKPEN D = О Всегда 0, черный цвет в режиме RGB R2_N0TMERGEPEN D - ~(D | P) Инверсия R2_MERGEPEN R2J1ASKN0TPEN D = D&-P Конъюнкция приемника с инвертированным пером R2_N0TC0PYPEN D = ~Р Инверсия цвета пера R2MASKPENN0T D = P&-D Конъюнкция пера с инвертированным приемником R2_N0T D = ~D Инверсия приемника R2__X0RPEN D = DAP Приемник и перо объединяются операцией исключающего «ИЛИ» R2J0TMASKPEN D - ~(D&P) Инверсия R2J1ASKPEN R2MASKPEN D - D&P Конъюнкция приемника с пером R2J0TX0RPEN D - ~(DAP) Инверсия R2J0RPEN R2N0P D - D Приемник не изменяется R2_MERGEN0TPEN D = D|~P Дизъюнкция приемника с инвертированным пером R2_C0PYPEN D - Р Перо R2_MERGEPENN0T D - P|~D Дизъюнкция пера с инвертированным приемником R2_MERGEPEN D - P|D Конъюнкция пера с приемником R2_WHITE D = 1 Всегда 1, белый цвет в режиме RGB Контекст устройства GDI содержит атрибут, определяющий текущую операцию ROP2. Этот атрибут также называется режимом рисования (draw mode). Для получения текущего значения этого атрибута используется функция GetR0P2, а для присваивания ему нового значения — функция SetR0P2. Эти функции определяются следующим образом: int SetR0P2(HDC hDC. int fnDrawMode); int GetR0P2(HDC hDC); Функция SetR0P2 назначает в контексте устройства новую бинарную операцию (при условии передачи корректного значения) и возвращает исходный режим рисования. Функция GetR0P2 просто возвращает текущий режим рисования. По умолчанию в контексте устройства выбирается режим R2C0PYPEN, при котором пикселу приемника просто присваивается цвет пера. Режим рисования
424 Глава 8. Линии и кривые используется всюду, где используются перья, — то есть при выводе линий и кривых, а также при обводке заполненных областей. На рис. 8.1 показан эффект применения всех 16 бинарных растровых операций к 20 разноцветным полосам на экране в режиме True Color. Сначала программа рисует вертикальные полосы с применением цветов, взятых из палитры контекста устройства по умолчанию. Перед выводом каждой горизонтальной полосы происходит переключение бинарной растровой операции. Взгляните на рисунок; в режиме R2_BLACK фон закрашивается черным цветом, в режиме R2_N0T фон инвертируется, в режиме R2N0P фон не изменяется, а в режиме R2WHITE фон закрашивается белым цветом. В 256-цветном режиме цвета могут изменяться непредсказуемо, если только системная палитра не была специально подготовлена для последующего выполнения логических операций. R2_WHITE ■■■■■■■ тжжшт мм Рис. 8.1. Эффект от выполнения бинарных растровых операций (режим True Color) При использовании бинарных растровых операций следует помнить о том, что операции определяются для физических цветов, а не для логических значений C0L0RREF. Таким образом, результат операций является более или менее ап- паратно-зависимым. Для устройств, использующих цветовое пространство RGB, операции применяются к каждой из трех составляющих RGB, поэтому результат вполне предсказуем, но не всегда оправдан с точки зрения логики. В цветовой модели RGB хранятся значения интенсивности основных цветов, поэтому применение поразрядных логических операций не всегда находит соответствие в цветовом восприятии. Для устройств с палитрой растровые операции применяются к цветовым индексам, поэтому результат зависит от упорядочения цветов в палитре. В многозадачных ОС семейства Windows приложения не обладают полным контролем над аппаратной палитрой системы. В GDI существуют
Бинарные растровые операции 425 специальные функции, при помощи которых приложение вносит изменения в системную палитру, причем приоритетным правом обладают окна переднего плана. Обрабатывая специальные сообщения, приложение может реагировать на изменения в системной палитре. Палитры подробно рассматриваются в главе 13. Бинарные растровые операции играют важную роль в компьютерной графике. Режим R2BLACK используется для закраски пикселов черным цветом (0), а режим R2WHITE окрашивает пикселы в белый цвет (1, или OxFFFFFF в 24-разрядном кадровом буфере). Режим R2N0TC0PYPEN меняет цвет пера на противоположный. Режим R2N0P полностью подавляет вывод линий и кривых — это очень удобно, если вы не хотите обводить прямоугольник рамкой. Режим R2MASKPEN обеспечивает избирательное подавление битов на графической поверхности контекста устройства. Например, если режим R2MASKPEN используется для пера RGB(OxFF.O.O) в кадровом буфере RGB, при выводе линий данные синего и зеленого канала маскируются, в результате остаются только данные красного канала. При использовании цвета RGB(0x7F,0x7F,0x7F) подавляются яркие цвета, поскольку после вывода максимальная интенсивность каждого канала будет равна только 127 вместо 255. Режимы R2N0T и R2X0RPEN часто используются в интерактивной компьютерной графике для вывода перекрестий и эластичных контуров. Перекрестие состоит из горизонтальной и вертикальной линий, пересекающих весь экран. Точка пересечения этих линий определяет текущую позицию курсора. Перекрестия часто применяются при выравнивании объектов в графических редакторах. Эластичные контуры изменяются динамически и обозначают некие границы, определяемые пользователем при помощи мыши или клавиатуры. Эластичные прямоугольники и другие фигуры часто используются при построении и выделении геометрических фигур в графических пакетах. В процессе перемещения мыши построение фигуры считается еще не законченным, поэтому фиксировать фигуру нельзя. Вместо этого, когда пользователь перемещает мышь, приложение должно быстро нарисовать контур, стереть его, восстановить исходное содержимое и переместить в новую позицию. Бинарные операции R2_N0T, R2X0RPEN и R2N0TX0RPEN позволяют быстро рисовать временные линии и удалять их, не оставляя следа, поскольку при повторном применении этих операции восстанавливается исходное содержимое — одно из свойств логических операций. В листинге 8.1 показано, как реализовать перекрестие с использованием операции R2N0T. Класс окна хранит последнюю позицию курсора в переменных (m_lastx,m_lasty). Для каждого сообщения WMM0USEM0VE функция вывода перекрестия вызывается дважды — для удаления старых pi для рисования новых линий. Листинг 8.1. Вывод перекрестия с использованием R2_NOT void KMyCanvas::DrawCrossHair(HDC hDC. bool on) { if ( m_lastx<0 ) return; RECT rect; GetClientRect(m_hWnd. & rect); SetR0P2(hDC. R2 NOT); Продолжение х*>
426 Глава 8. Линии и кривые Листинг 8.1. Продолжение MoveToExChDC. rect.left. mjasty. NULL); LineToChDC. rect.right. m_lasty): MoveToExChDC. mjastx. rect.гор. NULL); LineTo(hDC. m_lastx. rect.bottom); } LRESULT KMyCanvas::WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam) { switch( uMsg ) { case WM_CREATE: mjastx = mjasty = -1; // Перекрестия еще нет return 0: case WM_M0USEM0VE; { HDC hDC = GetDC(hWnd): DrawCrossHair(hDC); mjastx = L0W0RD(IParam); mjasty = HIWORDCIParam); DrawCrossHairChDC. true): ReleaseDCChWnd. hDC); } }: Хотя каждая из операций R2N0T, R2X0RPEN и R2N0TX0RPEN может использоваться для вывода временных, легко стираемых линий, между ними существуют незначительные отличия. Операция R2N0T инвертирует биты кадрового буфера, заменяет черный цвет белым, а белый цвет — черным. Таким образом, линия всегда видна, однако контролировать ее цвет вы не можете. Операция R2X0RPEN имеет более общий характер, чем R2_N0T. Чтобы добиться того же эффекта, как и при использовании R2_N0T, достаточно определить перо, физический цвет которого содержит 1 во всех битах. Другими словами, R2_X0RPEN с белым пером работает так же, как и R2_N0T. Если вы знаете, что фон клиентской области в основном состоит из одного цвета С, вы можете воспользоваться пером цвета Р и операцией R2X0RPEN, чтобы линия в основном была окрашена в цвет САР. Растровые операции бывают не только бинарными. Для растровых изображений в Win32 GDI определяются операции с тремя и четырьмя операндами, которые называются соответственно тернарными или кватернарными. В Windows 98 и Windows 2000 появилась простейшая поддержка нелогических операций смешения на уровне пикселов посредством альфа-наложения. Все эти возможности будут рассматриваться при знакомстве с растрами. Режим заполнения фона и цвет фона Для некоторых графических примитивов GDI делит выводимые пикселы на два класса: основные (foreground) и фоновые (background). Например, при выводе текста пикселы, образующие глифы символов, считаются основными, а остальные пикселы текстовой области считаются фоновыми. При выводе пунктирных
Перья 427 линий пикселы отрезков считаются основными, а пикселы промежутков — фоновыми. Основные пикселы выводятся всегда, а вывод фоновых пикселов необязателен. В каждом контексте устройства присутствует такой атрибут, как режим заполнения фона, управляющий выводом фоновых пикселов. При выводе фоновых пикселов задействуется цвет, заданный другим атрибутом контекста устройства — цветом фона. Для работы с этими атрибутами в GDI используются следующие функции: int GetBkMode(HDC hDC): int SetBkMode(HDC hDC. iBkMode); COLORREF GetBkColor(HDC hDC); COLORREF SetBkColorCHDC hDC. COLORREF crColor); Допустимыми значениями режима заполнения фона являются константы OPAQUE (пикселы фона выводятся) и TRANSPARENT (пикселы фона игнорируются). По умолчанию в контексте устройства используется режим OPAQUE с белым цветом фона. Режим заполнения и цвет фона требуются при выводе стилевых линий, текста и рисовании штриховой кистью. Цвет фона также используется при преобразовании растров между цветным и черно-белым форматом. Перья На вывод линий влияют многочисленные атрибуты. Некоторые атрибуты, относящиеся именно к линиям, группируются в объект пера GDI, что позволяет хранить и легко ссылаться на группы параметров. Говоря точнее, объект пера в Win32 GDI содержит информацию о толщине линии или кривой, ее стиле, цвете, концах, типе соединений и узоре. Толщина пера определяет толщину нарисованных линий. Линии толщиной в один пиксел хорошо подходят для вывода на экран и являются самыми тонкими линиями, используемыми в инженерной графике. Линии с фиксированной физической толщиной нужны для того, чтобы напечатанные документы одинаково выводились на принтерах с разными разрешениями. Стиль пера определяет тип выводимой линии — однородная, точечная, пунктирная или линия с пользовательским стилем. При определении пера обычно указывается однородный цвет, которым рисуются все пикселы линии, однако Win32 GDI также позволяет выводить узорные линии (узор определяется объектом кисти). Атрибуты завершения и типа соединения описывают внешний вид обоих концов линии и точек соединения отрезков. Объект логического пера GDI позволяет создавать объекты перьев (а точнее, объекты логических перьев). Логическое перо представляет собой описание требований к перу со стороны приложения, которое может в каких-то деталях и не соответствовать тому, как линии будут выводиться на поверхности физического устройства. Драйвер графического устройства можс^т поддерживать собственные структуры данных,
428 Глава 8. Линии и кривые определяющие реализацию логического пера; такие внутренние объекты называются физическими перьями. Структура данных логического пера находится под управлением GDI вместе с остальными логическими объектами — контекстами устройств, логическими кистями, логическими шрифтами и т. д. Манипулятор созданного пера возвращается приложению и требуется для ссылок на перо при его использовании в будущем. Манипуляторы объектов GDI описываются общим типом HGDIOBJ; для манипуляторов логических перьев зарезервирован тип HPEN. При определении макроса STRICT GDI использует файлы, в которых HGDIOBJ определяется как указатель на void, a HPEN и другие специализированные типы указателей — как указатели на абсолютно разные структуры. Таким образом, типом HPEN можно заменить тип HGDIOBJ, но попытка использования HGDIOBJ вместо HPEN требует обязательного преобразования типа. Если макрос STRICT не определен, все типы манипуляторов объявляются как указатели на void, поэтому компилятор не отвечает за неправильное использование типов манипуляторов. Объект логического пера является одним из атрибутов контекста устройства. В отличие от других атрибутов (таких, как режим заполнения фона или бинарная растровая операция), для работы с этим атрибутом используются общие функции работы с объектами. HGDIOBJ GetCurrentObjectCHDC hDC. UINT uObjectType); HGDIOBJ SelectObjectCHDC hDC, HGDIOBJ hgdiobj); int GetObjectCHGDIOBJ hgdiobj. int cbBuffer, LPVOID IpvObject); int EnumObjectsCHDC hDC. int nObjectType. GOBJENUMPROC lpObjectProc. LPARAM IParam); Функция GetCurrentObject возвращает манипулятор текущего объекта GDI в контексте устройства; тип объекта определяется параметром uObjectType. Например, GetCurrentObject (hDC, 0BJPEN) возвращает манипулятор текущего объекта логического пера. Функция SelectObject заменяет манипулятор объекта GDI в контексте манипулятором нового объекта и возвращает старый манипулятор. Таким образом, если при вызове SelectObject был указан манипулятор действительного объекта логического пера, функция SelectObject изменяет значение атрибута логического пера в контексте устройства. Функция GetOb ject возвращает исходное определение объекта GDI. Функция EnumObjects вызывает заданную функцию для каждого объекта GDI, доступного для пользователей, в контексте устройства. Объект логического пера, как и другие объекты GDI, поглощает ресурсы пользовательского пространства и ресурсы ядра, а также занимает место в таблице объектов GDI. Следовательно, когда необходимость в логическом пере отпадает, его следует исключить из контекста устройства и уничтожить функцией Delete- Object. По тем же причинам приложение не должно создавать слишком большого количества объектов GDI и не должно уничтожать их лишь при выходе из приложения. В системах Win32 все процессы в системе используют общую таблицу, рассчитанную на 16 384 манипуляторов GDI. Следовательно, если приложение создает 1024 манипуляторов объектов GDI, в системе одновременно может работать не более 16 таких приложений. Впрочем, при завершении процесса операционная система удаляет все созданные им объекты GDI и освобождает все занимаемые ресурсы.
Перья 429 Стандартные перья В GDI определяются четыре стандартных объекта перьев, которые могут использоваться любыми приложениями. Чтобы получить манипулятор стандартного пера, вызовите функцию GetStockObject с индексом стандартного объекта. Например, GetStockObject (BLACKPEN) возвращает однородное черное перо толщиной в один пиксел, также назначаемое по умолчанию в контексте устройства. Вызов GetStockObject (WHITEPEN) возвращает однородное белое перо толщиной в один пиксел. GetStockObject (NULL_PEN) возвращает пустое перо, которое ничего не рисует и может использоваться для временного запрета вывода линий. Эти стандартные перья (черное, белое и пустое) существуют уже давно. В Windows 98/2000 наконец появилось новое стандартное перо — перо DC, возвращаемое вызовом GetStockObject(DC_PEN). Перо DC, или выражаясь шире — объект GDI контекста устройства, является абсолютно новой концепцией. Обычные объекты GDI «намертво» фиксируются при создании. Их можно использовать, можно удалять, но нельзя изменять. Если вам понадобился слегка отличающийся объект GDI, приходится создавать новый объект и удалять старый. При большом количестве объектов GDI это приводит к снижению быстродействия (например, при реализации градиентных заливок без прямой поддержки со стороны GDI). Перо DC принадлежит к новому типу объектов GDI и является лишь одним из частных случаев. Можно называть эти объекты объектами GDI контекста устройства, поскольку они имеют особый смысл лишь при присоединении к контексту устройства. После выбора в контексте устройства такие объекты можно до определенной степени модифицировать. Если такие изменения поддерживаются GDI, вы избавляетесь от необходимости создавать новые или заменять старые объекты. По умолчанию перо DC является однородным черным пером толщиной в один пиксел. После выбора пера DC в контексте устройства вы можете изменять только его цвет. При работе с цветом пера DC используются следующие функции: C0L0RREF GetDCPenColorCHDC hDC); C0L0RREF SetDCPenColorCHDC hDC, C0L0RREF crColor); Функция GetDCPenColor возвращает текущий цвет пера DC в контексте устройства. Функция SetDCPenColor устанавливает новый цвет пера и возвращает старый цвет пера. Эти функции могут использоваться даже в том случае, если перо DC не выбрано в контексте устройства. Цвет пера DC можно рассматривать как новый атрибут контекста устройства, требуемый для рисования линий только в том случае, если перо DC выбрано в качестве текущего объекта пера. Следующий фрагмент показывает, как нарисовать градиентную заливку всего одним пером: HGDIOBJ hOld = SelectObjectChDC. GetStockObject(DC_PEN)); for (int i=0; i<128; i++) { SetDCPenColor(hDC. RGB(i. 255-i. 128+i)): MoveToEx(hDC, 10. i+10. NULL): LineToChDC. 110. i+10): } SelectObjectChDC. hOld);
430 Глава 8. Линии и кривые После получения и выбора пера DC программа при помощи функции Set- DCPenColor постепенно изменяет цвет пера в интервале от RGB(0,255,128) до RGB( 127,128,255), создавая линейную градиентную заливку. После завершения вывода программа восстанавливает исходное перо. Без пера DC нам пришлось бы при каждой итерации создавать новое перо, выбирать его в контексте устройства и удалять старое перо. Стандартные объекты заранее создаются операционной системой pi совместно используются всеми процессами, работающими в системе. После завершения работы со стандартными объектами их манипуляторы удалять не нужно. Впрочем, вызов DeleteObject для манипулятора стандартного пера абсолютно безопасен — Del eteObject просто возвращает TRUE, не выполняя никаких действий. Простые перья Все стандартные перья имеют однородный цвет и единичную толщину. Чтобы рисовать прерывистые или более толстые линии, приложение создает нестандартные объекты логического пера. Ниже приведены две несложные функции для создания простых перьев: HPEN CreatePendnt fnPenStyle. int nWidth, COLORREF crColor): HPEN CreatePenlndirect(CONST LOGPEN * Iplgpn); Структура LOGPEN содержит три параметра логического пера, а именно его стиль, толщину и ссылку на цвет. Следовательно, эти две функции представляют собой разновидности одной и той же функции. В практической реализации CreatePenlndirect извлекает данные из структуры LOGPEN и вызывает функцию CreatePen. Стиль пера определяет порядок следования пикселов и расположение линии. В табл. 8.2 перечислены различные стили перьев и ограничения, накладываемые на их реализацию. Таблица 8.2. Простые стили перьев Стиль Вид линии Выравнивание Ограничения PS_S0LID PS_DASH PS_D0T PS_DASHDOT PS_DASHD0TD0T PS_NULL PSJNIDEFRAME Сплошная, рисуются все пикселы Пунктирная Точечная Чередование отрезков и точек Отрезок и две точки Линия не рисуется Сплошная, рисуются все пикселы По центру По центру По центру По центру По центру Нет Внутри контура Толщина <1 Толщина < 1 Толщина < 1 Толщина < 1 Толщина > 1, используется при обводке замкнутых областей
Перья 431 Одной из составляющих стиля пера является правило чередования отрезков и промежутков в нарисованной линии. Перья со стилями PSSOLID и PSINSIDEFRAME рисуют сплошные линии, а перо PSNULL вообще ничего не рисует, поэтому остается разобраться с 4 оставшимися стилями. Пунктирное перо PSDASH состоит из отрезков длиной 18 пикселов, разделенных промежутками в 6 пикселов. Точечное перо PSD0T состоит из отрезков длиной 3 пиксела, разделенных промежутками в 3 пиксела. Пунктирно-точечное перо PS_DASHDOT строится по правилу «отрезок 9 пикселов, промежуток 6 пикселов, отрезок 3 пиксела, промежуток 6 пикселов». Для перьев PS_DASHD0TD0T используется цикл «отрезок 9 пикселов, промежуток 3 пиксела, отрезок 3 пиксела, промежуток 3 пиксела, отрезок 3 пиксела, промежуток 3 пиксела». Вероятно, в Microsoft решили, что один пиксел слишком мал, поэтому одна точка на линии представляется тремя пикселами. На рис. 8.2 показаны циклы чередования пикселов в стилях, перечисленных в табл. 8.2. В левом столбце указано название стиля, в среднем — пример линии, нарисованной пером этого стиля, а справа та же линия изображена в увеличении. Линии на рисунке выведены в режиме заполнения OPAQUE темным пером на светлом фоне. Как видно из рисунка, перо PSNULL не выводит ничего, даже пикселов фона. Если толщина линии составляет один пиксел в системе координат устройства, перо PSINSIDEFRAME эквивалентно PSSOLID. В линиях других стилей наглядно прослеживается цикл чередования пикселов. PS_SOLID PS_DASH PS_DOT PS_DASHDOT PS_DASHDOTDOT PSJMULL PSJNSIDEFRAME ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Рис. 8.2. Стили простых перьев Второй параметр CreatePen определяет толщину линии в логической системе координат. Фактическая толщина линии в физических координатах зависит от мировых преобразований и от отображения окна в область просмотра. Например, в режиме MMLOENGLISH с тождественным мировым преобразованием перо с логической толщиной 10 всегда рисует линию, толщина которой на принтере близка к 0,1 дюйма независимо от разрешения. Одна десятая дюйма соответствует 30 пикселам на принтере с разрешением 300 dpi или 120 пикселам на принтере с разрешением 1200 dpi. Перо толщины 0 интерпретируется особым образом; оно всегда рисует линию толщиной 1 пиксел в физических координатах. Если физическая толщина пера превышает 1 пиксел, то перо, созданное функцией CreatePen, не рисует полноценные стилевые линии — например, пунктирные и точечные линии. Вместо этого рисуются только однородные линии с большей толщиной. Другими словами, логическое перо, созданное функций CreatePen, позволяет рисовать стилевые линии лишь толщиной в один пиксел. Увеличение толщины перьев приводит к усложнению вида нарисованных линий. Каждая линия определяется своей базовой осью. Предположим, гори- ■■■■■■■■■■■■■■■■■■шшШШШшМШВВВ шшшшшшшшшшшшшшшшшшшшшшшшшшшшшш — шшшшшшшшшшшшшшшшшшшшшшшшшшшшшш — шшшшшшшшшшшшшшштттшшштттшшшшшш пппппппппппппппппппппппппппппп
432 Глава 8. Линии и кривые зонтальная линия определяется двумя точками (0,0) и (100,0). Если толщина линии равна одному пикселу, вполне очевидно, что в линию должны входить точки (1,0), (2,0) и т. д. до (99,0). Но если толщина линии составляет 5 пикселов, эту линию можно нарисовать несколькими разными способами. Первый вопрос — как пикселы линии должны располагаться по отношению к базовой оси? Для всех перьев, кроме перьев со стилем PSINSIDEFRAME, нарисованная линия центруется относительно своей базовой оси. Перья со стилем PSINSIDEFRAME используются при обводке некоторых фигур GDI (прямоугольников простых и с закругленными углами, эллипсов и т. д.). В этом случае центр линии смещается внутрь области таким образом, чтобы линия не выходила за границы контура. Чтобы нарисовать линию внутри контура, GDI необходимо точно знать, какая из двух сторон линии является внутренней, а какая — внешней. Следовательно, при выводе обычных линий и даже многоугольников перо со стилем PSINSIDEFRAME рисует обычную сплошную линию, центрованную по базовой оси, поскольку GDI не знает, какая сторона является внутренней. Стиль PSINSIDEFRAME активизируется лишь при рисовании определенных фигур с четко различаемой внутренней и внешней частью. Не каждую линию удается точно отцентрировать по базовой оси. Только в вертикальных и горизонтальных линиях с нечетной толщиной один пиксел находится в центре, а остальные равномерно распределяются по обе стороны от него. При выводе утолщенных линий возникает и другой вопрос — как должны выглядеть концы линий? Для перьев, созданных функцией CreatePen, линии всегда заканчиваются полукруглыми концами. w=0 w=2 w=4 w=6 w=8 w=10 w=1 w=3 w=5 w=7 w=9 w=11 Рис. 8.З. Концы линий разной толщины На рис. 8.3 изображены концы линий со стилем PSD0T, которые были нарисованы перьями разной толщины, созданными функцией CreatePen. Если физическая толщина равна 0 или 1, нарисованная линия действительно состоит из точек. С увеличением толщины линии по обеим сторонам базовой оси (светлые
Перья 433 точки) появляются дополнительные пикселы (темные точки), образующие утолщенные линии и закругленные концы. Обратите внимание: только при нечетной толщине линия симметрично центруется относительно базовой оси. ПРИМЕЧАНИЕ В Windows 95/98 утолщенные линии рисуются не так, как показано на рисунке, полученном в Windows 2000. Пикселы не распределяются равномерно по двум сторонам базовой оси, а завершение не имеет нормальной полукруглой формы. Расширенные перья Если разобраться со всеми ограничениями, становится ясно, что простые перья, созданные функциями CreatePen или CreatePenlndirect, существуют только в двух формах: стилевое перо с толщиной один пиксел и утолщенное перо с круглым завершением. Стиль PSINSIDEFRAME из-за своей реализации в Windows GDI особой пользы не приносит, поскольку он может применяться лишь для некоторых фигур, вписанных в прямоугольник. Однако для этих фигур приложение может легко добиться того же эффекта при помощи обычного пера, слегка уменьшив ограничивающий прямоугольник. Для преодоления этих ограничений в Win32 API появилась новая функция ExtCreatePen, создающая расширенные перья с обогащенным набором атрибутов. HPEN ExtCreatePen(DWORD dwPenStyle. DWORD dwWidth, CONST LOGBRUSH * lplb. DWORD dwStyleCont. CONST DWORD * IpStyle): Функция ExtCreatePen позволяет создавать перья 2 типов, 9 стилей, с 3 видами завершений и 3 видами соединений. Вся эта информация определяется одним параметром dwStyle в виде комбинации флагов из табл. 8.3, объединенных поразрядным оператором ИЛИ (|). Таблица 8.3. Типы, стили, завершения и соединения расширенных перьев Флаг Смысл Ограничения Типы PSC0SMETIC Косметическое перо. Толщина равна одному пикселу PSGE0METRIC Геометрическое перо. Толщина пера задается в логических единицах Стили PSS0LID Непрерывная линия, рисуются все пикселы. Выравнивание по центру PSDASH Пунктирная линия. Выравнива ние по центру В Windows 95/98 не поддерживаются геометрические перья с этим стилем Продолжение #
434 Глава 8. Линии и кривые Таблица 8.3. Продолжение Флаг Смысл Ограничения PSD0T Точечная линия. Выравнивание по центру PSDASHDOT Пунктирно-точечная линия. Выравнивание по центру PSDASHD0TD0T Отрезок и две точки. Выравнивание по центру PS_NULL Линия не рисуется PS_INSIDEFRAME Непрерывная линия, рисуются все пикселы. Выравнивание внутри контура PSUSERSTYLE Чередование отрезков и промежутков задается параметрами dwStyl eCount и IpStyle. Выравнивание по центру PS_ALTERNATE Чередование «пиксел — промежуток» Только геометрические перья, используется лишь при обводке некоторых фигур GDI Поддерживается только в Windows NT/2000 Поддерживается только в Windows NT/2000 и только для косметических перьев Завершение PS_ENDCAP_ROUND PS ENDCAP SQUARE Закругленное завершение (к линии добавляется половина круга) Квадратное завершение (к линии добавляется половина квадрата) PSENDCAPFLAT Плоское завершение Только для геометрических перьев Только для геометрических перьев Только для геометрических перьев Соединение PS_JOIN_BEVEL PS_JOIN_MITER PS JOIN ROUND Усеченное соединение Заостренное соединение Закругленное соединение Только для геометрических перьев Только для геометрических перьев Только для геометрических перьев Расширенные перья делятся на два типа: косметические и геометрические. Параметр dwWidth определяет толщину пера. Для косметических перьев толщина может быть равна только 1. Для геометрических перьев толщина задается в логических координатах, поэтому фактическая толщина линий зависит от мировых преобразований и отображения окна в область просмотра. Расширенные перья используют структуру L0GBRUSH для определения цветов и узоров. В косметических перьях допускаются только однородные цвета и сплошная заливка, а геометрические перья допускают наличие смешанных цветов и различных узор-
Перья 435 ных кистей. Два последних параметра ExtCreatePen определяют пользовательское правило чередования пикселов в перьях стиля PSJJSERSTYLE. Косметические перья Косметические перья всегда рисуют линии толщиной в один пиксел. Хотя в MSDN утверждается, что косметические перья обладают произвольной шириной, задаваемой в системе координат устройства, единственным допустимым значением параметра dwWidth является 1; при любых других значениях вызов функции завершается неудачей. В Windows NT/2000 появились два новых стиля: PSJJSERSTYLE и PS_ALTERNATE. Стиль PS_ALTERNATE может использоваться только в косметических перьях для создания «настоящих» точечных линий. Стиль PSJJSERSTYLE позволяет приложению определять собственные последовательности чередования пикселов (биты стиля). Для создания пера с пользовательским стилем необходимы два дополнительных параметра, dwStyl eCount (тип DWORD) и IpStyle (массив DWORD). Первый элемент массива содержит длину первого отрезка, второй — длину промежутка, третий — длину второго отрезка и т. д. При этом одна единица соответствует трем пикселам вместо одного. Следовательно, пользовательский стиль позволяет имитировать стили PSJ3ASH, PSJDOT, PSJDASHDOT и PSJ3ASHD0TD0T, но не стиль PS_ ALTERNATE. В приведенном ниже фрагменте создается косметическое перо с циклом чередования {4,3,2,1} — то есть отрезок из 12 пикселов, промежуток из 9 пикселов, отрезок из 6 пикселов и промежуток из 3 пикселов. const DWORD cycle[4] ={4.3.2.1}: const LOGBRUSH brush = {BS_S0LID. RGB(O.O.OxFF). 0 }: HPEN hPen - ExtCreatePen(PS_COSMETIC | PSJJSERSTYLE. 1. & brush. sizeof(cycle)/sizeof(cycle[0]). cycle): На первый взгляд кажется, что косметические перья аналогичны простым перьям, созданным функцией CreatePen с шириной 0. Однако у них имеется одно важное недокументированное отличие (а может, дефект реализации): косметические перья всегда рисуют в прозрачном режиме. Другими словами, даже при включении режима заполнения фона OPAQUE фоновые пикселы в промежутках не выводятся. Стили косметических перьев показаны на рис. 8.4. Для линий пользовательского стиля используется цикл чередования {4,3,2,1}. Обратите внимание: PS_INSIDEFRAME является недопустимым стилем косметического пера, который не преобразуется автоматически к стилю сплошной линии. PS_SOLID PS_DASH PS_DOT PS_DASHDOT PS_DASHDOTDOT PS_NULL PSJNSIDEFRAME PSJJSERSTYLE PS ALTERNATE ■DDDDnDI ■□□□■■■□□□■■■□□□■■■□□□■■■□□□ ■■■■■■«^□□□□□■■■□□□□□□■■■■И ■■■■■■■□□□■■■□□□■■■□□□■■■■■И ■■■■■■■■■■■■□□□□□□□□□■■■■■■□□□ ■□■□■□■□■□■□■□■□■□■□■□■□■□■ПИП Рис. 8.4. Стили косметических перьев
436 Глава 8. Линии и кривые Как подсказывает название, косметические перья хорошо подходят для рисования тонких линий, особенно на экране монитора. При выводе в контексте устройства принтера, обладающем повышенным разрешением, стилевые линии выглядят как более светлые сплошные линии, и даже сплошные линии видны лишь при высоком контрасте с цветом фона. Геометрические перья Геометрическое перо рисует линию «наконечником» в виде геометрической фигуры. Говоря точнее, геометрическое перо обладает переменной толщиной, стилем, завершением и соединением. Давайте рассмотрим эти атрибуты более подробно. Толщина геометрического пера задается в логических координатах, но в отличие от перьев, созданных функцией CreatePen, толщина геометрического пера не может быть равна 0. С реальной физической толщиной геометрического пера дело обстоит сложнее. В режиме ММТЕХТ с тождественным преобразованием одна логическая единица устройства преобразуется в одну физическую единицу, поэтому физическая толщина совпадает с логической. Если мировое преобразование и отображение окна в область просмотра используют одинаковый масштаб по обеим осям, толщина логического пера масштабируется в соответствии с заданным масштабным коэффициентом. Но если масштаб различается, вертикальные и горизонтальные линии, нарисованные одним и тем же геометрическим пером, будут иметь разную толщину. Это относится и к перьям, созданным функцией CreatePen. Линия, нарисованная геометрическим пером, рассматривается не как простая последовательность пикселов, а как геометрическая фигура. Например, линия (0,0)—(100,0), нарисованная пером толщины 10, по форме совпадает с прямоугольником, определяемым противоположными углами (0,0) и (100,10). Мировые преобразования и режим отображения распространяются на линию в той же степени, как и на прямоугольники. На рис. 8.5 изображены контрольные точки повернутой геометрической линии (х0,у0) - (х1,у1). dx = penwidth * sin (о)/2 dy = penwidth * cos(o)/2 (x0-dx,y0+dy) (x0,y0) (x1-dx,y1+dy) (x1,y1) [x1+dx,y1-dy) (x0+dx,y0-dy) Рис. 8.5. Геометрическая линия как геометрическая фигура
Перья 437 Атрибут завершения геометрической линии определяет вид «наконечников», добавляемых к обоим концам линии или ее внутренних отрезков. Линия, изображенная на рисунке, выводится без завершений, что соответствует стилю PS_ ENDCAPFLAT (плоское завершение). К обоим концам утолщенных линий, нарисованных простыми перьями, добавляются полукруглые наконечники (PS_ENDCAP_ ROUND). При квадратном завершении (PSENDCAPSQUARE) к обоим концам присоединяются половины квадратов. В Windows NT/2000 для геометрических перьев реализованы все стили кроме стиля PS_ALTERNATE, зарезервированного для косметических линий. В отличие от простых перьев, созданных функцией CreatePen, утолщенные геометрические линии рисуются в соответствии со своим стилем и не преобразуются в сплошные линии. Геометрические перья не изображают одну точку тремя пикселами; вместо этого размер точки или отрезка масштабируется вместе с толщиной линии. При этом одна точка изображается одним пикселом, как при использовании косметических линий со стилем PS_ALTERNATE. С утолщением пера увеличиваются и размеры точек. Каждый отрезок или точка оформляются соответствующими завершениями. Следовательно, отрезки пунктирной линии могут заканчиваться плоскими, круглыми или квадратными завершениями. К сожалению, в Windows 95/98 реализация Win32 GDI API выглядит несколько иначе. В этих системах, основанных на 16-разрядных версиях GDI, утолщенные геометрические перья реализуются в виде сплошных линий. Геометрические перья уже не ограничиваются одним сплошным цветом. Функции ExtCreatePen передается структура L0GBRUSH, содержащая информацию о цвете, стили кисти и стиле штриховки. Структура L0GBRUSH обычно используется для определения логических кистей, предназначенных для заливки фигур. Однако геометрические линии принципиально не отличаются от геометрических фигур, поэтому вполне естественно, что GDI позволяет закрашивать их кистями. На рис. 8.6 изображены геометрические линии с разными завершениями, стилями и узорами. Обратите внимание: стиль PSALTERNATE для геометрических линий считается недействительным, а стиль PSNULL ничего не рисует. В отличие от косметических перьев геометрические перья рисуют линии в прозрачном режиме, игнорируя цвет и режим заполнения фона (с одним исключением — при работе со штриховой кистью эти атрибуты используются для закраски фона между штрихами). Также стоит обратить внимание на то, что величина промежутков в пользовательском стиле задается в пикселах, а не в логических единицах, которые изменяются вместе с толщиной пера. С утолщением пера или с добавлением завершений отрезки в линиях пользовательского стиля могут «наползать» друг на друга. Стыки утолщенных линий с завершениями могут выглядеть не так, как можно было бы предположить. На рис. 8.7 показано, как выглядит буква Z, состоящая из трех утолщенных линий с разными завершениями. Тонкие белые линии обозначают положение базовых осей. На рисунке видны завершения, созданные стилями PS_ENDCAP_SQUARE и PS_ENDCAP_ROUND. Плоские и квадратные завершения стыкуются неровно. Хотя линии с круглыми завершениями стыкуются нормально, при использовании режима R2_X0RPEN общие части линий будут отличаться по цвету, поскольку они прорисовываются дважды.
438 Глава 8. Линии и кривые w=3, flat PS_SOLID PS_DASH PS_DOT PS_DASHDOT PS_DASHDOTDOT PS_NULL PSJNSIDEFRAME PSJJSERSTYLE — - - PS ALTERNATE w=7, flat w=11, square w=15, round, hatch 0 # # m ф т m m ■« m # Рис. 8.6. Геометрические линии с различной толщиной, завершениями, штриховкой и стилями PS ENDCAP FLAT PS ENDCAP SQUARE PS ENDCAP ROUND PS_ENDCAP_ROUND R2 XORPEN Рис. 8.7. Соприкосновение линий с разными завершениями Для обеспечения плавной стыковки линий GDI позволяет объединить несколько линий и кривых в один графический вызов. Если геометрическое перо используется для рисования линии или кривой, состоящей из нескольких сегментов, способ стыковки сегментов определяется специальным атрибутом — соединением. Существует три типа соединений. Усеченное соединение строится по форме двух сегментов с плоскими соединениями; к стыку добавляется треугольник, заполняющий впадину. Заостренное соединение строится аналогичным образом, но в этом случае линии продолжаются до точки пересечения. Закругленное соединение выглядит так же, как и при стыковке двух линий с круглыми завершениями. На рис. 8.8 изображена та же Z-образная фигура, нарисованная функцией Polyline GDI, позволяющей за один вызов нарисовать несколько линий с разными типами соединений. Кроме улучшения внешнего вида соединений, функция Polyline рисует каждый пиксел только один раз, поэтому даже при использовании операции R2_X0RPEN вся линия будет нарисована одним цветом. PS_ENDCAP_FLAT PS JOIN BEVEL PS_ENDCAP_SQUARE PS JOIN MITER PS_ENDCAP_ROUND PS JOIN ROUND PS_ENDCAP_ROUND PS_JOIN_ROUND R2 XORPEN Рис. 8.8. Типы соединений при использовании функции Polyline
Перья 439 При стыковке линий под острыми углами длина заостренного соединения может быть очень большой. Чтобы избежать чрезмерного удлинения стыков, GDI позволяет приложению ограничить длину заостренного соединения при помощи функции SetMiterLimit: BOOL SetMiterLimitCHDC hDC. FLOAT eNewLimit. PFLOAT peOldLimit); Функция SetMiterLimit определяет угловой лимит — максимальное отношение длины заострения к толщине линии. На второй фигуре слева (см. рис. 8.8) длина заострения равна расстоянию от пересечения внешних границ линии до пересечения внутренних границ. Толщина пера равна расстоянию между двумя пересечениями по оси у. По умолчанию угловой лимит в контекстах устройств равен 10,0. На рисунке отношение равно примерно 4,35. Если отношение длины заострения к толщине линии превышает угловой лимит, вместо заостренного соединения используется усеченное. Если вы предпочитаете математический подход, то при пересечении двух линий под углом 9 угловое отношение определяется выражением l/sin(9/2), независящим от толщины пера. В приведенном выше примере ширина Z-образной фигуры вдвое превышает ее высоту, поэтому sin(0) = 1/V5, sin(8/2) = 0,229753, а угловое отношение равно 4,352502. Получение информации о логических перьях По известному манипулятору объекта логического пера приложение может узнать тип пера и получить его описание при помощи двух общих функций: DWORD GetObjectTypeCHGDIOBJ h); int GetObjectCHGDIOBJ hgdiobj. int cbBuffer. LPVOID IpvObject); Функция GetObjectType возвращает идентификатор типа объекта GDI. Для простого пера возвращается константа 0BJPEN; для расширенного пера возвращается 0BJEXTPEN. Функция GetObject заполняет буфер определением объекта GDI. Для простых перьев заполняется структура LOGPEN; а для расширенных — структура EXTLOGPEN. Структура LOGPEN имеет фиксированный размер, поэтому для простого пера функция GetObject работает просто. Однако структура EXTLOGPEN имеет переменную длину из-за массива описания стиля, поэтому функцию GetObject приходится вызывать дважды. При первом вызове определяется точный размер структуры EXTLOGPEN, а при втором вызове заполняется выделенный блок памяти нужного размера. В Win32 API подобные двухшаговые вызовы встречаются довольно часто. Приведенный ниже фрагмент показывает, как использовать эти две функции для заполнения структуры LOGPEN или EXTLOGPEN в зависимости от типа манипулятора объекта пера. LOGPEN logpen; EXTLOGPEN * pextlogpen - NULL; int size = 0; switch ( GetObjectType(hPen) ) { case 0BJ_PEN: GetObject(hPen, sizeof(logpen), & logpen); break;
440 Глава 8. Линии и кривые case OBJJXTPEN: size = GetObject(hPen. 0, NULL); pextlogpen = (EXTLOGPEN *) new char[size]; GetObjectChPen. size, pextlogpen); break; default: } if ( pextlogpen ) { delete [] (char *) pextlogpen; pextlogpen = NULL; } Класс для работы с объектами перьев GDI Чтобы воспользоваться нестандартным объектом пера, необходимо создать его и выбрать в контексте устройства; после использования объект исключается из контекста и удаляется. Сделать это несложно, но не слишком интересно. Ниже приведен простой класс КРеп C++, предназначенный для работы с простыми перьями и обычными расширенными перьями. // Класс для выбора объектов GDI class KSelect { HGDIOBJ mJiOld; HDC mJiDC: public: void Select(HDC hDC. HGDIOBJ hObject) { if ( hDC ) { m_hDC = hDC: mJiOld - SelectObject(hDC. hObject); } else { m_hDC - NULL; m_h01d - NULL; } } void UnSelect(void) { if ( m_hDC ) { SelectObject(m_hDC. m_h01d); mJiDC = NULL; mJiOld - NULL; } } }:
Перья 441 // Класс для работы с объектами перьев class KPen : public KSelect { public: HPEN m_hPen; KPen(int style, int width, COLORREF color, HDC hDC=NULL) { m_hPen = CreatePen(style, width, color); Select(hDC); } KPen(int style, int width. COLORREF color, int count. DWORD * gap. HDC hDC=NULL) { LOGBRUSH logbrush = { BSJOLID. color. 0 }; m_hPen = ExtCreatePenCstyle, width. & logbrush. count, gap); Select(hDC); } void Select(HDC hDC) { KSelect::Select(hDC. m_hPen); } -KPenО { UnSelectO: DeleteObject(m_hPen): } }: Класс KPen содержит два конструктора. Первый конструктор создает простые перья, а второй — расширенные перья без узорной кисти. В принципе можно написать еще один конструктор, который бы создавал расширенные перья с узорной кистью. Оба конструктора получают необязательный параметр — манипулятор контекста устройства. Если этот параметр задан, манипулятор созданного пера GDI выбирается в заданном контексте устройства. Деструктор исключает перо из контекста, если оно все еще остается выбранным, и удаляет объект. Два дополнительных метода предназначены для явного выбора и исключения манипулятора пера из контекста. Применять класс KPen чрезвычайно просто. Если в некотором фрагменте используется всего одно перо, заключите экземпляр класса KPen в соответствующий блок, передайте конструктору манипулятор контекста устройства, и в дальнейшем создание объекта GDI, его выбор в контексте, исключение и удаление будут выполняться автоматически. Если фрагмент программы работает с несколькими перьями, не передавайте манипулятор контекста конструктору; вместо этого в нужные моменты следует вызывать методы Select и UnSelect. Рассмотрим несколько простых примеров. { KPen red(PS_SOLID. 1. RGBCOxFF. 0. 0). hDC); // Рисовать красным пером
442 Глава 8. Линии и кривые // При выходе из этого блока перо автоматически // исключается из контекста и уничтожается } { KPen red (PS_S0LID. 1. RGB(0xFF, 0. 0)); KPen green (PS_S0LID, 1. RGB(0. OxFF. 0)); red.Select(hDC); // Рисовать красным пером red.UnSelect(hDC): green.Select(hDC): // Рисовать зеленым пером green.UnSelect(hDC): // При выходе из блока оба пера автоматически удаляются } Линии После того как в контексте устройства выбран действительный манипулятор объекта логического пера, можете использовать следующие функции для рисования прямых линий (по отдельности или нескольких сразу), а также для подготовки к рисованию линий: BOOL MoveToEx(HDC hDC. int X, int Y. LPPOINT IpPoint); BOOL LineTo(HDC hDC. int nXEnd, int nYEnd); BOOL PolylineTo(HDC hDC. CONST POINT * Ippt. DWORD cCount): BOOL Polyline(HDC hDC. CONST POINT * Ippt. int cPoints): BOOL PolyPolyline(HDC hDC. CONST POINT * Ippt. CONST DWORD * lpdwPolyPoints. DWORD nCount); Функция MoveToEx не рисует линий — она всего лишь перемещает текущую позицию пера в контексте устройства в точку с заданными координатами. Исходная позиция возвращается в параметре IpPoint. Такие функции, как LineTo, PolylineTo, PolyBezierTo и даже функции вывода текста, начинают вывод с текущей позиции пера. Все координаты задаются в логическом пространстве. Функция LineTo рисует линию от текущей позиции пера к точке (nXEnd, nYEnd) pi переводит текущую позицию в точку (nXEnd, nYEnd). Внешний вид линии зависит от всех атрибутов, описанных в предыдущем разделе. В процессе вывода также могут учитываться и другие атрибуты контекста устройства — например, мировое преобразование, режим отображения, бинарная растровая операция, режим заполнения фона, цвет фона и угловой лимит. При этом необходимо учитывать ряд обстоятельств. Во-первых, пиксел физического координатного пространства, отображаемый в точку (nXEnd, nYEnd), не рисуется, а начальная точка рисуется. Например, если вы проводите линию из точки (0,0) в точку (100,0) при тождественном отображении из логических координат в физические, рисуются пикселы (0,0)—(99,0), но не рисуется пиксел
Линии 443 (100,0). При этом текущая позиция пера перемещается в точку (100,0), поэтому эта точка будет нарисована при выводе следующей линии, проведенной из этой точки. Если вы рисуете несколько соединенных линий функцией LineTo, каждый пиксел, за исключением последнего, рисуется ровно один раз. Это условие сохраняется при смещениях, масштабированиях, поворотах и других преобразованиях координатного пространства. Если при выводе линии используются такие бинарные растровые операции, как R2X0RPEN, точки соединения отрезков по виду не отличаются от других пикселов. Если бы функция LineTo прорисовывала последний пиксел, точки стыков рисовались бы дважды и поэтому выводились бы цветом фона. Из-за этого правила и по другим причинам операции рисования линий являются направленными. Другими словами, для двух точек (х0,у0) и (х1,у1) линия, проведенная из (х0,у0) в (х1,у1), несколько отличается от линии, проведенной из (х1,у1) в (х0,у0). Также следует помнить о том, что каждый вызов функции рисования линии стилевым пером заново начинает цикл чередования пикселов. Совмещение стилей разных линий (что-то наподобие изменения базовой точки кисти) в GDI не поддерживается. Например, для трех точек (х0,у0), (х1,у1) и (х2,у2), расположенных на одной прямой, результат рисования двух линий (х0,у0) - (х1,у1) и (х1,у1) - (х2,у2) может отличаться от результата рисования одной линии (х0,у0) - (х2,у2). В следующем фрагменте функции MoveToEx и LineTo используются для рисования «розетки» — многоугольника, у которого каждая вершина соединена со всеми остальными вершинами. Цвет линии зависит от расстояния между вершинами. Для упрощения переключения цветов в этом фрагменте используется перо DC, однако его нетрудно заменить простым пером. const int N =19; const int Radius - 200; const double theta - 3.1415926 * 2 / N: SelectObject(hDC. GetStockObject(DC_PEN)); const C0L0RREF color[] = { RGB(0. 0. 0), RGB(255, 0. 0). RGB(0.255.0) RGB(255.255.0). RGB(0. 255. 255). RGBC255. 255 RGB(127. 255. 0). RGB(0. 127. 255). RGBC255. 0 }: for (int p=0; p<N; p++) for (int q=0; q<p; q++) { SetDCPenColor(hDC. color[min(p-q.N-p+q)]); MoveToEx(hDC. (int)(220 + Radius * sin(p * theta)). (int)(220 + Radius * cos(p * theta)). NULL); LineTo(hDC. (int)(220 + Radius * sin(q * theta)). (int)(220 + Radius * cos(q * theta))); Функции PolylineTo передается массив структур POINT, содержащих координаты хну. Сначала функция рисует первый отрезок от текущей позиции пера к первой точке массива POINT, а затем последовательно соединяет линиями все остальные точки массива. В конце рисования текущая позиция пера перемещается в последнюю точку. Функция Polyline получает те же параметры, что и RGB(0.0.255). 0). 127)
444 Глава 8. Линии и кривые PolylineT, но работает несколько иначе — она не использует и не обновляет текущую позицию пера. Функция Polyline проводит отрезок от первой точки массива ко второй, а затем последовательно соединяет все остальные точки массива. Для массива из п структур POINT функция PolylineTo рисует п отрезков, а функция Polyline рисует п-1 отрезок. В общем случае функции PolylineTo и Polyline нельзя заменить вызовами MoveToEx и LineTo. При использовании стилевого пера функции Polyline и PolylineTo при переходе к новому отрезку продолжают старый цикл чередования пикселов, а при нескольких вызовах LineTo рисунок каждый раз начинается заново. При работе с геометрическим пером атрибут завершения применяется к первой и последней точке, а атрибут соединения — к каждому стыку. Использование функций Polyline и PolylineTo улучшает внешний вид стыков, чего довольно трудно добиться с помощью функции LineTo. Это особенно важно при увеличении изображения или при печати, где характерны утолщенные перья. Достаточно сравнить рис. 8.7, где используются серии вызовов LineTo, и рис. 8.8, где используется один вызов Polyline. Кроме того, многократный вызов функции API обрабатывается дольше, чем однократный вызов для нескольких отрезков. Наконец, при выводе в метафайловый контекст устройства функции Polyline и PolylineTo занимают меньше места, чем серия вызовов LineTo. Однако функции PolylineTo и Polyline не идеальны; в частности, они не поддерживают концепцию замкнутых контуров. Завершение выводится в первой и последней точке всегда, даже если их координаты в точности совпадают. Если вы рисуете геометрические фигуры, все углы которых кратны 90°, квадратные завершения и заостренные соединения обеспечат нормальное замыкание контура, а для рисования замкнутых фигур с закругленными углами всегда можно воспользоваться закругленными завершениями и соединениями. Но если вы рисуете произвольный треугольник или многоугольник, в нем могут встретиться острые или тупые углы. Заостренное соединение обеспечивает правильность всех стыков, кроме самой первой точки (которая также является последней). Существует стандартное решение — добавить в конец дополнительный отрезок от первой точки ко второй. Даже при использовании бинарных растровых операций, при которых существуют различия между однократным и двукратным выводом, фигура, нарисованная за один вызов PolylineTo или Polyline, не содержит пикселов, нарисованных дважды. В следующем фрагменте функция Polyline используется для рисования треугольника. Необязательный параметр extra позволяет создать дополнительный отрезок, улучшающий вид конечной точки: void Triangle(HDC hDC. int xO. int yO. int xl. int yl. int x2, int y2. bool extra=false) { POINT corner[5]= {xO.yO. xl.yl. x2.y2. xO.yO, xl.yl}; if (extra) // Дополнительный отрезок, // улучшающий вид замкнутой фигуры Polyline(hDC. corner, 5); else Polyline(hDC, corner, 4); }
Линии 445 Функция PolyPolyline позволяет нарисовать несколько ломаных линий за один вызов. В ее последнем параметре nCount вместо количества вершин передается количество ломаных. Третий параметр, IpdwPolyPoints, представляет собой массив с количествами вершин в каждой ломаной. Функция PolyPolyline рисует всю фигуру в целом; она не сводится к простому вызову Polyline для каждой ломаной. Различия проявляются при использовании перекрывающихся ломаных и таких растровых операций, как R2X0RPEN. Если фигура рисуется одним вызовом, каждый пиксел прорисовывается всего один раз; в противном случае перекрывающиеся пикселы прорисовываются многократно, а их цвет обычно отличается от цвета пикселов при однократной прорисовке. На растровых устройствах (таких, как экран монитора или принтер) пикселы, образующие линию, выбираются при помощи специальных алгоритмов DDA (Digital Differential Analyzer). Примером классического алгоритма DDA является алгоритм Брезенхэма (Bresenham). Для представления поверхности физического устройства графический механизм Windows NT/2000 использует координаты с фиксированной точкой в формате 28.4. Линии рисуются по так называемому алгоритму G1Q (Grid Intersection Quantization), при котором каждый пиксел окружается воображаемым ромбом величиной 1x1 пиксел. Пиксел рисуется, если линия имеет общие точки с этим ромбом. Функция LineDDA позволяет передать координаты каждой точки, которую GDI собирается выводить, функции косвенного вызова, указанной приложением: BOOL LineDDACint nXStart. int nYStart. int nXEnd, int nYEnd. LINEDDAPROC IpLineProc. LPARAM lpData); Прототип LineDDA не производит особого впечатления. Среди параметров функции нет ни контекста устройства, ни логического пера. Следовательно, LineDDA возвращает точки в одной системе координат с параметрами, без учета специфики физической системы координат и стилей пера. В листинге 8.3 показано, как функции LineTo, Polyline и LineDDA используются для рисования равносторонних треугольников. Результат изображен на рис. 8.9. Поскольку мы используем толстое геометрическое перо, соединения на первом рисунке (функция LineTo) выглядят уродливо. На втором рисунке (функция Polyline с тремя отрезками) нарушено лишь последнее соединение. На третьем рисунке добавлен четвертый отрезок, обеспечивающий идеальную стыковку во всех точках. На четвертом рисунке показано, как при помощи функции LineDDA разместить вдоль базовой оси треугольника несколько маленьких треугольников. Функция косвенного вызова LineDDAProc рисует маленький треугольник при каждом 32-м вызове. Листинг 8.2. Рисование линий функциями LineTo, Polyline и LineDDA * void CALLBACK LineDDAProcCint x. int y. LPARAM lpData) { HDC hDC = (HDC) lpData; POINT cur; GetCurrentPositionEx(hDC. &cur); if ( (cur.x & 31)== 0 ) // Каждый 32-й вызов Triangle(hDC, x. y-16. x+20, y+18. x-20. y+18): Продолжение^
446 Глава 8. Линии и кривые Листинг 8.2. Продолжение cur.x ++; MoveToEx(hDC, cur.x, cur.у, NULL); void KMyCanvas::TestLine2(HDC hDC) { LOGBRUSH logbrush = { BS_S0LID. RGB(0, 0, OxFF), 0 }; HPEN hPen = ExtCreatePen(PS_GEOMETRIC | PS_S0LID | PSJNDCAPJLAT | PS_JOIN_MITER, 15. & logbrush, 0. NULL); HGDIOBJ hOld = SelectObject(hDC. hPen); // Нарисовать треугольник несколькими вызовами LineTo SetViewportOrgEx(hDC, 100. 50. NULL); Line(hDC. 0. 0. 50, 86); LineTo(hDC. -50, 86); LineTo(hDC. 0, 0); // Использование функции Polyline SetViewportOrgEx(hDC. 230. 50. NULL); Triangle(hDC. 0. 0, 50, 86, -50. 86, false ); // Использование функции Polyline с дополнительным отрезком SetViewportOrgEx(hDC. 360, 50, NULL); Triangle(hDC, 0. 0. 50. 86. -50. 86. true ); // Использование LineDDA SetViewportOrgEx(hDC. 490. 50, NULL); SelectObject(hDC. hOld); DeleteObject(hPen); hPen = ExtCreatePen(PS_GEOMETRIC | PS_D0T | PS_ENDCAP_ROUND. 3. & logbrush, 0. NULL); SelectObject(hDC. hPen): LineDDA( 0. 0. 50, 86. LineDDAProc. (LPARAM) hDC); LineDDA( 50, 86. -50. 86. LineDDAProc. (LPARAM) hDC); LineDDA(-50. 86. 0. 0. LineDDAProc. (LPARAM) hDC); SetViewportOrgEx(hDC, 50. 150. NULL); SelectObjecUhDC. hOld); DeleteObject(hPen); Рис. 8.9. Рисование треугольников функциями LineTo, Polyline и LineDDA AAA
Кривые Безье 447 Кривые Безье Предположим, у нас имеются точки Р1 и Р2 на плоскости и отрезок, соединяющий эти точки. Пусть переменная t принимает значения от 0 до 1; точка Р12(£) на отрезке Р1-»Р2 определяется по формуле P12(t) - (l-t)Pl + tP2 Отрезок Р1-»Р2 образуется значениями функции Р12(£) при изменении t от О до 1. Если добавить на плоскость еще одну точку РЗ, мы можем определить Р12(£) как точку между Р1 и Р2, а Р23(£) — как точку между Р2 и РЗ. Если теперь применить аналогичный метод для определения Р1223(£) как точки между Р12(£) и Р23(£), мы получим: P12(t) = (l-t)Pl + tP2 P23(t) - (l-t)P2 + tP3 P1223(t) = (l-t)(l-t)Pl + tP2) + t((l-t)P2 + tP3) = (l-t)A2Pl + 2t(t-l)P2 + tA2P3 Точки, описываемые функцией PI223(0 при изменении t от 0 до 1, уже не образуют прямую линию. Перед нами квадратичная кривая, или параболическая кривая второго порядка. Этот способ определения кривых изобрел П. де Касте- ло (P. de Casteljau) в 1959 году. Позднее, в 1962 году, теорию этих кривых заново разработал П. Безье (P. Bezier) в процессе работы над системами автоматизированного проектирования для компаний «Ситроен» и «Рено». Именно Безье впервые представил эти кривые широкой публике, поэтому они известны как кривые Безье. Квадратичные кривые Безье используются в шрифтах TrueType для описания контуров глифов. Для компьютерной графики характерны кривые, определяемые четырьмя точками по описанному выше принципу. Такие кривые называются кубическими кривыми Безье. На рис. 8.10 показан процесс конструирования кубической кривой Безье по следующим формулам: P12(t) = (l-t)Pl + tP2 P23(t) = (l-t)P2 + tP3 P34(t) = (l-t)P3 + tP4 P1223U) « (l-t)A2Pl + 2t(t-l)P2 + Г2РЗ P2334U) = (l-tr2P2 + 2t(t-l)P3 + Г2Р4 P(t) = (l-t)A3Pl + 3(l-t)"2tP2 + 3(l-t)tA2P3 + ГЗР4 Процесс, проиллюстрированный на рисунке, обычно называется алгоритмом де Кастело. Точки Р1, Р2, РЗ и Р4, задающие кривую Безье, называются ее определяющими точками. Точки Р1 и Р4 называются конечными, а точки Р2 и РЗ — контрольными. Кривые Безье обладают рядом интересных свойств, из-за которых они широко используются в системах автоматизированного проектирования и в производстве. О Аффинная инвариантность. Кривые Безье в результате аффинных преобразований, используемых GDI при отображении из мировой системы координат в страничную, переходят в кривые Безье. Следовательно, графическому механизму остается лишь преобразовать определяющие точки и нарисовать кривую в координатах устройства по преобразованным точкам.
448 Глава 8. Линии и кривые Р2 '■*■*.. Р23 PI P4 Рис. 8.10. Построение кубической кривой Безье по четырем определяющим точкам О Ограниченность. Кривая Безье всегда полностью лежит внутри выпуклой фигуры, вершинами которой являются ее определяющие точки. О Касательные в конечных точках. Линия, соединяющая точки Р1 и Р2, является касательной к кривой в точке Р1; линия, соединяющая точки РЗ и Р4, является касательной к кривой в точке Р4. Чтобы две кривые Безье (Р1,Р2, РЗ,Р4) и (Р4,Р5,Р6,Р7) соединялись плавно (то есть с непрерывной первой производной), достаточно, чтобы точки РЗ, Р4 и Р5 находились на одной линии. О Делимость. Кривая Безье легко делится на две кривые Безье. Кривую, изображенную на рис. 8.10, можно легко разделить на две кривые, соединяющиеся в точке Р; первая кривая определяется точками (Р1,Р12,Р1223,Р), а вторая - точками (Р,Р2334,Р34,Р4). На основании свойства делимости построен алгоритм рисования кривых Безье как совокупности прямых линий. Кривая Безье делится в средней точке (t = 0,5), после чего две полученные кривые рекурсивно делятся до тех пор. пока контрольные точки не окажутся достаточно близко к линии, что позволяет представить кривую отрезком. Рекурсивная функция для аппроксимации кривых Безье представлена в листинге 8.3. Сначала функция проверяет, расположены ли точки (х2,у2) и (хЗ,уЗ) па расстоянии меньше одной единицы от линии (х1,у1) - (х4,у4). Если это условие выполняется, функция рисует прямую линию; в противном случае кривая делится в середине на две кривые, вывод которых осуществляется рекурсивным вызовом. Точность вычислений обеспечивается использованием чисел с плавающей точкой. Листинг 8.3. Рисование кривых Безье из отрезков void Bezier(HDC hDC. double xl, double yl. double x2. double y2. double x3. double y3, double x4. double y4) {
Кривые Безье 449 double A = у4 - yl; double В = xl - х4; double С = yl * (x4-xl) - xl * ( y4-yl); // Ах + By + С = О - линия (xl.yl) - (х4,у4) double AB =А*А+В*В; // Расстояние от (х2.у2) до линии меньше 1 // Расстояние от (хЗ.уЗ) до линии меньше 1 if ( (A*x2 + B*y2 + C)*(A*x2 + B*y2 + C)<AB) if ( (А*хЗ + В*уЗ + С)*(А*хЗ + В*уЗ + С)<АВ) { MoveToEx(hDC. (int)xl. (int)yl. NULL); LineTo(hDC. (int)x4. (int)y4); return; } double xl2 double yl2 double x23 double y23 double x34 double y34 double xl223 double у1223 double x2334 double y2334 double x double у = xl+x2 = yl+y2 - x2+x3 - У2+УЗ = x3+x4 = y3+y4 = xl2+x23; = yl2+y23 = x23+x34 = y23+y34 = X1223 + x2334 = У1223 + y2334 Bezier(hDC. xl. yl. xl2/2. yl2/2. xl223/4. yl223/4. x/8. y/8); Bezier(hDC, x/8. y/8. x2334/4. y2334/4. x34/2. y34/2. x4. y4): } Давайте познакомимся с двумя функциями GDI, обеспечивающими поддержку кривых Безье. BOOL PolyBezier (HDC hDC. CONST POINT * Ippt. DWORD cPoints); BOOL PolyBezierTo(HDC hDC. CONST POINT * Ippt. DWORD cCount); Обе функции рисуют несколько кривых Безье за один вызов. Для рисования п кривых функция PolyBezier получает jxn+1 точек в массиве, на который ссылается указатель Ippt; при этом параметр cPoints должен быть равен jxn+ 1. Первые четыре точки lppt[0], lppt[l], lppt[2] и lppt[3] определяют первую кривую, lppt[3] со следующими тремя точками — вторую кривую и т. д. Функция PolyBezier не использует и не обновляет текущей позиции пера. Функция Poly- BezierTo рисует, начиная с текущей позиции пера, и переводит ее в последнюю точку, переданную в параметрах функции. Для рисования п кривых функция PolyBezierTo должна получить jxn точек. На рис. 8.10 изображена обычная кривая Безье с двумя контрольными точками, расположенными по одну сторону от линии Р1-»Р4; координаты х всех четырех контрольных точек упорядочены по возрастанию. Изменение положения контрольных точек приводит к кардинальному изменению внешнего вида кривой. В следующем фрагменте (листинг 8.4) рисуется последовательность из пяти кривых Безье с использованием функции PolyBezier.
450 Глава 8. Линии и кривые Листинг 8.4. Рисование серии кривых Безье с использованием функции PolyBezier HPEN hRed = CreatePen(PS_DOT, 0, RGBCOxFF. 0, 0)); HPEN hBlue - CreatePen(PS SOLID. 3. RGB(0, 0, OxFF)); for (int z=0; z<=200; z+=40) int x = 50, у = 240; POINT p[4]=(x.y, x+50,y-z, x+100,y-z. POINT q[4]=(x,y. x+50,y-z, x+100.y+z. POINT r[4]=(x,y, x+170,y-z, x-20.y-z. POINT s[4]=(x.y. x+170,y-z, x-20,y+z, POINT t[4]=(x+75,y. x.y-z. x+150,y-z. SelectObject(hDC, hRed); x+150.y} x+150,y} x+150,yj x+150.y} x+75,y}; x+=160 x+=180 x+=200 x+=180 PolylineChDC. p, 4) PolylineChDC. r, 4) PolylineChDC, t. 4) PolylineChDC, q, 4); PolylineChDC, s, 4); Select0bject(hDC. hBlue); PolylineChDC, p, 4) PolylineChDC, r. 4) PolylineChDC, t. 4) PolylineChDC. q, 4); PolylineChDC. s, 4); SelectObject(hDC. GetStockObject(BLACK_PEN)); DeleteObject(hRed); DeleteObject(hBlue); Этот фрагмент показывает, как определяются кривые Безье разной формы. У кривых первой группы контрольные точки лежат на одной стороне от линии, а у кривых второй группы они лежат на разных сторонах. В третьей группе значения координат х двух контрольных точек меняются местами, а четвертая группа совмещает признаки второй и третьей. Наконец, в последней группе позиции двух конечных точек совпадают. Результат работы этого фрагмента с пояснительными метками показан на рис. 8.11. Р2, рз . Р2, Р2 РЗ- /' РЗ Рис. 8.11. Галерея кривых Безье
Кривые Безье 451 С точки зрения применения перьев функции PolyBezier и PolyBezierTo аналогичны Polyline и PolylineTo. Простые перья используют режим заполнения и цвет фона для стилевых линий, геометрические и косметические перья всегда рисуют в прозрачном режиме, не обращая внимания на цвет и режим заполнения. При рисовании нескольких кривых внешний вид стыков определяется атрибутом соединения, конечные точки снабжаются завершениями, а весь вывод выполняется за одну операцию, при этом никакие части изображения не рисуются дважды. Poly Draw Функции PolyBezier и PolyBezierTo рисуют только непрерывные кривые Безье. В Windows NT/2000 GDI появилась новая функция PolyDraw, обладающая расширенными возможностями — она позволяет рисовать разъединенные линии, кривые Безье и даже замкнутые фигуры. BOOL PolyDrawCHDC hDC. CONST POINT * lppt, CONST BYTE * IpbTypes. int nCount); Функция PolyDraw получает два массива: параметр lppt содержит массив точек, а параметр 1 pbTypes — массив типов точек (по одному элементу для каждой точки первого массива). Пять допустимых типов точек перечислены в табл. 8.4. Таблица 8.4. Типы точек, используемые функциями PolyDraw и GetPath Тип Описание PTM0VET0 Начать новую отдельную фигуру. Текущая позиция пера перемещается в заданную точку PTLINET0 Провести линию от текущей позиции к заданной точке и обновить текущую позицию PTLINET01PTCLOSEFIGURE То же, что и PTLINET0, с замыканием фигуры от заданной точки к последней позиции PT_M0VET0 PTBEZIERTO Нарисовать кривую Безье, используя текущую позицию пера и три точки массива, начиная с заданной. У двух следующих точек также должен быть установлен флаг PTBEZIERTO. Текущая позиция пера перемещается в третью точку PTBEZIERTO | PTCLOSEFIGURE Последняя точка PTBEZIERTO соединяется с последней позицией PT_M0VET0 Функция PolyDraw обладает некоторыми выдающимися возможностями. Во- первых, она позволяет комбинировать кривые Безье с прямыми линиями. Хотя любую прямую можно преобразовать в кривую Безье, добавив две контрольные точки на самой линии, подобные преобразования выглядят неестественно. Во- вторых, PolyDraw позволяет нарисовать несколько отдельных фигур за один вызов. Как говорилось выше, рисование нескольких линий или кривых за один вызов функции гарантирует, что ни один пиксел не будет прорисован дважды,
452 Глава 8. Линии и кривые что бывает существенно при рисовании сложных фигур с использованием режима R2X0RPEN в графическом пакете. В-третьих, функция PolyDraw позволяет замыкать фигуры автоматическим соедршением конечной точки с начальной, что весьма удобно для приложений. При рисовании замкнутых фигур геометрическим пером завершения не используются; даже конечная точка оформляется соединением, чтобы фигура выглядела более гладкой. Фрагмент кода, приведенный в листинге 8.5, двумя разными способами рисует фигуру, состоящую из горизонтальной «восьмерки» и ромба. Для вывода используется утолщенное однородное геометрическое перо с плоским завершением и заостренным соединением; рисование осуществляется в режиме R2X0RPEN. В первой части программы «восьмерка» рисуется функцией PolyBezier, а ромб — функцией Polyline. Хотя обе фигуры замкнуты, в конечных точках видны заметные дефекты стыковки, а пересечения фигур окрашены в белый цвет. Во второй части две замкнутые фигуры рисуются простым вызовом PolyDraw, что решает обе проблемы. Результат показан на рис. 8.12. Листинг 8.5. Использование функции PolyDraw при рисовании замкнутых фигур const POINT P[12] - { 50, 200. 100. 50, 150. 350. 200. 200. 150. 50. 100. 350. 50. 200. 125. 275. 175. 200. 125. 75. 200. 125, 275 }: const BYTE T[12] = { PT_M0VET0. PT_BEZIERTO. PTJEZIERTO. PT_BEZIERTO. PT_BEZIERTO. PT_BEZIERTO. PT_BEZIERTO | PT_CLOSEFIGURE. PT_M0VET0. PT_LINET0. PT_LINETO. PT_LINET0. PT_LINET0 | PT_CLOSEIGURE }: SetR0P2(hDC. R2J0RPEN): LOGBRUSH logbrush = { BS_S0LID. RGB(0xFF. OxFF. 0). 0 }; HPEN hPen = ExtCreatePen(PS_GEOMETRIC | PS_S0LID | PS_ENDCAP_FLAT| PS_JOIN_MITER. 15. & logbrush. 0. NULL); SelectObjectChDC. hPen); PolyBezier(hDC. P. 7); // Две кривые Безье Polyline(hDC. P+7, 5); // Ромб SetViewportOrgEx(hDC. 200. 0. NULL); PolyDraw(hDC. P, T. 12); // Обе фигуры SetViewportOrgEx(hDC. 0. 0. NULL); SelectObject(hDC. GetStockObject(BLACK_PEN)); DeleteObject(hPen); К сожалению, в Windows 95/98 эта замечательная функция не поддерживается. В статье Q135059 MSDN Knowledge Base приведена возможная реализация PolyDraw для Windows 95, основанная на использовании функций MoveToEx, LineTo и PolyBezierTo. Предлагаемый код обладает рядом недостатков — он не pea-
Кривые Безье 453 лизует PTCLOSEFIGURE, использует множественные вызовы функций, приводящие к многократной прорисовке фрагментов изображения, и применяет завершения для геометрических перьев. В правильной реализации следует воспользоваться траекториями GDI, которые могут состоять из нескольких отдельных фигур с завершениями и соединениями. Объекты траекторий рассматриваются ниже в этой главе. Рис. 8.12. Использование функции PolyDraw при рисовании замкнутых фигур Альтернативное определение кривых Безье В стандартном определении кривой Безье используются две конечные и две контрольные точки. Такое определение весьма наглядно с геометрической точки зрения, поэтому оно хорошо подходит для интерактивных манипуляций. Однако с точки зрения программиста кривую было бы удобнее определять по точкам, расположенным на кривой, без контрольных точек. В частности, для кубических кривых Безье часто возникает вопрос — как определить по четырем точкам А, В, С, D кривую, которая бы проходила через точку А при t = О, через точку В при t = 1/3, через точку С при t = 2/3 и через точку D при t = 1? Проблема сводится к вычислению по известным А, В, С и D четырех точек Р1, Р2, РЗ и Р4, где точки Р1 и Р4 находятся на концах кривой, а точки Р2 и РЗ соответствуют контрольным точкам. В соответствии с параметрическим определением кривой Безье мы получаем следующую систему линейных уравнений: А - Р1 В = (2/ЗГЗ Р1 + 3(2/3)^2(1/3) Р2 + 3(2/3)(1/3)А2РЗ + Р4 С = (1/ЗГЗ Р1 + 3(1/2)^2(2/3) Р2 + 3(1/3)(2/ЗГ2РЗ + Р4 D = Р4 С точками Р1 и Р4 все просто. Уравнения для точек В и С преобразуются к виду: 12Р2 + 6РЗ = 27В - 8А - D 6Р2 + 12РЗ = 27С - А - 8D Решая эту систему уравнений для переменных Р2 и РЗ, мы получаем решение: PI - A Р2 - (- 5А + 18В - 9С + 2D)/6 РЗ = ( 2А - 9В + 18С - 5D) / 6 Р4 - D
454 Глава 8. Линии и кривые Эти формулы также убедительно доказывают, что для любых четырех точек на плоскости существует кривая Безье, проходящая через них при И 0, 1/3, 2/3 и 1. Дуги Из всех кривых наибольшей известностью пользуется эллипс, частным случаем которого является окружность. В простейшем случае оси эллипса параллельны осям координат. Эллипс определяется следующим уравнением: (х-хОГ2/аА2 + (у-уО)А2/ЬА2 = 1 Здесь (хО,уО) — центр эллипса, а а и Ъ — главная и вспомогательная оси. Благодаря простоте этого уравнения эллипсы или любые фигуры, созданные на их основе, очень просто представляются в GDI. В GDI эллипс определяется ограничивающим прямоугольником (хО - а,уО - Ь, хО + а, уО + Ь). Дуга представляет собой полный периметр эллипса или его часть. Часть периметра эллипса проще всего определяется по значениям начального и конечного углов; в этом случае дуга определяется как совокупность точек эллипса, лежащих в интервале от начального до конечного угла. Чтобы избежать вычислений с плавающей точкой, но при этом обеспечить необходимую точность, GDI использует две опорные точки (xStart,yStart) и (xEnd,yEnd), по которым легко вычисляется начальная и конечная точки дуги. Начальная точка дуги является пересечением линии, соединяющей центр эллипса (xStart,yStart) с периметром эллипса; аналогично, конечная точка дуги находится в пересечении линии «центр эллипса — (xEnd,yEnd)» с периметром эллипса. Следующие три функции GDI предназначены для рисования дуг: BOOL ArcCHDC hDC, int nLeft. int nTop, int nRight, int nBottom, int xStart. int nYStart, int nXEnd, int nYEnd); BOOL ArcToCHDC hDC, int nLeft, int nTop. int nRight. int nBottom, int xStart. int nYStart, int nXEnd, int nYEnd); BOOL AngleArc(HDC hDC, int X, int Y, DWORD dwRadius. FLOAT eStartAngle. FLOAT eSweepAngle); Для функций Arc и АгсТо параметры nLeft, nTop, nRight и nBottom задают ограничивающий прямоугольник эллипса, частью которого является дуга. Центр эллипса совпадает с центром прямоугольника. Следующие четыре параметра используются для вычисления начального и конечного углов дуги. Функция Arc рисует дугу от начального до конечного угла. В Windows 95/9 дуга рисуется против часовой стрелки; в Windows NT/2000 направление дуги определяется флагом контекста устройства (GetArcDi recti on, SetArcDi recti on). Первые две дуги на рис. 8.13 поясняют смысл параметров Агс/АгсТо и показывают, как направление рисования влияет на вывод. Функция Arc не использует и не обновляет текущую позицию пера. С функцией АгсТо дело обстоит несколько иначе — она проводит линию из текущей позиции пера в настоящую начальную точку дуги, после чего рисует дугу. После завершения дуги текущая позиция пера перемещается в конечную точку дуги.
Дуги 455 Arc, против часовой стрелки АгсТо, по часовой стрелке AngleArc Слева, сверху Слева, сверху (xStart, yStart) (xStart, yStart) (xEnd, yEnd) Снизу, справа (xEnd, yEnd) eStartAngle eStartAngle + eSweepAngle Снизу, справа Снизу, справа Рис. 8.13. Определение дуг в GDI Функции Arc и АгсТо позволяют нарисовать полный периметр эллипса; для этого достаточно задать конечную точку, совпадающую с начальной. Чтобы нарисовать часть эллипса, не входящую в заданную дугу, достаточно поменять местами начальную и конечную точки. На случай, если вам вдруг понадобится вычислить позицию начальной или конечной точек, ниже приведены формулы для начальной точки: ХО - (nLeft + nRight)/2; // Центр эллипса Y0 - (nTop + nBottom)/2; DXs = nXStart - ХО; DYs - nYStart - YO; Ds - sqrt(DXs * DXs + DYx * DYx); // Расстояние от центра Xs - ХО + (nRight-nLeft)/2 * DXs / Ds; Ys - YO + (nBottom-nTop)/2 * DYs / Ds; Определение дуги в градусах: функция AngleArc Функция AngleArc, поддерживаемая только в ОС семейства NT, нарушает общий принцип — избегать вещественных вычислений. Она получает начальный угол дуги и ее угловой размер в градусах (не в радианах!) в виде вещественных чисел. Угловой размер дуги указывает и ее направление, поэтому атрибут направления дуг контекста устройства в этом случае не используется. Другая особенность AngleArc заключается в том, что вы можете задать только радиус круга в логическом координатном пространстве. Чтобы нарисовать часть эллипса, приложение должно определить соответствующее преобразование или отображение. Функция AngleArc, как и АгсТо, проводит отрезок от текущей позиции пера к начальной точке дуги и перемещает текущую позицию в конечную точку дуги. Непонятно лишь одно — почему эта функция не называется AngleArcTo? При использовании AngleArc полный эллипс рисуется очень просто: достаточно нарисовать дугу с угловым размером 360 градусов. А что будет, если нарисовать дугу в 540 градусов? В MSDN утверждается, что если угловой размер дуги превышает 360 градусов, дуга рисуется несколько раз. Отсюда следует, что в режиме R2_X0RPEN 540-градусная дуга сначала нарисует 360-градусный полный круг, а затем добавит дугу в 180 градусов, восстанавливающую исходный фон, так что в
456 Глава 8. Линии и кривые итоге вы получите 180-градусную дугу. Наши эксперименты показали, что если угловой размер превышает 360 градусов, полная окружность рисуется всего один раз. Функция Angl еАгс легко реализуется на базе функции АгсТо; эта возможность может пригодиться на платформах, не входящих в семейство NT. Примерная реализация выглядит так: BOOL AngleArcTo(HDC hDC, int X. int Y. DWORD dwRadius, FLOAT eStartAngle, FLOAT eSweepAngle) { const FLOAT pioverl80 - (FLOAT) 3.141592653586/180; if ( eSweepAngle >= 360) // Если угол больше 360 градусов - eSweepAngle = 360; // оставить полную окружность else if (eSweepAngle <= -360 ) eSweepAngle = -360; FLOAT eEndAngle = (eStartAngle + eSweepAngle ) * pioverl80; eStartAngle = eStartAngle * pioverl80; int dir; // Угловой размер дуги определяет направление if (eSweepAngle > 0) dir = SetArcDirecti on(hDC, AD_COUNTERCLOCKWISE); else dir = SetArcDirecti on(hDC. AD_CLOCKWISE); // Угол задается в системе координат устройства BOOL rslt = ArcTo(hDC. X - dwRadius, Y - dwRadius. X + dwRadius. Y + dwRadius. X + (int) (dwRadius * 10 * cos(eStartAngle)), Y - (int) (dwRadius * 10 * sin(eStartAngle)), X + (int) (dwRadius * 10 * cos(eEndAngle)). Y - (int) (dwRadius * 10 * sin(eEndAngle))); SetArcDirecti on(hDC. dir); return rslt; } Функция удостоверяется в том, что размер рисуемой дуги не превышает полной окружности, преобразует градусы в радианы, задает направление дуги в соответствии со знаком углового размера, вычисляет начальную и конечную точки (при этом радиус круга умножается на 10 для повышения точности) и затем рисует дугу функцией АгсТо. Рисование дуг пером со стилем PS__INSIDEFRAME Поскольку дуги ограничиваются прямоугольниками и внутренняя сторона дуги легко отличается от внешней, GDI учитывает стиль пера PSINSIDEFRAME. Если перо с этим стилем используется для рисования дуги, центральная линия кривой смещается внутрь на половину толщины пера. Внешние пикселы линии соприкасаются с ограничивающим прямоугольником, а остальные пикселы рисуются внутри прямоугольника. При выводе дуг применение пера со стилем PS_ INSIDEFRAME реализуется очень просто — достаточно уменьшить ограничивающий прямоугольник на половину толщины пера. Сделать то же самое в общем случае (например, для замкнутой серии кривых Безье) гораздо сложнее.
Дуги 457 Следует заметить, что стиль пера PSINSIDEFRAME определяется на том же уровне, что и PSS0LID или PSD0T и не является атрибутом линии, как, например, атрибуты завершения и соединения. В результате внутренние перья всегда являются сплошными. Вероятно, это свойство следовало бы реализовать как независимый атрибут пера. Преобразование дуг в кривые Безье Вероятно, вы уже поняли, что рисование кривых является непростой задачей. Чтобы определить, какую часть периметра эллипса необходимо нарисовать, приходится использовать вычисления с плавающей точкой и разбираться с атрибутом направления дуг. Еще хуже то, что вы можете рисовать части только таких эллипсов, у которых оси параллельны осям логической системы координат. Если вы захотите нарисовать дугу после поворота или сдвига, вам придется вычислить нужное преобразование, причем в ОС, не входящих в семейство NT, эта возможность не поддерживается. На помощь приходят кривые Безье. Операции с ними очень просты, а вычисления в процессе рисования достаточно элементарны. В результате аффинных преобразований кривая Безье отображается в кривую Безье, причем результат всегда однозначен, поскольку четыре точки определяют ровно одну кривую. Остается единственный вопрос — как построить кривую Безье, аппроксимирующую эллиптическую дугу? Аппроксимация полной окружности одной кривой Безье обладает слишком высокой погрешностью. Даже представление половины окружности одной кривой Безье не гарантирует достаточной точности. Давайте попробуем вычислить позиции контрольных точек для кривой Безье, аппроксимирующей четверть окружности (90 градусов). Для четверти единичной окружности, расположенной в первом квадранте декартовой системы координат, нам известны конечные точки (0,1) и (1,0). 90-градусная дуга симметрична относительно линии X = Y, поэтому две контрольные точки тоже должны быть симметричными. Мы знаем, что линия, проведенная из начальной точки в первую контрольную точку, является касательной к дуге в начальной точке. Это означает, что линия должна проходить под углом 0 градусов, то есть первая контрольная точка должна иметь координаты (т,1) для неизвестной переменной т. По свойству симметрии вторая контрольная точка должна иметь координаты (1,/и). Итак, нам известны все четыре контрольные точки Р1:(0Д), Р2:(етг,1), Р3(1,га) и Р4(1,0); остается лишь найти неизвестную переменную т. На рис. 8.14 показана 90-градусная дуга единичной окружности в первом квадранте. Светлая ломаная соединяет четыре точки кривой Безье, которую мы пытаемся найти. Шесть светлых кривых показывают аппроксимации кривой Безье при изменении т от 0 до 1,0 с шагом 0,2. Темная кривая изображает аппроксимируемую дугу. Средняя точка кривой вычисляется подстановкой значения t = 0,5 в формулу из предыдущего раздела: Р(0,5) = (l-t)A3Pl + 3(l-t)A2tP2 + 3(l-t)tA2P3 + ГЗР4 = (PI + 3P2 + ЗРЗ + P4)/8
458 Глава 8. Линии и кривые (ОЛ) (т,1) т=0.552285, еггог(0.211) = +0.027253% Рис. 8.14. Преобразование 90-градусной дуги в кривую Безье Если вычислить по этой формуле среднюю точку кривой (0,1), (ти,1), (1,^0 и (1,0), мы получаем: Xmid = (0+3m+3+l)/8 - (3m + 4)/8 Ymid « (l+3+3m+l)/8 - (3m + 4)/8 Известно, что в единичном круге точка (Xmid,Ymid) имеет координаты (л/2/2, л/2/2), поэтому т = 4(л/2 - 1)/3 или приблизительно т = 0,552285. Если воспользоваться четырьмя такими кривыми Безье для аппроксимации полного эллипса, на всех углах, кратных 45 градусам, кривая Безье будет точно совпадать с кругом. Остается лишь понять, насколько близко она будет располагаться к остальным точкам? Изменяя t в интервале от 0 до 0,5 с небольшим приращением, мы можем получить координаты точек кривой Безье, вычислить их расстояние от начала координат и сравнить его с расстоянием для единичного круга. Наибольшая относительная погрешность составляет 0,027253 % и достигается при t = 0,211. Каков же размер этой погрешности в пикселах? При рисовании эллипса, занимающего весь экран (размеры которого обычно не превышают 1600 х 1200 пикселов), аппроксимация четырьмя кривыми Безье в худшем случае отклоняется от истинной кривой на 0,436 пиксела. В листинге 8.6 приведены две функции. Первая функция, EllipseToBezier, рисует полный эллипс, аппроксимированный кривыми Безье. Она вычисляет 13 определяющих точек для четырех кривых Безье, используя описанный выше
Дуги 459 способ. Вторая функция, AngleArcToBezier, рисует дугу с произвольными начальным и конечным углами, аппроксимируя ее одной кривой Безье. Листинг 8.6. Рисование периметра эллипса с использованием кривых Безье BOOL El IipseToBezier(HDC hDC, int left, int top. int right, int bottom) { const double M = 0.55228474983; POINT P[13]: int dx - (int) ((right - left) * (1-M) / 2); int dy - (int) ((bottom - top) * (1-M) / 2); P[ 0].x = right; // P[ 0].y - (top+bottom)/2; // 4 3 2 P[ l].x - right; // P[ l].y - top + dy; // 5 1 P[ 2].x = right - dx; // P[ 2].у = top; // 6 0,12 P[ 3].x = (left+right)/2: // P[ 3].y = top; // 7 11 // P[ 4].x = left + dx; // 8 9 10 P[ 4].у = top; P[ 5].x « left; PC 5].у = top + dy; P[ 6].x = left; P[ 6].у = (top+bottom)/2; P[ 7].x - left; P[ 7].у = bottom - dy; P[ 8].x - left + dx; P[ 8].у - bottom; P[ 9].x - (left+right)/2: P[ 9].у - bottom; P[10].x = right - dx; P[10].y - bottom; P[ll].x - right; P[ll].y - bottom - dy; P[12].x - right; P[12].y - (top+bottom)/2; return PolyBezier(hDC. P. 13); } BOOL AngleArcToBezier(HDC hDC, int xO, int yO, int rx, int ry, double startangle. double sweepangle, double * err) { double XY[8]; POINT P[4]; // Рассчитать кривую Безье для дуги, Продолжение &
460 Глава 8. Линии и кривые Листинг 8.6. Продолжение // симметричной относительно оси х // Против часовой стрелки: (О.-В), (х.-у). (х.у), (О,В) double В = ry * sin(sweepangle/2); double С = rx * cos(sweepangle/2); double A = гх - С; double X = A*4/3; double Y = В - X * (rx-A)/B; XY[0] = C: XY[1] = - B; XY[2] = OX; XY[3] = - Y; XY[4] = C+X; XY[5] « Y; XY[6] = C; XY[7] = B; // Вернуться к исходному углу double s = sin(startangle + sweepangle/2); double с = cos(startangle + sweepangle/2); for (int i=0; i<4; i++) { P[i].x = xO + (int) (XY[i*2] * с - XY[i*2+l] * s); P[i].y = yO + (int) (XY[i*2] * s + XY[i*2+l] * c); return PolyBezier(hDC. P. 4); } Метод преобразования дуги в кривую Безье, используемый функцией Ellipse- ToBezier, не подходит для произвольных дуг; он предназначен для аппроксимации дуг с угловым размером, кратным 90°. Функция AngleArcToBezier использует новый метод аппроксимации произвольной дуги кривой Безье, хотя в тех случаях, когда угловой размер превышает 90°, следует ожидать увеличения ошибок. Функция сначала поворачивает дугу, обеспечивая ее симметричность относительно оси х\ в результате половина дуги находится выше линии у = 0, а другая половина — ниже этой линии. Такое положение дуги существенно упрощает формулы для вычисления контрольных точек. После вычисления контрольные точки поворотом возвращаются в исходную позицию. С увеличением углового размера дуги значительно возрастает относительная погрешность аппроксимации. При угле 45° погрешность равна 0,00042 %; при 90° она возрастает до 0,02725 %, а при 180° ошибка составляет уже 1,835 %. Однако настоящая «прелесть» аппроксимации дуг кривыми Безье заключается в том, что с контрольными точками кривой можно выполнять преобразования и рисовать нестандартные дуги без применения мировых преобразований GDI, поддерживаемых только на платформах семейства Windows NT. Кроме того, свойство делимости кривых Безье позволяет легко реализовать новые стили линий, не поддерживаемые в GDI и в семействе Windows 95/98. Также обратите внимание на то, что при преобразовании дуги в кривые Безье перо со сти-
Траектории 461 лем PSINSIDEFRAME работает так же, как и обычные перья со стилем PSSOLID. Если вы хотите, чтобы линия размещалась внутри контура, уменьшите ограничивающий прямоугольник перед тем, как выполнять преобразование. Траектории При выводе линий и кривых средствами GDI API необходимы два источника информации — перо и другие атрибуты контекста, определяющие внешний вид линий и кривых, а также геометрическое описание (то есть координаты точек, через которые проходит линия, и их типы). Хорошо спроектированная графическая система должна по отдельности обрабатывать эти два информационных компонента, чтобы обеспечить максимальную гибкость. Для работы с перьями используются объекты перьев GDI, а объекты контекста устройства управляют другими внешними атрибутами линий и кривых. Остается лишь найти средства для геометрического Описания линий. Так мы приходим к объектам траекторий. Траекторией (path) называется объект GDI, описывающий геометрические формы. Точнее, траектория описывает упорядоченную последовательность замкнутых или разомкнутых фигур, которые представляют собой упорядоченные последовательности линий и кривых. Объекты траекторий принадлежат к числу объектов GDI, поэтому каждой траектории соответствует манипулятор GDI и запись в таблице объектов GDI. Однако в отличие от других стандартных объектов GDI (логических перьев, контекстов устройств и т. д.), объекты траекторий остаются скрытыми от пользователей. На уровне GDI объект траектории всегда связывается с контекстом устройства и не может существовать отдельно от него. Создание, модификация, выбор, использование и уничтожение траектории выполняется GDI при вызове специальных функций. Для работы с траекториями в GDI существуют следующие функции: BOOL BeginPathCHDC hDC); BOOL EndPath(HDC hDC); BOOL AbortPath(HDC hDC); BOOL CloseFigure(HDC hDC); int GetPath(HDC hDC, PPOINT pPoints, PBYTE pTypes. int nCount); BOOL FlattenPath(HDC hDC); BOOL WidenPath(HDC hDC); -BOOL StrokePathCHDC hDC); BOOL StrokeAndFillPath(HDC hDC); BOOL FillPath(HDC hDC); HRGN PathToRegion(HDC hDC): BOOL SelectClipPathCHDC hDC, int iMode); Построение траектории Прежде чем использовать траекторию, сначала ее необходимо построить. Функция BeginPath инициирует построение траектории в контексте устройства. Контекст переходит в режим построения траектории, сбрасывает объект траектории, неявно связанный с контекстом, и инициализирует его пустым объектом. Когда контекст устройства находится в режиме построения траектории, все функции,
462 Глава 8. Линии и кривые которые могут потребоваться при построении траектории, не рисуют в контексте устройства; вместо этого их вызовы добавляются в объект траектории, связанный с контекстом устройства. При построении траектории могут использоваться только функции GDI, создающие линии и кривые; вызовы остальных функций передаются на поверхность устройства. В табл. 8.5 перечислены функции, используемые при конструировании траекторий. Обратите внимание: функции заполнения областей и даже функции вывода текста тоже генерируют линии и кривые, поэтому они включаются в траекторию. Таблица 8.5. Функции построения траекторий Функция Описание Ограничение Angl eArc, Arc, АгсТо Ellipse, Chord, Pie CloseFigure ExtTextOut, TextOut Li neTo MoveToEx PolyBezier, PolyBezierTo PolyDraw Polygon, PolyPolygon Polyline, PolylineTo, PolyPolyline Rectangle RoundRect Добавляет в траекторию линию и дугу (функция Arc — только дугу) Добавляет полный периметр эллипса, сектор или сегмент Последняя точка помечается флагом замыкания фигуры Контуры символов добавляются как отдельные замкнутые фигуры Добавляет линию Начинает новую фигуру Добавляет линию и несколько кривых Безье (функция PolyBezier — только кривые Безье) Добавляет серию фигур Добавляет один или несколько многоугольников как отдельные замкнутые фигуры Добавляет одну или несколько ломаных Добавляет прямоугольник как новую замкнутую фигуру Добавляет замкнутую фигуру из четырех линий и четырех дуг Только в семействе NT Только в семействе NT Не поддерживается для растровых шрифтов Только в семействе NT Только в семействе NT Все функции, перечисленные в таблице, так или иначе выводят кривые и линии, включаемые в объект траектории. Функции вывода пикселов (например, SetPixel) линий не выводят, поэтому в таблице они отсутствуют. Понять, как при построении траектории используются такие функции, как LineTo, Polyline, Pol yli neTo, PolyPolyline, PolyBezier, PolyBezierTo, PolyDraw, Arc, АгсТо и Angl eArc, очень просто. Объекты перьев обычно не влияют на построение траекторий, по-
Траектории 463 скольку траектория отражает лишь геометрическую форму линий и кривых; исключение составляют функции рисования дуг пером со стилем PSINSIDEFRAME, при использовании которых ограничивающий прямоугольник дуги уменьшается на половину толщины пера. Обратите внимание: в системах, не входящих в семейство NT, функции PolyDraw, Arc, АгсТо и AngleArc либо не реализованы, либо их использование при построении траекторий недопустимо. Чтобы ваша программа работала на разных платформах, при включении таких фигур в траекторию их можно преобразовать в кривые Безье. Вторую категорию функций построения траекторий составляют функции GDI, выполняющие заливку областей, — например, функции Ellipse, Chord, Pie, Polygon, Rectangle и RoundRect. В общем случае эти функции закрашивают кистью замкнутую область и обводят ее контур пером. Подробности будут рассмотрены в главе 9, а пока достаточно запомнить, что эти функции определяют замкнутые геометрические фигуры (одну или несколько). Когда указанные функции вызываются в контексте устройства, находящемся в режиме построения траектории, эти геометрические фигуры включаются в текущую траекторию этого контекста. Третью категорию функций построения траекторий составляют функции вывода текста. В Windows используются три типа шрифтов: растровые (описываются растровыми изображениями), векторные (описываются прямыми линиями) и шрифты TrueType, описываемые линиями и кривыми Безье. Если в режиме построения траектории вызывается функция вывода текста для векторного шрифта или шрифта TrueType, контур глифа включается в текущую траекторию. Помимо этих трех категорий функций, в GDI существует специальная функция CloseFigure. Вся ее работа сводится к тому, что последняя точка помечается флагом замыкания. Пометка указывает на то, что эта точка должна быть соединена линией с начальной точкой фигуры, причем для геометрического пера стык должен быть оформлен в соответствии с атрибутом соединения, а не завершения. Рассмотрим небольшой пример построения траектории. В следующем фрагменте рисуются два эллипса с одинаковыми координатами; первый эллипс рисуется пером по умолчанию, а второй — пером толщиной в 21 единицу со стилем PS_INSIDEFRAME. Если перо по умолчанию не совпадает с внутренним пером толщиной в 21 единицу, построенная траектория состоит из двух концентрических кругов. BeginPath(hDC); Ellipse(hDC. О, 0, 100, 100): HPEN hPen = CreatePen(PS_INSIDEFRAME, 21. RGBCOxFF, 0. 0)); HPEN hOld - (HPEN) SelectObject(hDC. hPen); EllipseChDC, 0. 0, 100, 100); SelectObject(hDC, hOld): DeleteObject(hPen); EndPath(hDC); Получение информации о траектории Если построение траектории прошло успешно, после вызова EndPath приложение может получить описание траектории при помощи функции GetPath GDI.
464 Глава 8. Линии и кривые В графическом механизме объект траектории представляется довольно сложной структурой данных, которая обеспечивает экономию памяти, но при этом допускает простое увеличение размеров. ПРИМЕЧАНИЕ Структура данных траектории в Windows NT/2000 подробно описана в главе 3 (раздел «WinDbg и расширение отладчика GDI»). Функция GetPath преобразует внутреннее представление траектории, используемое GDI, в два массива: массив точек и массив флагов. В массиве точек хранятся координаты всех вершин и контрольных точек, определяющих траекторию. Для каждого элемента массива точек имеется соответствующий элемент в массиве флагов. Для каждой точки флаги сообщают, принадлежит ли данная точка линии или кривой Безье, является ли она начальной или конечной точкой фигуры. Допустимые флаги перечислены в табл. 8.4. Структура данных, возвращаемая GetPath, имеет такой же формат, как структура данных, передаваемая PolyDraw. Но куда же делись эллиптические кривые? Флага точки для эллиптической кривой не существует. Эти кривые преобразуются в кривые Безье способом, похожим на описанный в разделе «Дуги». Функция GetPath возвращает точки в логической системе координат. Во внутреннем представлении точки траектории хранятся в координатах устройства в формате с фиксированной точкой, обеспечивающем максимальную точность. При вызове GetPath GDI при помощи матрицы, обратной по отношению к матрице преобразования мировых координат в координаты устройства, вычисляет координаты точек траектории в логическом пространстве. Учтите, что логические координаты представляются целыми числами. Следовательно, если преобразование из логических координат в координаты устройства сопровождается значительным масштабированием, при возвращении данных GetPath может произойти потеря точности. Вызов GetPath сопряжен с некоторыми трудностями, поскольку вызывающая сторона должна выделить память для двух массивов неизвестного размера. Как это обычно бывает в Win32 API, функция GetPath вызывается дважды: в первый раз она возвращает количество точек, а во второй раз выделенные массивы заполняются настоящими данными. Приложение также может создать два массива разумных размеров в стеке, вызвать GetPath и возиться с динамическим выделением памяти лишь в том случае, если вызов завершится неудачей (это позволяет избежать дорогостоящих операций выделения памяти из кучи). Эвристическое правило рекомендует выделять в стеке блоки фиксированных размеров, которые бы подходили для 80 % случаев, и выделять память из кучи в оставшихся 20 %. В приведенном ниже классе KPathData реализован первый способ. Класс содержит две переменные для хранения двух массивов, возвращаемых при вызове GetPath. Метод GetPathData сначала вызывает GetPath для получения количества точек. После выделения блока памяти необходимого размера функция GetPath вызывается снова для получения настоящих данных траектории. Функция Магк- Points рисует рядом с каждой точкой небольшой маркер, обозначающий ее тип.
Траектории 465 class KPathData { public: POINT * m_pPoint; BYTE * m_pFlag; i nt mjnCount : KPathDataО { m_pPoint = NULL; m_pFlag = NULL; m_nCount = 0; } -KPathDataО { if ( m_pPoint ) delete m_pPoint; if ( m_pFlag ) delete m_pFlag; } int GetPathData(HDC hDC) { if ( m_pPoint ) delete m_pPoint; if ( m_pFlag ) delete m_pFlag; mjiCount = ::GetPath(hDC, NULL, NULL. 0); if ( m_nCount>0 ) { m_pPoint = new POINT[m_nCount]; m__pFlag = new BYTE[m_nCount]; if ( m_pPoint!=NULL && m_pFlag!=NULL ) m_nCount - ::GetPath(hDC, m_pPoint. m_pFlag, m_nCount); else m_nCount = 0; } return m_nCount; } void MarkPoints(HDC hDC, bool b$howLine=true); }: Функция GetPath помогает разобраться в том, как в GDI реализованы различные функции вывода линий и кривых, поскольку с ее помощью можно увидеть данные траектории. Например, если вы хотите узнать, как AngleArc преобразуется в кривые Безье, попробуйте выполнить следующий фрагмент: BeginPath(hDC); MoveToEx(hDC, 0. 0. NULL); AngleArc(hDC. 0, 0. 150. 0. 135); POINT P[] = { -75. 20, -20. -75. 40. -40 }; PolyBezier(hDC, P. 3); CloseFigure(hDC); EndPath(hDC); KPathData org; org.GetPathData(hDC);
466 Глава 8. Линии и кривые Между вызовами BeginPath и EndPath выполняются четыре вызова функций GDI. Функция MoveToEx переводит текущую позицию курсора в начало координат, AngleArc рисует 135-градусную дугу, PolyBezier подрисовывает к дуге кривую Безье, и функция CloseFigure замыкает фигуру. После вызова GetPathData можно просмотреть данные траектории в окне отладчика, вывести их в текстовый файл или снабдить точки графическими пометками на экране. Слева на рис. 8.15 изображена траектория, определяемая приведенным выше фрагментом. Вывод осуществлялся функцией PolyDraw для данных, возвращаемых GetPath. Справа изображены точки и флаги, возвращаемые функцией GetPath. Начальная точка фигуры помечена треугольником, точки линий — прямоугольниками, точки кривых Безье — кругами, а точка замыкания фигуры обозначается закрашенным маркером. .о о оч о" о —""^ *> \ \ / ^ ч# i 4— J \/ Дг 6 о Рис. 8.15. Траектория и данные траектории, возвращаемые функцией GetPath Из рисунка видно, что AngleArc проводит линию от текущей позиции пера (0,0) в начальную точку дуги (150,0); 135-градусная дуга представляется двумя кривыми Безье. Первая кривая Безье рисует начальную 90-градусную дугу, а вторая кривая рисует оставшиеся 45°. Также рисунок показывает, что функция CloseFigure не включает дополнительный отрезок в данные траектории, а всего лишь устанавливает флаг для последней точки. В документации Microsoft нет четкого определения того, где должен находиться флаг РТ CLOSEFIGURE. Иногда он ошибочно приписывается первой контрольной точке кривой Безье. Но если проанализировать данные, возвращаемые GetPath, все становится абсолютно ясно — флаг PT_CL0SEFIGURE должен устанавливаться для последней точки фигуры. Данные, полученные от GetPath, можно непосредственно передать функции PolyDraw, как это было сделано для построения левой части рисунка. Это чрезвычайно полезная возможность, особенно если учесть, что GDI не предоставляет приложениям манипулятора траектории. Приложение может сохранить данные траектории и использовать их в будущем. Если вы хотите нарисовать точки вместо кривых (например, с целью редактирования), возвращаемый массив точек можно передать функции Polyline, как это было сделано на правой части рисунка. Перед тем как передавать данные GDI, их можно подвергнуть любым преобразованиям. Помните о том, что GDI поддерживает только аффинные преобра-
Траектории 467 зования в системах семейства NT, а в других системах мировые преобразования вообще не поддерживаются. Реализовать преобразования для рисования линий и кривых несложно. Для аффинных преобразований, отображающих линии в линии, достаточно преобразовать все контрольные точки, а затем провести вывод с теми же флагами. Для не-аффинных преобразований, которые могут отображать линии в кривые, для повышения точности вам, возможно, придется разбить линии и кривые на сегменты меньших размеров. Преобразование объекта траектории В GDI для объектов траекторий определены два преобразования: замена криволинейных участков прямолинейными и утолщение линий. Функция Fl attenPath преобразует все кривые объекта траектории в последовательность отрезков, обеспечивающих приемлемую аппроксимацию кривой в логическом координатном пространстве. Функция FlattenPath ограничивается преобразованием кривых Безье. При этом используется рекурсивный алгоритм вроде приведенного в листинге 8.3: кривая делится надвое до тех пор, пока погрешность не станет незначительной. Название функции создает неверное впечатление, будто она приводит к значительному искажению кривой. На самом деле функция FlattenPath обеспечивает наилучшую аппроксимацию в логических координатах. Конечно, целочисленное представление приводит к некоторой потере точности, но если результат не масштабируется с большим коэффициентом, различия практически незаметны. Если результат должен выводиться в контексте устройства с высоким разрешением, приложение может увеличить разрешение логического координатного пространства или реализовать собственную версию Fl attenPath с вещественными вычислениями. Функция Fl attenPath вызывается после того, как EndPath завершает построение действительной траектории. Она модифицирует текущий объект траектории в контексте устройства. Обновленный объект траектории остается выбранным в контексте и может использоваться другими функциями, работающими с траекториями (например, функцией GetPath). При достаточно сложной форме траектории аппроксимация может потребовать немалых расходов памяти. Пример использования функции FlattenPath иллюстрирует рис. 8.16. Фигура слева была нарисована функцией PolyDraw по данным, полученным в результате вызова FlattenPath; справа выведена та же фигура с маркерами точек. Левая фигура почти не отличается от фигуры на рис. 8.15, однако при взгляде на правую фигуру становится видно, что точки кривой были заменены множеством линейных точек, довольно точно воспроизводящих форму траектории. Задача преобразования кривых в прямые часто встречается на практике, поскольку с линиями работать гораздо удобнее, чем с кривыми. Не существует простых формул, которые бы позволяли вычислить длину кривой Безье по определяющим точкам. В системах автоматизированного проектирования пользователи работают с шаблонами, созданными на основе кривых Безье; преобразование кривой в набор отрезков позволяет легко вычислить ее длину. В результате линейной аппроксимации замкнутая фигура практически превращается в многоугольник, а для вычисления площади многоугольника, его ограничивающего прямоугольника и проверки пересечений существует немало готовых алгорит-
468 Глава 8. Линии и кривые мов. Информация о длине кривой также применяется при рисовании стилевых линий. Процесс рисования стилевой линии можно представить как многократное чередование вывода отрезков и промежутков фиксированной длины. В разделе «Пример: рисование нестандартных стилевых линий» показано, как линейная аппроксимация траекторий помогает строить нестандартные стилевые линии. 0и Two Regions RGN_AND RGN_OR RGN_XOR RGN_DIFF RGN_COPY Рис. 8.16. FlattenPath: линейная аппроксимация кривой Вторым средством преобразования траекторий в GDI является функция WidenPath. В документации Microsoft сказано, что WidenPath преобразует текущую траекторию в область, которая была бы закрашена при прорисовке траектории пером, выбранным в этот момент в контексте устройства. Обратите внимание: WidenPath преобразует траекторию в область. Но траектория есть траектория, как она может быть областью? Никаких пояснений на этот счет MSDN не дает. В действительности WidenPath переопределяет текущую траекторию по периметру области, которая была бы закрашена при прорисовке траектории текущим пером. Функция WidenPath работает лишь в том случае, если текущее перо не является косметическим пером, созданным функцией ExtCreatePen. Для перьев, созданных функцией CreatePen, и геометрических перьев, созданных функцией ExtCreatePen, функция WidenPath рассчитывает периметр всей области с учетом толщины пера, его стиля (включая атрибуты соединения и завершения) и углового лимита. Функция WidenPath всегда генерирует замкнутые фигуры. Кроме того, она, как и FlattenPath, преобразует кривые в линии (как говорилось выше, с линиями удобнее работать). После вызова WidenPath вызывать FlattenPath уже не нужно, однако если вызвать FlattenPath перед вызовом WidenPath, сгенерированная траектория будет содержать больше точек (и более короткие отрезки). Обратите внимание на одно важное обстоятельство (по крайней мере, в Windows NT/2000): чтобы перо действовало при вызове WidenPath, оно должно быть выбрано в контексте устройства до последнего вызова, порождающего графический вывод. Если перо было выбрано после последней графической функции, но до CloseFigure и EndPath, будет использовано предыдущее перо. На рис. 8.17 показана довольно-таки уродливая картинка, созданная функцией WidenPath. Изображения были построены для геометрического пера толщиной в 17 единиц с плоским завершением и заостренным соединением. Функция WidenPath преобразует замкнутую фигуру в две замкнутые фигуры — первая на половину толщины пера выходит за границы траектории, а вторая на такую же
Траектории 469 величину уходит внутрь. Несомненно, функция WidenPath должна преобразовывать открытую траекторию в одну замкнутую фигуру, окружающую исходную траекторию на расстоянии в половину толщины пера с каждой стороны. Если бы вместо сплошного пера использовалось стилевое перо, для каждого пунктирного отрезка или точки была бы сгенерирована отдельная замкнутая фигура. Рис. 8.17. WidenPath преобразует одну замкнутую фигуру в две замкнутые фигуры Траектория, сгенерированная функцией WidenPath, уже разбита на прямолинейные отрезки. Но похоже, что GDI при этом не ограничивается тривиальным вызовом Fl attenPath с последующим расширением траектории. Если сделать это в приложении, сгенерированная траектория будет содержать больше точек и «петель». Уродливые петли на левом рисунке появляются при соприкосновении двух толстых линий под углом менее 180°. Они соответствуют перекрывающимся зонам, которые прорисовываются двумя линиями по отдельности. Если бы результат вызова WidenPath использовался только для реализации утолщенных геометрических линий, петли были бы полностью скрыты при закраске замкнутых фигур. Но если приложение захочет воспользоваться этим результатом для рисования двух замкнутых фигур, внутренней и внешней, ему придется основательно потрудиться над чисткой траекторий. Возможно, функция WidenPath или какая-нибудь ее внутренняя реализация используется GDI для преобразования геометрических линий в закрашиваемые области. Это также объясняет, почему при определении геометрических логических перьев используется структура L0GBRUSH, как и при определении кисти. С точки зрения GDI рисование геометрическим пером является усложненной формой заливки областей. Функция WidenPath позволяет приложению получить данные траектории, которые будут использоваться GDI для рисования геометрических линий. Впрочем, Microsoft нигде не объясняет, зачем приложению могут понадобиться эти внутренние данные. Вспомните, что говорилось выше — в GDI поддерживаются только аффинные преобразования; непосредственная поддержка не-аффинных преобразований (таких, как 1-, 2- и 3-точечные преобразования перспективы) отсутствует. Отличительной особенностью геометрических линий является наличие заметной толщины. С другой стороны, нарисованная геометрическая линия имеет постоянную толщину. Трехмерное изображение должно имитировать
470 Глава 8. Линии и кривые эффект перспективы, поэтому удаленные объекты, в том числе и геометрические линии, должны уменьшаться в размерах. Функция WidenPath обеспечивает необходимое «разделение труда» между GDI и приложениями. Приложение может получить данные траектории после применения WidenPath, применить к ним преобразование перспективы или любое другое преобразование, изменяющее толщину линий, и вернуть полученную траекторию для ее закраски кистью. В результате вы получите линии с переменной толщиной. В следующем фрагменте определяется абстрактный класс для выполнения двумерных преобразований K2DMap и производный от него класс KBiLinearMap, отображающий прямоугольное окно в произвольный четырехугольник. Метод K2DMap::Map выполняет отображение отдельных точек в данные, относящиеся к траектории. class K2DMap { public: virtual Mapdong & px, long & py) = 0; }: class KBiLinearMap : public K2DMap { double xOO, yOO, xOl. yOl. xlO. ylO, xll. yll; double orgx, orgy, width, height; public: void SetWindow(int x, int y, int w. int h) { orgx = x; orgy = y: width = w; height = h; } void SetDestination(POINT P[]) { xOO = P[0].x: yOO - P[0].y: xOl = P[l].x; yOl = P[l].y: xlO - P[2].x: ylO = P[2].y: xll = P[3].x; yll = P[3].y; } virtual Mapdong & px. long & py) { double x = (px - orgx ) / width: double у = (py - orgy ) / height; px - (long) ( (1-х) * ( xOO * (1-y) + xOl * у ) + x * ( xlO * (1-y) + xll * у ) ); py - (long) ( (1-х) * ( yOO * (1-y) + yOl * у ) + x * ( ylO * (1-y) + yll * у ) ): } }:
Траектории 471 Графические операции с использованием траекторий Непосредственная прорисовка траектории выполняется несколькими функциями: StrokePath, Fill Path и StrokeAndFi 11 Path. Функция StrokePath рисует линии и кривые, входящие в текущую траекторию, используя текущее перо и угловой лимит контекста устройства. С концептуальной точки зрения работа StrokePath эквивалентна получению данных траектории функцией GetPath и вызову функции PolyDraw — нарисованные линии будут одинаковыми. Главное различие заключается в том, что GetPath и PolyDraw не изменяют траектории в контексте устройства, а функция StrokePath освобождает ее после обводки. Следовательно, после вызова StrokePath приложение должно построить новую траекторию, если она ему нужна. Существует обходное решение — вызвать функцию SaveDC перед вызовом StrokePath и RestoreDC после него. Всего одна пара функций предохраняет объект траектории от уничтожения. Не рекомендуется вызывать StrokePath после вызова WidenPath с тем же утолщенным геометрическим пером. Если утолщенное перо, использованное для расширения траектории, остается выбранным в контексте, исходная траектория будет прорисована пером двойной толщины, что приведет к появлению уродливых пробелов и увеличению петель. При использовании тонкого пера уродливые петли, порожденные функцией WidenPath, становятся хорошо заметными (как в левой части рис. 8.17). Ниже приведен небольшой фрагмент, который использует функцию WidenPath для расширения траекторий очень толстыми геометрическими перьями, а затем вызывает функцию StrokePath с тонким косметическим пером для обводки траекторий, сгенерированных функцией WidenPath: for (int i=0; i<3; i++) { const WideStyle[] = { PS_ENDCAP_SQUARE | PS_JOIN_MITER. PS_ENDCAP_ROUND | PS_J0IN_R0UND, PSJNDCAPJLAT | PSJOINJEVEL }: const ThinStyle[] - { PS_ALTERNATE, PS_D0T. PS_S0LID }; const Color [] - { RGB(0xFF, 0, 0), RGB(0. 0. OxFF). RGB(O.O.O) }; KPen wide(PS_GEOMETRIC | PSJOLID | WideStyle[i], 70. RGB(0. 0, OxFF), 0, NULL); wide.Select(hDC); BeginPath(hDC); MoveToEx(hDC, 150, 0, NULL); LineTo(hDC, 0. 0): LineTo(hDC, 100, -100); EndPath(hDC); WidenPath(hDC); wide.UnSelect(hDC); if (1--2 ) {
472 Глава 8. Линии и кривые KPathData pd; pd.GetPathData(hDC); pd.MarkPoints(hDC, false); KPen thin(PS_COSMETIC thin.Select(hDC); StrokePath(hDC); thin.UnSelect(hDC); ThinStyle[i], 1. Color[i], 0, NULL); Приведенный фрагмент выполняется трижды: для пера с квадратным завершением и заостренным соединением, с закругленными завершением и соединением и, наконец, для пера с плоским завершением и усеченным соединением. Каждый раз строится траектория из двух линий, расположенных под углом 45°. Траектории расширяются и обводятся разными косметическими линиями. Для последнего пера точки расширенной траектории помечаются в соответствии с их типами. Этот фрагмент наглядно показывает, как рисуются линии с применением геометрических перьев с различными атрибутами (рис. 8.18). Рис. 8.18. Применение функций WidenPath и StrokePath Рисунок также наглядно иллюстрирует процесс возникновения петли при использовании функции WidenPath. Для пера с плоским завершением и усеченным соединением (на рисунке обозначено сплошной черной линией) WidenPath строит замкнутую фигуру, которая начинается с правого нижнего угла, помеченного треугольником. Траектория следует к центру другого конца линии, где она встречается с другой линией. После этого траектория переходит на вторую линию, следует по всему периметру до соединения, рисует соединение и замыкает фигуру. Петля генерируется в том случае, если две линии пересекаются под углом меньше 180°. Вероятно, алгоритму GDI следовало бы вычислить область пересечения периметров двух линий и удалить петли вместо того, чтобы просто следовать линии периметра. Для платформ, не входящих в семейство NT, функция StrokePath особенно важна для геометрических перьев, поскольку их атрибуты завершения и соединения требуются только при включении линий и кривых в траекторию. Другими
Пример: рисование нестандартных стилевых линий 473 словами, при вызове таких функций, как LineTo, Arc и BezierTo вне построения траектории, в этих системах атрибуты завершения и соединения геометрических перьев игнорируются, и вместо них используются значения по умолчанию. Функция Fill Path закрашивает область, занимаемую траекторией, при помощи кисти. Функция StrokeAndFi 11 Path закрашивает область, как Fill Path, и рисует линии и кривые, как StrokePath. С другой стороны, следующие подряд вызовы Fill Path и StrokePath не заменяют StrokeAndFi 11 Path, поскольку все эти функции перед возвращением управления уничтожают объект траектории. Функции Fi 11- Path и StrokeAndFi 11 Path рассматриваются в следующей главе. Преобразование пути в регион Остается рассмотреть еще две функции GDI, предназначенные для работы с траекториями. Функция PathToRegion преобразует текущую траекторию в контексте устройства в независимый регион, который может использоваться приложением для различных целей. Функция SelectClipPath преобразует текущую траекторию контекста устройства в регион и задействует его для обновления региона отсечения, определенного приложением в данном контексте. Мы еще вернемся к этим двум функциям после более подробного описания регионов и отсечения. Пример: рисование нестандартных стилевых линий На платформах, не входящих в семейство NT, утолщенные геометрические стилевые линии не поддерживаются. Иначе говоря, графические приложения, ориентированные на все платформы, не могут рассчитывать на поддержку утолщенных геометрических линий на уровне GDI. Впрочем, даже на платформах семейства NT поддержка стилевых линий в GDI обладает недостаточными возможностями. Вы не можете повторять произвольный пользовательский узор вдоль траектории, определять собственные типы завершений и соединений. Разбиение траектории на отрезки упрощает реализацию этих алгоритмов. С другой стороны, непосредственная работа с кривыми Безье экономит память и повышает точность. В листинге 8.7 приведены определения двух классов, обеспечивающих значительно большие возможности рисования стилевых линий по сравнению с GDI. Листинг 8.7. Классы для работы со стилевыми линиями class KDash { public: virtual double GetLengthdnt step) { return 10; } Продолжение &
474 Глава 8. Линии и кривые Листинг 8.7. Продолжение virtual BOOL DrawDash(double xl, double yl, double x2, double y2, int step) { return FALSE; } class KStyleCurve { i nt m_step; double m_xl, m_yl; KDash * m_pDash; public: KStyleCurve(KDash * pDash) { m_xl = 0; m_yl = 0; m_step = 0; m_pDash= pDash; } BOOL MoveTo(double x, double y); BOOL LineTo(double x, double y); BOOL PolyDraw(const POINT *ppt, const BYTE *pbTypes, int nCount); BOOL KStyleCurve::LineTo(double x. double y) { double x2 = x; double y2 = у; double curlen - sqrt((x2-m_xl)*(x2-m_xl) + (y2-m_yl)*(y2-m_yl)); double length = m_pDash->GetLength(m_step); while ( curlen >- length ) { double xl = m_xl; double yl - m_yl; m_xl += (x2-m_xl) * length / curlen; m^l +- (y2-mj/l) * length / curlen; if ( ! m_pDash->DrawDash(xl, yl. m_xl, m__yl, m_step) ) return FALSE; curlen -- length; m_step ++; length - m_pDash->GetLength(m_step); } return TRUE; } BOOL KStyleCurve::PolyDraw(const POINT *ppt. const BYTE *pbTypes. int nCount)
Пример: рисование нестандартных стилевых линий 475 { int lastmovex = 0; int lastmovey = 0; for (int i=0; i<nCount; i++) { switch ( pbTypes[i] & - PT_CLOSEFIGURE ) { case PT_M0VET0: m_xl = lastmovex = ppt[i].x; m_yl = lastmovey = ppt[i].y; break; case PT_LINET0: if ( ! LineTo(ppt[i].x. ppt[i].y) ) return FALSE; break; } if ( pbTypes[i] & PT_CLOSEFIGURE ) if ( ! LineTo(lastmovex, lastmovey) ) return FALSE; } return TRUE; } Задача рисования стилевых линий разделяется на две подзадачи, каждая из которых решается отдельным классом. Класс KDash управляет циклом чередования и выводом пунктирных отрезков. Он определяется в виде абстрактного класса с двумя виртуальными методами, позволяющими рисовать линии разных стилей для разных классов. Метод GetLength возвращает длину пунктирного отрезка по параметру step; в каком-то отношении он выполняет те же функции, что и массив с описанием пользовательского стиля. Если в стилевой линии используются одинаковые длины пунктирных отрезков и промежутков, GetLength просто возвращает константу. Если цикл чередования определяется фиксированным массивом, GetLength может вернуть lpStyle[step X dwStyleCount]. Метод DrawDash рисует отрезки и промежутки. В качестве параметров ему передаются две точки с вещественными координатами (для повышения точности) и номер текущего сегмента step. По значению этого параметра функция определяет, является ли текущий сегмент отрезком или промежутком. Например, при рисовании пунктирной линии функция может рисовать каждый второй сегмент. Класс KStyleCurve управляет делением линий и кривых на сегменты нужной длины. В приведенном варианте он содержит методы MoveTo для определения начальной позиции, LineTo для рисования линий и PolyDraw для рисования данных, возвращаемых GetPath. При необходимости класс легко расширяется для поддержки кривых Безье и эллиптических кривых без использования траекторий. Конструктор класса KStyleCurve получает указатель на объект класса KDash, который может потребоваться для получения информации. В классе KStyleCurve главная роль принадлежит функции KStyleCurve::LineTo. Функция получает от класса KDash информацию о текущей длине сегмента и пытается «отрезать» от
476 Глава 8. Линии и кривые текущей линии сегмент указанной длины. Процесс повторяется до тех пор, пока остаток линии не окажется слишком коротким; в этом случае обработка откладывается до следующей линии. Реализация всегда возвращает сегмент необходимого размера; все остатки меньших размеров сливаются со следующей линией. Такой подход гарантирует, что сегменты будут иметь требуемую длину, но иногда он может приводить к срезанию углов. Более изощренное решение должно поддерживать изгибы отрезков, их равномерное распределение и отсечение. Взаимосвязь между классами KStyleCurve и KDash очень похожа на отношения между функцией LineDDA и ее функциями косвенного вызова. Главное отличие заключается в том, что KStyleCurve позволяет работать с кривыми, а в классе KDash косвенный вызов организуется при помощи виртуальных функций C++. Ниже приведен пример класса KDiamond, производного от класса KDash. Класс KDiamond рисует стилевые линии, состоящие из ромбов разных размеров и цветов. Функция GetLength возвращает значение 8 или 16 в зависимости от четности или нечетности номера текущего сегмента. Функция DrawDash рассматривает точки (х1,у1) и (х2,у2) как углы ромба и использует их для вычисления двух оставшихся углов, после чего рисует ромбы как многоугольники различных цветов. Рисование многоугольников рассматривается в следующей главе. class KDiamond : public KDash { HDC mJiDC: virtual double Getl_ength(int step) { return 8 + (step & 1) * 8; } virtual BOOL DrawDash(double xl. double yl. double x2. double y2. int step); public: KDiamond(HDC hDC) { mJiDC = hDC; } }: BOOL KDiamond::DrawDash(double xl. double yl. double x2. double y2. int step) { HBRUSH hBrush - CreateSolidBrush(PALETTEINDEX(step * 20)); HGDIOBJ hOld = SelectObject(m_hDC. hBrush); SelectObject(m_hDC. GetStockObject(NULL_PEN)); double dx = (x2 - xl)/2; double dy = (y2 - yl)/2; POINT P[5] - { (int)xl. (int)yl. (int)((xl+x2)/2-dx). (int)((yl+y2)/2+dy). (int)x2. (int)y2. (int)((xl+x2)/2+dx). (int)(yl+y2)/2-dy). (int)xl. (int)yl }; Polygon(m_hDC. P. 5);
итоги 477 SelectObject(m_hDC. hOld); DeleteObject(hBrush); return TRUE; } На рис. 8.19 показано, как работает более гибкий класс, который вместо пунктирных отрезков рисует круги, квадраты, ромбы и треугольники. Рис. 8.19. Рисование нестандартных стилевых линий Итоги В этой главе, основанной на материале предыдущих глав, подробно рассматривается процесс рисования линий и кривых в Windows GDI. В ней изучаются бинарные растровые операции, режимы заполнения фона, логические перья, линии, кривые Безье, дуги и траектории, в которых линии объединяются с кривыми. Бинарные растровые операции определяют способ объединения пикселов пера с пикселами приемника и формирования новых пикселов приемника. Самым распространенным случаем является режим R2C0PYPEN, при котором цвет приемника заменяется цветом пера. Инвертируемые растровые операции часто используются в интерактивной компьютерной графике — например, для рисования эластичных линий и перекрестий, а также временных контуров перетаскиваемых объектов. Набор из шестнадцати бинарных растровых операций не так уж велик. Альфа-наложение, которое также является разновидностью объединения цвета выводимых пикселов с пикселами приемника, при рисовании линий не поддерживается. Применительно к линиям и кривым режим заполнения фона определяет, должны ли выводиться пикселы фона между отрезками. Режим заполнения фона относится только к простым перьям; косметические и геометрические перья рисуют только пикселы линий. Логические перья, определяемые в платформах на базе NT, обладают достаточно серьезными возможностями. Однако на платформах Win32, не входящих в семейство NT, поддержка перьев ограничена, что затрудняет написание уни-
478 Глава 8. Линии и кривые версальных приложений. В системах Windows 95/98 для геометрических перьев не поддерживаются стилевые линии, утолщенные линии центруются неточно, завершения и соединения поддерживаются только функциями построения траекторий, а альтернативные и пользовательские стили перьев не поддерживаются. В разделе «Пример: рисование нестандартных стилевых линий» приведен пример класса, позволяющего рисовать нестандартные стилевые линии. Этот класс дает возможность имитировать несуществующие геометрические стилевые перья. В GDI предусмотрена достаточно солидная поддержка рисования линий, кривых Безье и эллиптических кривых. Тем не менее функции Angl еАгс, АгсТо и PolyDraw реализованы только в системах семейства NT. В этой главе приведено достаточно теоретического материала и примеров, чтобы позволить приложениям создавать свои собственные реализации этих функций. Мы подробно рассмотрели теорию кривых Безье, а также процесс преобразования полных эллипсов и эллиптических дуг в кривые Безье. При решении этих практических задач используются несложные математические выкладки. Траектории — очень важный аспект графического программирования GDI, которому обычно не уделяют должного внимания. В этой главе показано, что собой представляет траектория, как она строится, преобразуется и используется при выводе. Практическое применение траекторий продемонстрировано на примере построения нестандартных стилевых линий и применения не-аффинных преобразований для построения линий переменной толщины. Траектории широко используются графическим механизмом Windows NT/2000 и интерфейсом DDI, через который графический механизм взаимодействует с драйверами графических устройств. За подробным описанием внутреннего представления траекторий обращайтесь к главе 3. Геометрические линии, которые могут иметь значительную толщину, несомненно реализуются посредством заливки областей, а не простым размещением пикселов вдоль траектории. По этой причине в этой главе встречается несколько ссылок на материал следующей главы. Настало время перейти к новому рубежу — заливке областей в GDI. Пример программы Эта глава сопровождается всего одним примером программы LineCurve (табл. 8.6). Впрочем, программа достаточно велика и в ней нашли отражение все темы, рассмотренные в главе. Кстати говоря, все рисунки к этой главе представляют собой снимки экранов программы LineCurve. Таблица 8.6. Программа главы 8 Каталог проекта Описание Samples\Chapt_08\LineCurve Меню Test содержит десятки команд, демонстрирующих применение бинарных растровых операций, перьев DC, простых и расширенных перьев, линий, кривых Безье, дуг, траекторий и нестандартных пользовательских стилей, описанных в разделе «Пример: рисование нестандартных стилевых линий»
Глава 9 Замкнутые области У истоков современной математики лежат две старые математические задачи — поиск касательной к заданной кривой и вычисление площади внутри заданной замкнутой кривой. Первая проблема решается в области дифференциального исчисления, а вторая — в области интегрального. Некая аналогия прослеживается и в графическом интерфейсе Windows API — одни функции выстраивают пикселы вдоль линий и кривых, а другие заполняют замкнутые фигуры, образованные линиями и кривыми. От одномерных линий и кривых, подробно описанных в главе 8, мы переходим в новое измерение и займемся заливкой областей. В этой главе рассматриваются основные темы, связанные с заливкой, — кисти; базовые структуры данных кистей; прямоугольники и регионы; основные виды геометрических фигур (прямоугольники, многоугольники, эллипсы, секторы и сегменты) и такое модное направление, как градиентные заливки. Кисти В процессе закраски области приходится учитывать множество факторов: геометрическую форму, правила ее интерпретации, растровые операции, режим заполнения фона, цвет и узор. В графическом интерфейсе Windows API сведения о цвете и узоре, используемом при заливке областей, группируются в объекте кисти. Как ни странно, рисовать кистью в Windows проще, чем пером, потому что перья рисуют линии и кривые с разной толщиной и стилем, а у кистей такая возможность не предусмотрена. Цвет кисти определяет основной цвет пикселов при закраске замкнутых фигур, а узор создает различные повторяющиеся эффекты заполнения. Объект логической кисти В GDI существует несколько функций для создания объектов кистей, или выражаясь точнее — объектов логических кистей. Логическая кисть описывает требо-
480 Глава 9. Замкнутые области вания, предъявляемые к заливке со стороны приложения (прежде всего цвет и узор). Она сообщает драйверу устройства, как должна выглядеть заливка, однако драйверы устройств для представления собственной интерпретации кисти работают с различными структурами данных, которые обычно называются «физическими кистями». Внутренними структурами данных логической кисти управляет GDI, как и структурами данных других объектов (контекстов устройств, логических перьев, логических шрифтов и т. д.). После создания логической кисти ее манипулятор возвращается приложению и используется при последующих ссылках на кисть. Манипуляторы объектов GDI описываются общим типом HGDI0BJ; для манипуляторов логических кистей зарезервирован тип HBRUSH. С каждым контекстом устройства связывается атрибут логической кисти, для работы с которым используются функции GetCurrentObject, SelectObject, GetObject и EnumObjects. Эти функции, рассматривавшиеся в главе 8 применительно к объектам перьев, выполняют одни и те же операции с разнотипными объектами GDI. Объект логической кисти, как и любой другой объект GDI, расходует ресурсы пользовательского процесса и ядра, а также занимает по крайней мере один элемент в таблице объектов GDI, поэтому ненужные логические кисти следует удалять функцией Del eteObject. Стандартные кисти GDI определяет несколько стандартных объектов кистей, которые могут легко использоваться любым приложением. Чтобы получить манипулятор стандартной кисти, достаточно вызвать функцию GetStockObject с одной из констант BLACK_BRUSH, DKGRAY_BRUSH, GRAYJRUSH, LTGRAYJRUSH, WHITEJRUSH, NULL_BRUSH (то же, что и H0LL0W_BRUSH) или DCBRUSH. Черная, темно-серая, серая, светло-серая и белая стандартные кисти представляют собой однородные кисти с различными уровнями интенсивности серого цвета. По умолчанию в контексте устройства выбирается белая кисть. При выборе пустой стандартной кисти (NULLBRUSH или H0LL0WBRUSH) внутренняя часть области не закрашивается (по аналогии с тем, как пустое перо не рисует линий). Поскольку функция GetStockObject работает с обобщенными объектами GDI, результат ее вызова для стандартных объектов кистей обычно преобразуется к типу HBRUSH. Стандартная кисть DC, возвращаемая вызовом GetStockObject(DC_BRUSH), принадлежит к числу новых средств Windows 98/2000. Кисти DC, как и перья DC, являются псевдообъектами GDI и могут изменять цвет после выбора в контексте устройства. Для работы с цветом кисти DC, выбранной в контексте устройства, используются следующие функции: C0L0RREF GetDCBrushColor(HDC hDC); C0L0RREF SetDCBrushColorCHDC hDC. C0L0RREF crColor); Функция GetDCBrushColor возвращает текущий цвет кисти DC; функция Set- DCPenColor назначает новый и возвращает старый цвет. Эти функции могут использоваться даже в том случае, если кисть DC не выбрана в контексте устройства, однако в этом случае они ни на что не влияют. Стандартные объекты заранее создаются операционной системой и совместно используются всеми процессами, работающими в системе. После завершения
Кисти 481 работы со стандартными объектами их манипуляторы удалять не нужно. Впрочем, вызов Del eteOb ject для манипулятора стандартной кисти абсолютно безопасен — функция просто возвращает TRUE, не выполняя никаких действий. Пользовательские кисти Вряд ли кого-нибудь обрадует картина, нарисованная всего пятью оттенками серого цвета. Для создания или получения разноцветных пользовательских кистей с интересными узорами используются следующие функции: HBRUSH CreateSolidBrushCCOLORREF crColor); HBRUSH CreateHatchBrushdnt fnStyle, COLORREF crRef); HBRUSH CreatePatternBrush(HBITMAP hbmp); HBRUSH CreateDIBPatternBrushPt(CONST VOID * IpPackedDIB, UINT iUsage); HBRUSH CreateDIBPatternBrush(HGLOBAL hglbDIBPacked. UINT fuColorSpec); HBRUSH GetSysCo1orBrush(int nlndex); Однородные кисти Проще всего создаются однородные кисти — для этого достаточно указать цвет. Функция CreateSolidBrush создает только логическую кисть. Когда манипулятор кисти выбирается в контексте устройства, GDI и драйвер устройства должны согласовать между собой реализацию кисти. Если контекст устройства не использует палитру, описатель цвета без особых хлопот преобразуется в составляющие RGB. С другой стороны, для контекстов, использующих палитру, описатель цвета должен преобразовываться в индекс палитры. Если совпадение отыскивается, найденный индекс задеиствуется при выводе; в противном случае устройство имитирует пикселы нужного цвета, комбинируя доступные цвета путем так называемого смешения (dithering). Смешение позволяет воспроизводить дополнительные цвета на 16- и 256-цветных видеоадаптерах и даже имитировать вывод в оттенках серого на черно-белых принтерах. В следующем фрагменте показано, как создать однородную кисть и выбрать ее в контексте устройства. Программа рисует прямоугольник 8x8 каждого из 256 цветов в интервале от синего до белого и отображает увеличенные изображения 16-цветных прямоугольников, расположенных на диагональной линии. Если запустить программу в 256-цветном видеорежиме, вы увидите узоры смешения, показанные на рис. 9.1. // Прямоугольник не обводится контуром SelectObject(hDC. GetStockObject(NULL_PEN)); for (int y=0; y<16; y++) for (int x=0; x<16; x++) { HBRUSH hBrush = CreateSolidBrush(RGB(y*16+x. y*16+x, OxFF)); HGDIOBJ hOld = SelectObject(hDC, hBrush); Rectangle(hDC, 235+x*10. y*10, 235+x*10+9, y*10+9); if ( x==y ) // Увеличить цветные квадраты по диагонали
482 Глава 9. Замкнутые области ZoomRectChDC. 235+х*10. у*10. 235+х*10+8. у*10+ 80*(х£8). 180+80*(х/8). 6); SelectObject(hDC, hOld): DeleteObject(hBrush); } SelectObjectChDC. GetStockObject(BLACK PEN)); яяяяяяяяяяяяяжяя яяявяяняняняняяя вяякяяккяякяяяяя Рис. 9.1. Смешение при рисовании однородной кистью на устройствах, использующих палитру Для цветов, не входящих в текущую аппаратную палитру, смешение создает узоры, цвет которых в среднем приближается к исходным цветам. При использовании двух чистых цветов в узоре 8x8 возможно 64 уровня интенсивности цвета. На устройствах с низким разрешением смешение порождает довольно заметные скопления точек. Но на устройствах высокого разрешения (например, на современных принтерах) драйвер устройства обычно задействует изощренные полутоновые алгоритмы для имитации однородных оттенков цвета. Благодаря ничтожно малым размерам точек современные принтеры обеспечивают качество печати, близкое к качеству фотографических изображений. Штриховые кисти Функция CreateHatchBrush создает логическую кисть с одним из шести стандартных узоров, образующих равномерный рисунок в виде повторяющихся линий. Тип штрихового узора определяется параметром fnStyle (рис. 9.2). В верхней части рисунка показан результат применения штриховых кистей для заполнения прямоугольных областей. Как нетрудно убедиться, рисунок создается многократным повторением маленьких «блоков», изображенных в нижней части рисунка. Обычно для реализации штриховых кистей драйверы устройств используют растры размером 8x8 пикселов, однако архитектура интерфейса DDI позволяет выбирать и другие реализации в зависимости от таких факторов, как разрешение.
Кисти 483 ||1щ wMm HS_HORIZONTAL HS_VERTICAL HS_FDIAGONAL HS_BDIAGONAL HS_CROSS HS_DIAGCROSS Рис. 9.2. Стили штриховых кистей При работе со штриховыми кистями необходимо учитывать размер штрихового узора, цвет, режим заполнения фона и выравнивание штрихового узора. Штриховые кисти обычно определяются растрами 8 х 8 в единицах устройства (то есть 8 пикселов на 8 пикселов). В отличие от большинства других средств GDI, размер узора штриховой кисти не определяется в логических единицах. Например, при выводе на экран штриховые кисти всегда используют шаблоны 8x8 пикселов независимо от действующих преобразований из логических координат в физические. На обычном экране такой узор смотрится нормально, но при сильном уменьшении он начинает выглядеть странно из-за искажения пропорций. С другой стороны, если приложение использует штриховые кисти при выводе на принтер с высоким разрешением, заливка, созданная с применением штриховой кисти, может вообще не порождать сколько-нибудь заметного узора. Какой размер соответствует блоку 8x8 пикселов при печати с разрешением 2400 dpi? — 1/300 дюйма. Чтобы штриховой узор имел те же физические размеры, как и на экране с разрешением 120 dpi, принтер с разрешением 2400 dpi должен использовать штриховые узоры размером 160 х 160 пикселов. Следовательно, если приложение поддерживает просмотр или печать документов в различных масштабах, стандартных штриховых кистей GDI лучше избегать. Вместо этого следует искать альтернативные решения, масштабируемые с учетом разрешения устройства и отображения логических координат в координаты устройства. В штриховых кистях пикселы делятся на основные (на рис. 9.2 выделены темным цветом) и фоновые (изображены светлым цветом). Основные пикселы выводятся всегда, а фоновые пикселы выводятся лишь в том случае, если установлен режим заполнения фона OPAQUE. Для работы с атрибутом режима заполнения фона в контекстах устройств используются функции GetBkMode и SetBkMode. Второй параметр функции CreateHatchBrush (параметр crRef) задает основной цвет, а фоновый цвет определяется атрибутом цвета фона в контексте устройства (функции GetBkColor и SetBkColor). Как для основного, так и для фонового цвета GDI подбирает ближайший чистый (присутствующий в системной палитре) цвет и использует его при выводе; смешение для штриховых кистей не поддерживается. При использовании штриховых кистей несколькими графическими объектами или при поддержке прокрутки может возникнуть проблема совмещения узоров. Для выравнивания кистей в контекстах устройств GDI задействует атрибут базовой точки кисти, для работы с которым требуются следующие функции:
484 Глава 9. Замкнутые области BOOL GetBrushOrgExCHDC hDC. LPPOINT lppt): BOOL SetBrushOrgEx(HDC hDC. int nxOrg. int nyOrg, LPPOINT lppt): Базовая точка кисти представляет собой точку (ЬхО, ЬуО) в системе координат устройства, которая определяет привязку левого верхнего пиксела штрихового узора; остальные пикселы выстраиваются соответствующим образом. Выражаясь точнее, точке (х,у) в системе координат устройства соответствует точка узора Pattern[(x-bxO) % pattern_width. (y-byO) % pattern_height] По умолчанию координаты базовой точки кисти равны (0,0). Чтобы обеспечить правильное выравнивание кистей после изменения преобразований или отображений, следует вызвать функцию SetBrushOrgEx. Следующий фрагмент обеспечивает выравнивание кистей по точке (0,0) в логической системе координат: POINT Р = { 0. О }; // Начало координат LPtoDP(hDC, &P. 1); // Отображение в координаты устройства SetBrush0rgEx(hDC. P.x. Р.у, NULL); Раньше штриховые кисти очень часто использовались в деловой графике — например, для выделения разных данных в гистограммах или круговых диаграммах. С появлением современных видеоадаптеров, отображающих миллионы цветов, и цветных принтеров штриховые кисти утратили свое значение — считается, что они приносят больше хлопот, чем пользы. Если приложение должно выводить масштабируемые рисунки, напоминающие штриховые узоры GDI, вместо штриховых кистей можно воспользоваться другими средствами (например, линиями или растрами). Растровые кисти Шести стандартных штриховых кистей явно недостаточно, поэтому GDI позволяет приложениям создавать кисти на базе растровых изображений. В GDI поддерживаются два основных типа растров: аппаратно-зависимые и аппаратно-не- зависимые. Оба типа подробно рассматриваются в следующих трех главах, а сейчас будет лишь показано, как создать на основе растра растровую кисть1 (bitmap brush) и воспользоваться ею. Функция CreatePatternBrush получает манипулятор аппаратно-зависимого растра (DDB) и создает растровую кисть. Многочисленные экземпляры кисти «выкладываются» наподобие мозаики и заполняют область в операциях заливки. GDI создает копию растра, поэтому манипулятор растра не используется логической кистью после ее создания. Функция CreateDIBPatternBrushPt создает кисть по указателю на упакованный аппаратно-независимый растр (DIB); функция Create- DIBPatternBrush создает кисть по глобальному манипулятору блока памяти, содержащему данные DIB. В программировании Win32 глобальный манипулятор блока памяти ресурса (HGL0BAL) в действительности представляет собой указатель в 32-разрядном линейном адресном пространстве. Однако манипулятор глобального блока, возвращаемый функцией GlobalAlloc, отличается от соответствующего указателя, который может быть получен при вызове функции Global - Lock. Различия между манипулятором блока и указателем на блок унаследованы из парадигмы 16-разрядного программирования. Также встречается термин «узорная кисть» (pattern brush). — Примеч. перев.
Кисти 485 В приведенном ниже фрагменте показано, как эти три функции используются для создания растровых кистей. Прежде всего мы должны где-то найти готовые растровые изображения, не создавая собственных ресурсных файлов. Вам доводилось играть в карточные игры под Windows (например, раскладывать пасьянс, входящий в комплект поставки системы)? Изображения карт хранятся в библиотеке cards.dll и могут использоваться другими приложениями. В приведенном фрагменте DLL загружается функцией LoadLibrary. Функция LoadBitmap создает манипулятор DDB, а функции FindResource и LoadResource создают манипулятор глобального блока. HINSTANCE hCards = LoadLibrary("cards.сПГ); for (int i=0; i<3; i++) { HBRUSH hBrush: int width, height; switch ( i ) { case 0: { HBITMAP hBitmap = LoadBitmap(hCards. MAKEINTRES0URCE(52)); BITMAP bmp; GetObjectChBitmap. sizeof(bmp). & bmp); width = bmp.bmWidth; height = bmp.bmHeight; hBrush = CreatePatternBrush(hBitmap); DeleteObject(hBitmap); } break; case 1: { HRSRC hResource = FindResource(hCards, MAKEINTRES0URCE(52-14). RT_BITMAP); HGLOBAL hGlobal = LoadResource(hCards. hResource); hBrush = CreateDIBPatternBrushPt( LockResource(hGlobal). DIB_RGB_C0LORS); width = ((BITMAPCOREHEADER *) hGlobal)->bcWidth; height = ((BITMAPCOREHEADER *) hGlobal)->bcHeight; } break; case 2: { HRSRC hResource = FindResource(hCards, MAKEINTRES0URCE(52-28), RT_BITMAP); HGLOBAL hGlobal = LoadResource(hCards, hResource); hBrush = CreateDIBPatternBrush(hGlobal, DIB_RGB_C0L0RS); width - ((BITMAPCOREHEADER *) hGlobal)->bcWidth; height = ((BITMAPCOREHEADER *) hGlobal)->bcHeight;
486 Глава 9. Замкнутые области } HGDIOBJ hOld - SelectObjecKhDC, hBrush); POINT P « { i*140+20 + width*i/4. 250 + height*i/4 }; LPtoDP(hDC, &P. 1); SetBrushOrgEx(hDC. P.x, P.y, NULL);// Выровнять изображения карт // в прямоугольнике Rectangle(hDC. 1*140+20. 250, i*140+20+width*3/2+l. 250+height*3/2+l); SelectObjecKhDC. hOld): DeleteObject(hBrush); } Программа в цикле перебирает три возможных случая. В первом случае король пик загружается как DDB-растр, на основе которого создается растровая кисть. Во втором случае дама червей загружается и фиксируется в памяти; полученный указатель на упакованный DIB-растр используется для создания растровой кисти DIB. В третьем случае валет бубен загружается и фиксируется в памяти для получения манипулятора блока, требующегося при создании другой растровой кисти DIB. Созданные кисти обеспечивают закраску трех прямоугольников, размеры которых примерно в 1,5 раза превышают размеры карт по каждой из сторон. Чтобы обеспечить совмещение растров с левым верхним углом прямоугольника, мы используем функцию LPtoDP для отображения логических координат в координаты устройства и вызываем функцию SetBrushOrg, которая и производит непосредственное выравнивание. Результат показан на рис. 9.3. Рис. 9.3. Растровые кисти и совмещение базовой точки Обратите внимание: в Windows 95/98 cards.dll является 16-разрядной библиотекой DLL и не может напрямую загружаться приложениями Win32. При работе с растровыми кистями необходимо помнить о некоторых обстоятельствах. Во-первых, на уровне GDI растровые кисти не обеспечивают полноценной замены штриховых кистей. Для растровой кисти каждый пиксел интерпретируется как пиксел основного цвета; фоновых пикселов не существует.
Кисти 487 Во-вторых, размер растровых кистей, как и размер штриховых кистей, задается в единицах координат устройства. Узоры, нарисованные растровыми кистями, всегда имеют одинаковую ориентацию и размеры в системе координат устройства. Чтобы создавать узоры, масштабируемые в соответствие с разрешением устройства, приложению приходится задействовать несколько разных растров. Но самой серьезной является третья проблема: на платформах, не входящих в семейство NT, максимальный размер растровой кисти ограничивается величиной 8x8 пикселов. Например, если вы попытаетесь использовать в Windows 95/98 растр больших размеров, выведен будет только левый верхний угол. В следующей главе описаны решения, позволяющие добиться нужного эффекта при помощи растровых функций GDI. Растровые узорные кисти часто используются для рисования горизонтальных и вертикальных пунктирных линий. Вспомните прошлую главу — в псевдоточечных линиях PS_D0T одна точка изображается тремя пикселами, а настоящий точечный стиль PS_ALTERNATE поддерживается только в семействе NT. Если вам не хочется рисовать пунктирную линию пиксел за пикселом, существует простое решение — воспользоваться растровой кистью. Приложение может создать кисть с шахматным узором и рисовать прямоугольники с шириной или высотой, равной одному пикселу, или же закрашивать области, в результате отсечения сведенные к ширине или высоте в один пиксел. В приведенном ниже фрагменте создается кисть с шахматным узором, которая используется для обводки контура прямоугольника, имитируя стиль PSALTERNATE. Узор генерируется на основе черно-белого растра 8x8, созданного функцией CreateBitmap. Для рисования линий толщиной в один пиксел применяется функция PatBlt, работающая в режиме отображения ММ_ТЕХТ. В других режимах отображения или в расширенном графическом режиме требуется отсечение, которое гарантирует, что толщина нарисованной линии окажется равной одному пикселу. Этот фрагмент также иллюстрирует второе распространенное применение шахматной кисти — рисование полупрозрачных узоров. Допустим, в текущем контексте устройства выбран черный цвет текста, белый цвет фона, пиксел 0 соответствует черному цвету (RGB(O.O.O)), а пиксел 1 соответствует белому цвету (RGB(255,255,255)). Цвет кисти объединяется с цветом приемника растровой операцией R2MASKPEN. Таким образом, черные пикселы кисти остаются черными, а белые пикселы не изменяют содержимого приемника. При закраске половина пикселов приемника затемняется, и возникает эффект «полупрозрачности». void Frame(HDC hDC, int xO. int yO, int xl, int yl) { unsigned short ChessBoard[] = { OxAA, 0x55. OxAA. 0x55, OxAA, 0x55, OxAA, 0x55 }; HBITMAP hBitmap = CreateBitmap(8, 8. 1. 1, ChessBoard); HBRUSH hBrush = CreatePatternBrush(hBitmap); DeleteObject(hBitmap); HGDIOBJ hOld = SelectObject(hDC. hBrush); // Прямоугольник PS_ALTERNATE PatBlUhDC, xO. yO. xl-xO. 1. PATCOPY); PatBltChDC. xO. yl. xl-xO, 1. PATCOPY);
488 Глава 9. Замкнутые области PatBltChDC. хО, уО. 1, yl-yO. PATCOPY); PatBltChDC. xl, уО, 1. yl-yO. PATCOPY); int old = SetROP2(hDC. R2_MASKPEN); Rectangle(hDC, xO+5, yO+5. xl-5. yl-5); SetR0P2(hDC. old); SelectObjectChDC. hOld); DeleteObject(hBrush); } На рис. 9.4 показан эффект от применения шахматного узора. Пожалуй, разработчикам из Microsoft следовало бы включить этот узор в состав штриховых кистей. Рис. 9.4. Применение шахматного узора: пунктирные линии и полу прозрачность Кисти системных цветов В системе управления окнами используются десятки цветов, предназначенных для вывода различных частей окна — строк заголовков, рамок, меню, полос прокрутки, кнопок и т. д. Эти цвета называются системными и настраиваются в специальном приложении панели управления или на программном уровне, при помощи функций API GetSysColor и SetSysColor. Для каждого системного цвета система создает стандартную кисть. Приложения могут получать кисти системных цветов при помощи функции GetSysColorBrush, передавая ей значения в интервале от C0L0R_SCR0LLBAR до COLOR_GRADIENTACTIVECAPTION. Кисти системных цветов применяются для закраски областей, цвета которых должны соответствовать областям, закрашиваемым системой. Если окно самостоятельно управляет прорисовкой неклиентской области, кисти системных цветов оказываются исключительно полезными. Эти кисти принадлежат к числу стандартных объектов GDI, которые не нужно удалять после использования. Вызовы функции DeleteObject для кистей системных цветов игнорируются.
Кисти 489 Кисти системных цветов могут указываться в качестве фоновых кистей при регистрации классов окон, при этом допускается использование индексов системных цветов в формате (HBRUSH)(C0L0RWIND0W + 1). В соответствии с MSDN, в некоторых системах вызов GetSystemColorBrush в случае многократной загрузки и выгрузки user32.dll может завершиться неудачей. Это связано с тем, что при каждой загрузке user32.dll система создает кисти системных цветов, но при выгрузке забывает их удалить. Таким образом, после того как библиотека user32.dll будет загружена и выгружена несколько сотен раз, таблица объектов GDI может переполниться. Подобные ситуации возникают только в консольных приложениях, выполняющих динамическую загрузку/выгрузку DLL, в частности user32.dll. В GUI-приложениях библиотека user32.dll загружена всегда, она никогда не выгружается и не перезагружается. В Windows NT/2000 кисти системных цветов создаются всего один раз и совместно используются всеми процессами. Структура LOGBRUSH Подведем краткие итоги всего, о чем говорилось выше. Кисти предназначены для внутренней закраски областей. В GDI поддерживаются три типа кистей: однородные, штриховые и узорные. Однородная кисть определяется описателем цвета, при реализации которого на устройствах с палитрой может использоваться смешение. Особенностью штриховых кистей является деление пикселов на основные и фоновые; последние выводятся лишь в режиме заполнения фона OPAQUE. Штриховые кисти применяют лишь для простых экранных изображений, поскольку их узоры обычно не масштабируются в соответствие с разрешением и масштабом устройства. Узорная кисть определяется на основе аппаратно-зависимо- го или аппаратно-независимого растра. В процессе закраски растр многократно размещается в границах области по принципу мозаики. В реализации GDI для Windows 95/98 максимальный размер используемой части растра равен 8x8 пикселов, что существенно снижает полезность этого удобного средства. Все три типа кистей описываются структурой LOGBRUSH, которая может передаваться функции CreateBrushlndirect при создании логической кисти. Соответствующие определения приведены ниже. typedef struct tagLOGBRUSH { UINT lbStyle: COLORREF IbColor; LONG IbHatch; }; HBRUSH CreateBrushIndirect(CONST LOGBRUSH * lplb): Основные трудности при работе со структурой LOGBRUSH связаны с тем, что при выборе стиля BS_PATTERN поле IbHatch содержит манипулятор DDB, а для стилей BSDIBPATTERN и BSDIBPATTERNPT в этом поле указывается манипулятор блока DIB или указатель, а значение LOWORD(lbColor) равно либо DIBPALC0L0RS, либо DIB_RGB_C0L0RS. Структура LOGBRUSH может использоваться для получения информации об объекте кисти GDI при помощи функции GetObject: LOGBRUSH logbrush; GetObject(hBrush. sizeof(LOGBRUSH), & logbrush);
490 Глава 9. Замкнутые области Не рассчитывайте найти в структуре L0GBRUSH, возвращаемой GetObject, действительный манипулятор или указатель на растр узорной кисти. При создании узорной кисти GDI создает копию растра во внутренней структуре данных, скрытой от пользовательских приложений. Структура L0GBRUSH также используется при создании расширенных перьев. При рисовании линий и кривых геометрическим пером на самом деле задейст- вуется кисть, поэтому здесь также могут потребоваться смешение, штриховка и растры. Объект логической кисти находится под управлением GDI. В Windows NT/ 2000 объект логической кисти состоит из компонента пользовательского режима, оптимизирующего процесс частого создания и уничтожения однородных кистей, и компонента режима ядра, в котором хранится полная информация о логической кисти. В частности, объект режима ядра содержит данные об основном и фоновом цвете, расширенный набор флагов стиля, растр, маску и т. д. Маска нужна для реализации штриховых кистей, сохраняющих фоновый рисунок. На уровне DDI графический механизм позволяет драйверу устройства предоставить собственные растры для реализации штриховых кистей на уровне графического устройства, чтобы штриховой узор лучше различался. Предусмотрена специальная точка входа, при помощи которой драйвер устройства реализует логическую кисть — другими словами, создает свою внутреннюю интерпретацию логической кисти, которая позднее используется в графических операциях с применением логической кисти. Логические кисти (за исключением узорных) занимают очень мало памяти. Для узорных кистей в таблице GDI создается дополнительный манипулятор (как для узорных кистей DDB, так и для DIB) и выделяется память для хранения копии растра. Прямоугольники Основной геометрической фигурой в Windows API является прямоугольник. Прямоугольники применяются при определении окон и клиентских областей, различных фигур с прямоугольным ограничивающим контуром, при форматировании текста и даже при отсечении. В Win32 определяется структура данных и API для работы с прямоугольниками как структурами данных и для разнообразной закраски прямоугольных областей. Прямоугольник как структура данных В Win32 API прямоугольники определяются при помощи структуры RECT, для которой определяется около десятка всевозможных операций. typedef struct _RECT { LONG left; LONG top; LONG right: LONG bottom; }
Прямоугольники 491 BOOL SetRect(LPRECT Iprc. int xLeft, int yTop. int xRight. int yBottom); BOOL SetRectEmpty(LPRECT Iprc); BOOL IsRectEmpty(CONST RECT * Iprc); BOOL EqualRect(CONST RECT *lprcl. CONST RECT *lprc2); BOOL CopyRect(LPRECT IprcDst, CONST RECT * IprcSrc): BOOL OffsetRect(LPRECT Iprc, int dx. int dy); BOOL PtInRect(CONST RECT * Iprc. POINT pt); BOOL InflateRectCCONST LPRECT Iprc, int dx. int dy); BOOL IntersectRectCCONST LPRECT IprcDst. CONST RECT * lprcSrcl. CONST RECT * lprcSrc2); BOOL SubtractRect(LPRECT lprcDst2. CONST RECT * lprcSrcl. CONST RECT * lprcSrc2); BOOL UnionRect(LPRECT IprcDst. CONST RECT *lprcSrcl, CONST RECT * lprcSrc2); Прямоугольник определяется минимальными и максимальными координатами по обеим осям, что соответствует левому верхнему и правому нижнему углу в системе координат устройства. При работе с функциями, использующими структуру RECT, всегда предполагается, что левая координата не больше правой, а верхняя не больше нижней. Дело в том, что эти функции поддерживаются диспетчером окон для выполнения операций с прямоугольниками окон и клиентских областей, задаваемыми в экранных координатах. Прежде чем передавать данные этим функциям, приложение должно нормализовать их, иначе результаты могут быть весьма неожиданными. Также предполагается правильность передаваемых указателей на RECT — проверка указателей в текущих реализациях весьма ограничена (вероятно, по соображениям быстродействия). Функция SetRect заполняет все четыре поля структуры RECT новыми значениями и используется главным образом для инициализации новых прямоугольников. Функция SetRectEmpty обнуляет все четыре поля, в результате чего прямоугольник оказывается пустым. Функция IsRectEmpty проверяет, пуст ли заданный прямоугольник (то есть является ли его высота или ширина нулевой или отрицательной величиной). Функция Equal Rect проверяет, содержат ли два прямоугольника попарно совпадающие поля. Функция CopyRect копирует исходный прямоугольник в заданную структуру. Функция OfffsetRect смещает прямоугольник (то есть прибавляет к его левой и правой координате величину dx, а к верхней и нижней — величину dy). Функция PtlnRect проверяет, принадлежит ли точка прямоугольнику; при этом верхняя и левая стороны прямоугольника включаются в проверку, а правая и нижняя — нет. Другими словами, точки, расположенные на левой и верхней сторонах, считаются принадлежащими прямоугольнику, а точки правой и нижней стороны в прямоугольник не входят. Функция InflateRect расширяет прямоугольник на dx единиц по горизонтали и на dy единиц по вертикали (с каждой из сторон). Если задать отрицательные значения, прямоугольник уменьшается. Функция IntersectRect вычисляет область пересечения двух прямоугольников (получается либо прямоугольник, либо пустая область). Функция SubtractRect исключает прямоугольник из другого прямоугольника. Всем известно, что в общем случае при таком исключении генерируется непрямоугольная область, которая описывается тремя прямоугольниками. В Win32 API результат вызова SubtractRect определяется ограничивающим пря-
492 Глава 9. Замкнутые области моугольником. Таким образом, если перекрывающаяся область прямоугольников А и В по ширине или высоте совпадает с прямоугольником А, она исключается из результата А - В; в противном случае прямоугольник А остается без изменений. Функция UnionRect возвращает ограничивающий прямоугольник области, точки которой принадлежат хотя бы одному из двух прямоугольников. При работе с RECT все эти функции реализуются очень просто. При критических требованиях к быстродействию приложение может реализовать их в виде подставляемого (inline) кода вместо вызова функций Win32 API. Например, вызов SetRect с пятью параметрами требует минимум пяти инструкций, а при использовании подставляемого кода можно обойтись всего четырьмя инструкциями. Формат структуры RECT в памяти точно совпадает с форматом массива из двух структур POINT. При преобразовании координат функциями LPtoDP или DPtoLP структура RECT может передаваться вместо массива из двух структур POINT. Но если к структуре RECT применяются преобразования или отображения, вы должны принять дополнительные меры предосторожности и убедиться в том, что прямоугольник остается нормализованным и сохраняет параллельность осям. Рисование прямоугольников В Win32 API предусмотрено несколько функций, которые закрашивают внутреннюю область прямоугольника кистью, обводят его контуры пером или делают то и другое: BOOL Rectangle(HDC hDC. int nLeftRect, int nTopRect, int nRightRect, int nBottomRect); int FillRect(HDC hDC, CONST RECT * Iprc, HBRUSH hbr); int FrameRect(HDC hDC. CONST RECT * lprc, HBRUSH hbr); BOOL InvertRectCHDC hDC, CONST RECT * lprc); BOOL DrawFocusRect(HDC hDC, CONST RECT * lprc); Rectangle Функция Rectangle рисует прямоугольник, определяемый четырьмя координатами. На процесс рисования влияет достаточно большое количество атрибутов контекста. Поскольку функция Rectangle принадлежит к числу базовых функций GDI, мы рассмотрим ее более подробно. Рисунок 9.5 иллюстрирует результат применения функции Rectangle при разных атрибутах контекста устройства. Если контекст находится в совместимом графическом режиме, правая и нижняя стороны прямоугольника в системе координат устройства не рисуются (что соответствует традиционным правилам включения/исключения сторон). Обратите внимание на то, что правая сторона прямоугольника может и не соответствовать nBottomRect; она определяется максимальным значением nTopRect и nBottomRect при отображении на систему координат устройства. Но если контекст устройства находится в расширенном графическом режиме, выводятся все четыре стороны прямоугольника, как показывает нижний рисунок в левом столбце. Вероятно, это изменение неизбежно, поскольку возможность применения произвольных аффинных преобразований в расширенном режиме затрудняет определение правой и нижней сторон (по сравнению с верхней и нижней). Периметр прямоугольника обводится текущим объектом пера, выбранным в контексте устройства.
Прямоугольники 493 Если толщина пера равна один пикселу в координатах устройства, рисуются только пикселы периметра. Если перо имеет толщину в п пикселов, один пиксел рисуется на центральной линии, (п-1)/2 пикселов рисуются снаружи прямоугольника и еще (п-1)/2 — внутри прямоугольника. При использовании пера со стилем PSINSIDEFRAME один пиксел рисуется на центральной линии, а еще (п-1) пикселов — внутри прямоугольника. Другим особым случаем является пустое перо, которое не обводит периметр прямоугольника. При использовании пустого пера ширина и высота прямоугольника уменьшаются на один пиксел. •R »R "R Черное перо Пустое перо Перо с толщиной 3 пиксела Черное перо, Перо с толщиной 3 пиксела, Синее перо, расширенный режим рисование внутри контура R2_NOTCOPYPEN Рис. 9.5. Различные стили прямоугольников Текущий объект кисти закрашивает ту область, которая не была закрашена пером, а в случае пустого пера — весь прямоугольник, уменьшенный на один пиксел. На результаты применения кисти также влияет режим заполнения фона, цвет фона и базовая точка кисти. Текущая растровая операция в контексте устройства распространяется как на периметр, так и на внутреннюю часть прямоугольника. Например, если выбрать операцию R2 NOP, функция Rectangle не выполняет никаких действий. FillRect Функция FillRect закрашивает кистью прямоугольник, определяемый структурой RECT. Правая и нижняя стороны в системе координат устройства исключаются всегда, даже в расширенном графическом режиме. В отличие от вызова Rectangle с пустым пером, приводящим к рисованию уменьшенного прямоугольника, функция FillRect закрашивает весь прямоугольник. Она не использует атрибут бинарной растровой операции в контексте устройства. Параметр-кисть, передаваемый FillRect, также может содержать индекс системного цвета в формате (HBRUSH)(индекс +1). Различия между FillRect и Rectangle
494 Глава 9. Замкнутые области объясняются тем, что в реализации FillRect используются средства GDI для работы с растрами. FillRect вызывает недокументированную функцию PolyPatBlt GDI, работа которой основана на вызове PatBlt (см. следующую главу). FrameRect Функция FrameRect закрашивает периметр прямоугольника кистью (а не пером!). При этом контур нарисованного изображения имеет те же размеры, как и при вызове FillRect. Толщина периметра равна одной логической единице, а его реальная толщина в пикселах определяется мировым преобразованием и режимом отображения. Прорисовка периметра прямоугольника позволяет создавать интересные эффекты, которые трудно выполнить при помощи пера GDI. В частности, кисть позволяет использовать смешанные цвета, не создавая геометрическое перо, или рисовать полноценные точечные контуры прямоугольников растровой кистью с шахматным узором. Функция FrameRect также реализуется с применением недокументированной функции PolyPatBlt. InvertRect Функция InvertRect инвертирует цвет каждого пиксела прямоугольника по аналогии с тем, как перо в режиме R2_N0T инвертирует пикселы линии. В устройствах, использующих палитру, инвертируются индексы палитры и цвет определяется расположением цветов в палитре. В устройствах без палитры черный цвет переходит в белый, белый цвет переходит в черный, а RGB-значение каждого пиксела инвертируется. При двукратном вызове InvertRect с одинаковыми параметрами восстанавливается исходное содержимое контекста устройства. Функция InvertRect реализуется функцией PatBlt, поэтому она подчиняется тем же правилам включения/исключения сторон, что и функции FrameRect и FillRect. DrawFocusRect Функция DrawFocusRect напоминает функцию FrameRect. Она рисует периметр прямоугольника шахматной узорной кистью с применением растровой операции «исключающего ИЛИ». Как и в случае с функцией InvertRect, повторный вызов DrawFocusRect восстанавливает исходное содержимое контекста устройства. Функция DrawFocusRect реализуется функцией PolyPatBlt с узорной кистью и растровой операцией «исключающего ИЛИ». Название DrawFocusRect связано с применением этой функции в модуле управления окнами. Например, в диалоговых окнах функция DrawFocusRect рисует точечный контур прямоугольника на кнопке, получающей фокус ввода с клавиатуры. Когда фокус переходит к другой кнопке, прямоугольник стирается повторным вызовом DrawFocusRect, после чего вызывается функция рисования прямоугольника на кнопке, получившей фокус. Функция DrawFocusRect также может использоваться при выводе «эластичных» прямоугольников. Применяя эту функцию в интерактивном взаимодействии, проследите за правильностью определений прямоугольников. MSDN преувеличивает проблему и предупреждает программистов, что нарисованные функцией DrawFocusRect прямоугольники не могут прокручиваться. На самом деле с прокруткой проблем нет: обновляемый регион
Прямоугольники 495 после прокрутки содержит только вновь открывшиеся области, поэтому вызов DrawFocusRect при обработке сообщения WM_PAINT не приводит к стиранию прямоугольника. Но если контекст устройства был получен функцией GetDC, которая не настраивает системный регион, проще стереть прямоугольник перед прокруткой. На рис. 9.6 продемонстрирован результат вызова функций FillRect, FrameRect, InvertRect и DrawFocusRect, которые не относятся к числу функций GDI, хотя и используют функции GDI в своей работе. Эти функции поддерживаются системой управления окнами (user32.dll) и относятся именно к ней. FillRect FrameRect InvertRect DrawFocusRect Рис. 9.6. Функции рисования прямоугольников, используемые системой управления окнами Прорисовка границ и элементов управления В Win32 API входит ряд функций, с помощью которых система управления окнами рисует разнообразные границы и элементы управления (controls) и которые имеют непосредственное отношение к рисованию прямоугольников. Эти функции могут использоваться при реализации элементов, прорисовка которых осуществляется владельцем, при нестандартном выводе неклиентской области или при имитации внешнего вида окон и элементов управления. Ниже приведены прототипы двух важнейших функций, DrawEdge и DrawFrameControl. BOOL DrawEdge(HDC hDC. LPRECT Iprc, UINT edge, UINT grFlags); BOOL DrawFrameControl(HDC hDC. LPRECT Iprc. UINT uType. UINT uState); Обе функции получают манипулятор контекста, структуру RECT с описанием рисуемой области и два флага. Флаги и их смысл описаны в документации MSDN, а мы лишь приведем примеры их использования. Следующий фрагмент показывает, как рисовать различные границы (рис. 9.7). for (int e=0; e<4;e++) { const int Edge[] « {EDGE_RAISED. EDGE_SUNKEN. EDGE ETCHED. EDGE BUMP); int int Edge[] Flag[] = { EDGE RAISED. EDGE SUNKEN. = { BF MIDDLE | BF BOTTOM. BF MIDDLE BF MIDDLE BF MIDDLE BF MIDDLE BF MIDDLE BF MIDDLE BF BOTTOMLEFT. EDGE_ BF BOTTOMLEFT | BF TOP. BF RECT. BF RECT | BF FLAT. BF RECT | BF MONO. BF RECT | BF SOFT. _ETCHED. EDGE JUMP };
496 Глава 9. Замкнутые области BF_MIDDLE | BF_RECT | BF_DIAGONAL, BF_MIDDLE | BF_RECT | BF_ADJUST }; for (int f»Q: f<sizeof(Flag)/sizeof(Flag[0]); f++) { RECT rect = { f*56+20, e*56 + 20, f*56+60, e*56+60 }; InflateRect(&rect, 3. 3); // Увеличить фон FillRectChDC. & rect. GetSysColorBrush(COLOR_BTNFACE)); InflateRect(&rect. -3. -3); // Восстановить размер DrawEdge(hDC, & rect. Edge[e]. Flag[f]): *4, r~~™~™*% J ■^\kl r.'.r., ■ \ \ ' ' SlIsL | i ' j :' - ' \ ■ ■ < \ к ff } ' '" V >' s '' ' - \ , / '< •^ Л :..r.i*i .} ,; Рис. 9.7. Использование функции DrawEdge для рисования границ Функция DrawFrameControl рисует всевозможные элементы управления, обычно встречающиеся в строке заголовка, строке меню, полосах прокрутки, кнопках и всплывающих меню. Некоторые примеры приведены на рис. 9.8. За подробным описанием обращайтесь к MSDN. 'jJ5sJ ',,!S!,„J -„Ы,] r.ifecj , ж,,,,! Lf i .„ifrt.J ±1 zJ_±J ±1 zJ ^k'k ^ ГО'#г rjQJ x _ ness Рис. 9.8. Рисование различных элементов управления функцией DrawFrameControl
Эллипсы, секторы, сегменты и закругленные прямоугольники 497 Показанные на рисунке элементы управления нарисованы в прямоугольниках 40 х 40 пикселов, что значительно превышает стандартные размеры, используемые в системе. Обратите внимание на отсутствие неровных краев, которые обычно появляются при увеличении мелких растровых изображений. Возможно, вы и не подозревали, что при рисовании этих крестиков, стрелок, вопросительных знаков и т. д. Windows использует символы шрифта TrueType Marlett, чтобы изображение было полностью масштабируемым. Эллипсы, секторы, сегменты и закругленные прямоугольники В GDI предусмотрено несколько функций для рисования эллипса, его частей и даже гибрида прямоугольника с эллипсом — закругленного прямоугольника. Прототипы этих функций приведены ниже. BOOL Ellipse(HDC hDC. int nleftRect. int nTopRect. int nRightRect. int nBottomRect); BOOL Chord(HDC hDC. int nLeftRect. int nTopRect. int nRightRect. int nBottomRect. int nXRadiall. int nYRadiall. int nXRadial2. int nYRadial2); BOOL Pie(HDC hDC. int nLeftRect. int nTopRect. int nRightRect. int nBottomRect. int nXRadiall. int nYRadiall. int nXRadia!2. int nYRadia!2); BOOL RoundRect(HDC hDC. int nLeftRect. int nTopRect. int nRightRect. int nBottomRect. int nWidth. int nHeight); Эти четыре функции используют такие же ограничивающие прямоугольники, как и описанная выше функция Rectangle. Сходство проявляется и в принципе рисования: контур обводится текущим объектом пера в контексте устройства, а внутренняя область закрашивается текущей кистью. В совместимом графическом режиме, если толщина пера в системе координат устройства равна одному пикселу, правая и нижняя стороны не рисуются в соответствии с правилами включения/исключения. Однако в расширенном графическом режиме рисуются все четыре стороны. В документации Microsoft лишь упоминается тот факт, что в двух графических режимах прямоугольники рисуются по-разному. Линии, нарисованные пером со стилем PS_INSIDEFRAME, полностью находятся в ограничивающем прямоугольнике. На рис. 9.9 показано, как нарисованный эллипс выглядит на уровне пикселов. Первый эллипс нарисован однородным пером толщиной в один пиксел в совместимом графическом режиме; нижняя и правая стороны в ограничивающий прямоугольник не входят. Второй эллипс нарисован в расширенном графическом режиме с включением правой и нижней стороны. Третий эллипс нарисован пером толщиной в два пиксела со стилем PSINSIDEFRAME, в результате чего образовалась уродливая несимметричная фигура. Возможно, нарушение симметрии связано с аппроксимацией кривых Безье и выводом кривых Безье в виде набора
498 Глава 9. Замкнутые области отрезков. Хотя выше говорилось о том, что такая аппроксимация обеспечивает минимальную погрешность, для такой крошечной фигуры даже разница в один пиксел становится очень заметной. Left •Left м [ШИПИ Top [fflflfr^ | | | 111 п^шфп 111 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 В otto m 'Right Однородное перо «Left Bottom Right Bottom PSJNSIDEFRAME Рис. 9.9. Нарисованный эллипс (в увеличении) Однородное перо, расширенный режим Right На рис. 9.10 сравниваются результаты вызова функций Ellipse, Pie и Chord. Функция Ellipse рисует полный периметр эллипса текущим пером и закрашивает его внутреннюю часть текущей кистью. Окружность является частным случаем эллипса, ширина и высота которого выражена в физических единицах. Функция Pie рисует сектор — клиновидную фигуру, образованную частью периметра и двумя радиусами. Функция Chord рисует сегмент, образованный частью периметра эллипса и секущей, соединяющей две точки периметра. В обеих функциях, Pie и Chord, начальный и конечный угол задаются двумя точками (по аналогии с функцией Arc). Таким образом, в совместимом графическом режиме окончательный вид фигуры зависит от атрибута направления дуг контекста. В расширенном режиме дуги всегда рисуются против часовой стрелки в логической системе координат. Chord, против часовой стрелки (Left, Top) Pie, по часовой стрелке (xEnd, у End).. (Left, Top) (xEnd.yEnd) у" (xStart, yStart) (Bottom, Right) (xStart, yStart) (Bottom, Right) (Bottom, Right) Рис. 9.10. Функции Ellipse, Pie и Chord
Эллипсы, секторы, сегменты и закругленные прямоугольники 499 Кривые, нарисованные этими функциями, являются замкнутыми. Таким образом, при использовании геометрического пера на всех стыках применяется его атрибут соединения, а атрибут завершения не применяется. Периметры, нарисованные этими функциями, также могут включаться в объекты траекторий. В примере с функцией Chord задействовано косметическое перо со стилем PS_ALTERNATE, а для функции Pie — утолщенное геометрическое перо с заостренным соединением и стилем PS_INSIDEFRAME. Обратите внимание: дуга полностью расположена внутри ограничивающего прямоугольника, но на радиусах пикселы распределяются симметрично с обеих сторон. Для функции Ellipse на рисунке использовано узорное геометрическое перо и узорная кисть. Следующая функция рисует простейшие круговые диаграммы. void DrawPieChartCHDC hDC, int xO. int yO. int xl. int yl. double data[]. COLORREF co1or[], int count) { double sum - 0; for (int i=0; i<count; i++) sum +« data[i]; double angle - 0; for (i-0: i<count: i++) { double a - data[i] * 2 * 3.14159265358 / sum; HBRUSH hBrush - CreateSolidBrush(color[i]); HGDIOBJ hOld - SelectObjectChDC, hBrush); PieChDC. xO. yO. xl. yl. (int) ((xl-xQ) * cos(angle)). - (int) ((yl-yO) * sin(angle)). (int) ((xl-xO) * cos(angle+a)), - (int) ((yl-yO) * sin(angle+a))); angle += a; SelectObject(hDC. hOld); DeleteObject(hBrush); } } Функция RoundRect, предназначенная для рисования прямоугольников с закругленными углами, позволяет нарисовать прямоугольник, эллипс или любую промежуточную фигуру. При вызове ей передаются те же параметры ограничивающего прямоугольника, как и при вызове Rectangle или Ellipse. Последние два параметра, nWidth и nHeight, определяют размеры закругленных углов. Закругленные углы можно рассматривать как четыре четверти эллипса с шириной nWidth и высотой nHeight, соединенные прямыми линиями. Если оба параметра nWidth и nHeight равны нулю, функция Rou ndRect рисует прямоугольник. Если параметр nWidth равен ширине ограничивающего прямоугольника, а параметр nHeight совпадает с его высотой, функция RoundRect рисует эллипс. Если приложение передает в параметре nWidth или nHeight отрицательное число, GDI использует
500 Глава 9. Замкнутые области в вычислениях его абсолютную величину (модуль). Размеры ограничивающего прямоугольника также ограничивают размеры углов. Смысл параметров функции RoundRect иллюстрирует рис. 9.11. (nLeft nTop) InLeft + nWidth U* "XI Г" \} i nTop + nHeight * » 4 ) i • • / Ч !* ;'••» ^ ч' **! •'•*' *'-*-♦->*'♦•♦♦ *•*•♦ *■♦■♦ ♦•♦•♦ ♦•♦•♦>»Ч>-»--*"*'*'- - (nBottom, nRight) Рис. 9.11. Функция RoundRect: от прямоугольника к эллипсу Многоугольники Прямоугольник является частными случаем многоугольника — замкнутой фигуры, состоящей из двух и более вершин, соединенных прямыми линиями. Многоугольник может представлять собой треугольник, параллелограмм, прямоугольник, квадрат, восьмиугольник и т. д. В GDI API многоугольник представляется массивом структур POINT, определяющих координаты вершин. При одном вызове функции GDI позволяет нарисовать один или сразу несколько многоугольников. Данные нескольких многоугольников передаются в двух массивах — в одном содержится количество вершин каждого многоугольника, а в другом — координаты всех вершин. Ниже приведены прототипы функций GDI, предназначенных для рисования многоугольников. int GetPolyFillMode(HDC hDC); int SetPolyFillMode(HDC hDC, int iPloyFillMode); BOOL Polygon(HDC hDC, CONST POINT * IpPoints, int nCount); BOOL PolyPolygon(HDC hDC. CONST POINT * IpPoints. CONST int * IpPolyCounts. int nCount); Принцип рисования многоугольников функцией Polygon напоминает рисование ломаных линий функцией Polyline. Параметр IpPoints указывает на массив структур POINT, содержащих координаты вершин. Параметр nCount определяет количество вершин в массиве (не менее двух). Функция Polygon автоматически замыкает фигуру и при использовании геометрического пера оформляет каждую вершину в соответствии с атрибутом соединения. Контур многоугольника обводится текущим пером, а его внутренняя часть закрашивается текущей кистью.
Многоугольники 501 На этом сходство не заканчивается: рисование нескольких многоугольников функцией PolyPolygon напоминает процедуру рисования нескольких ломаных функцией PolyPolyline. В параметре nCount передается количество многоугольников. Параметр lpPolyCounts указывает на массив с количествами вершин для каждого многоугольника (не менее двух). Параметр lpPoints указывает на массив структур, содержащих координаты вершин. Функция PolyPolygon автоматически замыкает каждый многоугольник. Контур каждого многоугольника обводится текущим пером, а внутренняя часть закрашивается текущей кистью. В отличие от функций с ограничивающими прямоугольниками (таких, как Rectangle, Ellipse и Arc), исключающих правую и нижнюю стороны в совместимом графическом режиме, функции Polygon и PolyPolygon рисуют все свои вершины, причем это поведение сохраняется как в совместимом, так и в расширенном графическом режиме. Следовательно, прямоугольник, нарисованный как многоугольник по четырем углам, несколько отличается от обычного прямоугольника, нарисованного в совместимом режиме. В частности, это объясняет различия между поведением функции Rectangle в двух графических режимах. В результате применения аффинных преобразований с поворотами и сдвигом прямоугольник может превратиться в параллелограмм или утратить параллельность осям координат, поэтому графический механизм GDI в общем случае не может нарисовать преобразованный прямоугольник исходными средствами. Режим заполнения многоугольников Для простого (например, выпуклого) многоугольника внутренняя область определяется достаточно четко. Однако невыпуклый прямоугольник может состоять из нескольких частей, что затрудняет определение его внутренней области. В Windows GDI внутренняя область многоугольника определяется при помощи двух правил, которые в терминологии GDI называются «режимом заполнения многоугольников» (polygon fill mode). Режим заполнения многоугольников принадлежит к числу атрибутов контекста устройства, и для работы с ним используются функции GetPolyFillMode и SetPolyFillMode. Существует два допустимых значения режима — ALTERNATE и WINDING. Режим ALTERNATE, используемый в контекстах устройств по умолчанию, очень прост и нагляден. Принадлежность точки внутренней области многоугольника в режиме ALTERNATE проверяется следующим образом: из этой точки проводится луч в бесконечность в любом направлении и подсчитывается количество пересечений этого луча с контуром многоугольника. При нечетном количестве пересечений точка считается находящейся внутри, а при четном — снаружи. Примеры использования режима ALTERNATE приведены на рис. 9.12. На первом рисунке изображен простой ромб, являющийся выпуклым многоугольником. Каждая строка развертки внутри ромба дважды пересекается с периметром; точки между пересечениями образуют внутреннюю область многоугольника. На втором рисунке слева при соединении вершин многоугольника получается фигура в виде восьмиконечной звезды. Каждая строка развертки пересекается с периметром до шести раз, поэтому все точки между вторым
502 Глава 9. Замкнутые области и третьим, а также четвертым и пятым пересечением не считаются принадлежащими многоугольнику. На двух последних рисунках фигура состоит из двух многоугольников (меньший прямоугольник находится внутри большего). В режиме ALTERNATE эти два примера выглядят одинаково. Рис. 9.12. Режим заполнения многоугольников ALTERNATE Практическая реализация вычисляет ограничивающий прямоугольник для каждого многоугольника и проверяет серию строк развертки у = ymin + 0,5, ymin + 1,5, ..., у = углах - 0,5 на пересечение с контуром. Для каждой строки развертки общее количество пересечений всегда четно. В режиме ALTERNATE точки, находящиеся между первым и вторым, третьим и четвертым и т. д. пересечениями, считаются внутренними. Главный недостаток режима ALTERNATE связан с обработкой перекрывающихся многоугольников. К сожалению, некоторые из перекрывающихся частей исключаются из фигуры, а эта ситуация достаточно часто встречается в компьютерной графике. Как было показано в предыдущей главе, траектории, сгенерированные функцией WidenPath, могут содержать петли, которые в действительности являются перекрывающимися частями изображения. Перекрытия также очень часто возникают при пересечении нескольких многоугольников. Для решения этой проблемы в GDI был предусмотрен более сложный режим заполнения многоугольников WINDING. В режиме WINDING учитывается такой фактор, как направление кривых. Принадлежность точки многоугольнику проверяется тем же способом — из точки проводится луч в бесконечность и проверяются пересечения луча с контуром. Для каждого луча поддерживается счетчик с нулевым исходным значением. При каждом пересечении с участком контура, направленным по часовой стрелке, значение счетчика увеличивается, а при пересечениях с участками, направленными против часовой стрелки, счетчик уменьшается. Если итоговое значение счетчика отлично от нуля, считается, что точка принадлежит внутренней области фигуры; в противном случае точка считается внешней. На рис. 9.13 изображены те же многоугольники, нарисованные в режиме WINDING. Все контуры многоугольников направлены по часовой стрелке, кроме маленького многоугольника на последнем рисунке — он нарисован против часовой стрелки. Как видно из рисунка, вторая и третья фигуры в режиме WINDING выглядят иначе. Ниже приведен фрагмент программы, который использовался при построении рис. 9.12 и 9.13.
Многоугольники 503 Рис. 9.13. Режим заполнения многоугольников WINDING for (int t=0; t<2; t++) { logbrush.lbColor - RGB(0. 0. OxFF); KGDIObject pen (hDC. ExtCreatePen(PS_GEOMETRIC | PSJOLID | PS_JOIN_MITER. 3. & logbrush. 0. NULL)); if ( t—0 ) SetPolyFillMode(hDC. ALTERNATE); else SetPolyFillMode(hDC. WINDING); for (int m=0; m<4; m++) { SetViewportOrgEx(hDC. 120+m*220. 350+t*220, NULL); const int s0[] = { 4. 4. 100. 0. 100. 1. 100. 2. 100. 3 }; const int sl[] - { 8. 8. 100. 0. 100. 3. 100. 6. 100. 1. 100. 4. 100. 7, 100. 2. 100. 5 }; const int s2[] - { 10. 5. 100. 0. 100. 1. 100. 2. 100. 3, 100. 4. 50. 0. 50. 1. 50. 2. 50. 3. 50. 4 }; const int s3[] - { 10. 5. 100. 0. 100. 1. 100. 2. 100. 3. 100. 4. 50. 4. 50. 3. 50. 2. 50. 1, 50. 0 }; const int * spec[] - { sO. si. s2. s3 }; POINT P[10]; int n - spec[m][0]; int d = spec[m][l]: const int * s * spec[m]+2; for (i-0; i<n; i++) { P[i].x = (int) ( s[i*2] * cos(s[i*2+l] * 2 * 3.1415927 / d) ); P[i].y - (int) ( s[i*2] * sin(s[i*2+l] * 2 * 3.1415927 / d) ); } if ( m<2 ) Polygon(hDC. P. n); else { int V[2] = { 5. 5 }; // Количество точек // Количество вершин // каждого многоугольника // Индекс вершины
504 Глава 9. Замкнутые области PolyPolygon(hDC. P. V, 2); } } } Замкнутые траектории Траекторией в GDI называется объект, состоящий из нескольких линий, дуг и кривых Безье. Траекторию, построенную вызовами функций рисования линий и кривых между вызовами BeginPath и EndPath, можно обвести пером, закрасить кистью или сделать то и другое одновременно. Процесс обводки траектории пером рассматривается в главе 8, а сейчас нас больше интересует закраскг траекторий кистью. В GDI эта задача решается двумя функциями: BOOL FillPath(HDC hDC); BOOL StrokeAndFillPath(HDC hDC); Функция Fill Path замыкает все незамкнутые фигуры в текущей траектории, неявно связанной с контекстом устройства, и закрашивает их текущей кистью, выбранной в контексте устройства. Как было сказано выше, траектория состоит из одной или нескольких групп линий или кривых. В результате аппроксимации кривых траектория фактически превращается в совокупность многоугольников. Функция Fill Path практически эквивалентна вызову PolyPolygon с пустым пером. Как и при вызове PolyPolygon, при определении принадлежности точек внутренней области закрашиваемой траектории учитывается режим заполнения многоугольников. Перед тем как вернуть управление, функция Fill Path освобождает объект траектории в контексте устройства. Функция StrokeAndPath замыкает все незамкнутые фигуры текущей траектории, закрашивает их текущей кистью и обводит контуры текущим пером. Эта функция очень похожа на функцию PolyPolygon. Как и функция Fill Path, она тоже освобождает объект траектории в контексте устройства перед возвратом управления. Учтите, что StrokeFillPath в общем случае нельзя заменить последовательными вызовами StrokePath и Fill Path, что объясняется двумя причинами. Во-первых, каждая из этих функций освобождает траекторию, поэтому следующий вызов завершится неудачей, если только вы не позаботитесь о сохранении и восстановлении контекста. Во-вторых, при раздельных вызовах Stroke- Path и Fill Path генерируются перекрывающиеся области, что приводит к возникновению нежелательных эффектов при использовании некоторых растровых операций. Многоугольник или совокупность многоугольников всегда можно без потери точности преобразовать в траекторию. Траектория, не содержащая кривых, легко преобразуется в совокупность многоугольников. Траекторию с кривыми можно аппроксимировать функцией Fl attenPath, а затем преобразовать в совокупность многоугольников, однако линейная аппроксимация кривых приводит к потере точности и увеличению объема данных, обрабатываемых GDI. Следовательно, там, где это возможно, функциям траекторий следует отдавать предпочтение перед функциями многоугольников.
Замкнутые траектории 505 На рис. 9.14 приведены примеры использования функций FillPath и Fi 11- AndStrokePath, а также иллюстрируются последствия вызова WidenPath и режима заполнения многоугольников. ш ш Рис. 9.14. Функции FillPath, StrokeAnd Fill Path и режимы заполнения многоугольников Мы имеем дело с восемью разными случаями. В каждом случае траектория образуется двумя перекрывающимися эллипсами, повернутыми на 45°. Изображения в первом ряду были получены в режиме WINDING, во втором — в режиме ALTERNATE. В первом столбце использовалась функция FillPath с кистью светлого оттенка, а изображения второго столбца были построены функцией StrokeAnd- Fill с темным толстым пером. Третий столбец был создан функцией WidenPath с толстым пером, после чего была вызвана функция FillPath. Изображения последнего столбца были построены функцией Wi denPath с толстым пером и последующим вызовом StrokeAndFi 11 Path с тонким пером. Вспомните, о чем говорилось в главе 8, — функция WidenPath генерирует новую траекторию по периметру области, которая была бы закрашена при обводке траектории текущим пером, и петли в новой траектории возникают в результате соединения линий и кривых. Ниже приведен фрагмент кода, при помощи которого был построен рис. 9.14. Программа строит траекторию из двух эллипсов, получает ее данные функцией GetPath, поворачивает на 45° и с помощью результата строит траектории, используемые непосредственно при рисовании. void KMyCanvas::TestFi11PathCHDC hDC) { const int nPoint = 26; POINT Point[nPoint]: BYTE Type[nPoint]; // Построение траектории из двух эллипсов BeginPath(hDC); Ellipse(hDC. -100, -40. 100, 40); Ellipse(hDC. -40, -100. 40, 100); EndPath(hDC); // Получение данных траектории и поворот на 45 градусов GetPath(hDC, Point, Type, nPoint);
506 Глава 9. Замкнутые области for (int i=0; i<nPoint; i++) { double x = Point[i].x * 0.707; double у = Point[i].y * 0.707; Point[i].x = (int) (x - y); Point[i].y = (int) (x + y); KGDIObject brush(hDC, CreateSolidBrush(RGB(OxFF. OxFF, 0))); KGDIObject pen (hDC. CreatePen(PS_SOLID. 19, RGB(0, 0, 0xFF))): for (int t=0; t<8; t++) { SetViewportOrgEx(hDC. 120+(tS4)*180. 120+(t/4)*180. NULL); // Построение траектории из повернутых эллипсов BeginPath(hDC); PolyDraw(hDC, Point, Type. nPoint); EndPath(hDC); if ( t>=4 ) SetPolyFillMode(hDC, ALTERNATE); else SetPolyFillMode(hDC, WINDING); switch ( t % 4 ) { case 0 case 1 case 2 case 3 FillPath(hDC); break StrokeAndFillPath(hDC); break WidenPath(hDC); FillPath(hDC) WidenPath(hDC); break; KGDIObject thin(hDC. CreatePen(PS_SOLID, 3, RGB(0, 0. OxFF))); StrokeAndFillPath(hDC); SetViewportOrgEx(hDC. 0. 0, NULL); Регионы В главе 7 мы в общих чертах познакомились с регионами, уделяя основное внимание их использованию при отсечении. В Win32 GDI регионы важны не только в качестве структур данных, но и при выводе. В этом разделе подробно рассматриваются регионы и основные области их применения. Ниже перечислены важнейшие области применения регионов в Windows- программировании (некоторые из них уже упоминались в главе 7).
Регионы 507 О Определение формы окна: SetWindowRgn. О Хранение информации об участках окна, нуждающихся в перерисовке: Inva- lidateRgn, GetUpdateRgn. О Отсечение: SelectClipRgn, SetMetaRgn. О Графический вывод: регион можно непосредственно воспроизвести на экране. О Проверка принадлежности: регионы могут использоваться для представления геометрических фигур. О DirectDraw: структура данных региона используется интерфейсом IDirect- Clipper. С точки зрения GDI регион определяет совокупность точек в координатном пространстве. Эта совокупность может быть пустой, а может занимать все координатное пространство; иметь прямоугольную или любую неправильную форму. Объект региона находится под управлением GDI и представляет некоторый регион в системе. Как и в случае с другими объектами GDI, после создания объекта региона приложение получает лишь его манипулятор, который может передаваться GDI при ссылках на этот объект. Манипуляторы регионов в GDI относятся к типу HRGN. Внутренняя структура данных, представляющая объект региона, достаточно сложна и может иметь весьма внушительные размеры. Когда объект региона станет ненужным, его следует удалить функцией DeleteObject. Создание объекта региона При создании новых объектов регионов используются следующие функции: HRGN CreateRectRgnCint nLeftRect. int nTopRect, int nRightRect, int nBottomRect); HRGN CreateRectRgnIndirect(CONST RECT * lprc); HRGN CreateRoundRectRgn(int nLeftRect.int nTopRect, int nRightRect, int nBottomRect, int nWidthEllipse. int nHeightEllipse): HRGN CreateEllipticRgnUnt nLeftRect, int nTopRect, int nRightRect, int nBottomRect); HRGN CreateEllipticRgnIndirect(CONST RECT * lprc); HRGN CreatePolygonRgnCCONST POINT * Ippt. int cPoints, int fnPolyFillMode); HRGN CreatePolyPolygonRgnCCONST POINT * lppt. CONST INT * lpPolyCounts. int nCount. int fnPolyFillMode); HRGN PathToRegion(HDC hDC); Все функции этой группы, за исключением PathToRegion, не зависят от контекста устройства, пера или кисти. Объект региона является независимым объектом, представляющим геометрическую фигуру. В другом контексте координаты региона интерпретируются как логические координаты или координаты устройства. Функция CreateRectRgn создает регион, содержащий все точки прямоугольной области, которая обычно определяется своими левым верхним и правым нижним углами. Две точки, определяющие прямоугольник, не обязательно должны быть правильно упорядочены; GDI нормализует их по правилам внутреннего представления GDI (левая координата меньше правой, верхняя координата
508 Глава 9. Замкнутые области меньше нижней). Функция CreateRectRgnIndirect представляет собой упрощенную разновидность CreateRectRgn, которая получает параметры через структуру RECT. В Windows NT/2000 реализация CreateRectRgnlndirect сводится к простому вызову CreateRectRgn. При использовании прямоугольного объекта региона он всегда интерпретируется по правилу исключения нижней и правой сторон. Это правило действует как в совместимом, так и в расширенном графических режимах. Например, вызов CreateRectRgn(0,0,0,0) создает пустой регион (вместо региона, содержащего единственную точку (0,0)). В системе координат устройства вызов CreateRectRgn (0,0,1,1) создает регион, содержащий единственную точку (0,0), и в этом смысле он эквивалентен вызову CreateRectRgn(1,1,0,0). Функция CreateRoundRectRgn(0,0,0,0) создает регион, состоящий из всех точек прямоугольника с закругленными углами. Каждый из четырех углов соответствует одной четверти эллипса nWidthET I ipsexnHeightEl 1 i pse. По каким-то неизвестным причинам при создании региона в виде прямоугольника с закругленными углами его нижняя и правая стороны исключаются из внутренней структуры данных, представляющей регион. Обратите внимание: ситуация отличается от прямоугольного региона, у которого нижняя и правая стороны включаются во внутреннее представление. Таким образом, при использовании в контексте устройства прямоугольника с закругленными углами с правой и нижней стороны исключаются по два ряда пикселов. При использовании в логической системе координат ширина исключаемых краев равна одной логической единице плюс одной единице устройства. Функция CreateEllipticRgn создает регион, состоящий из всех внутренних точек эллипса. Функция CreateEllipticRgnlndirect представляет собой упрощенный вариант, который переадресует вызов этой функции. Как и CreateRoundRectRgn, функция CreateEllipticRgn исключает нижнюю и правую стороны из внутреннего представления региона. Таким образом, при использовании эллиптического региона правая и нижняя стороны исключаются дважды. В Microsoft Knowledge Base имеется статья, посвященная проблеме исключения сторон при работе с функцией CreateEllipticRgn (Q83807). В ней сказано, что функция Ellipse включает в вычисления правый нижний угол ограничивающего прямоугольника, а функция CreateEllipticRgn исключает эту точку. Впрочем, утверждения Microsoft Knowledge Base расходятся с практикой. Из рис. 9.8 видно, что при вызове функции Ellipse в совместимом графическом режиме правая и нижняя стороны также исключаются. Как показывает рис. 9.15, функция CreateEllipticRgn в совместимом графическом режиме всегда исключает на одну логическую единицу больше, чем функция Ellipse. На рис. 9.15 изображены прямоугольник, прямоугольник с закругленными углами и эллипс. Рисунок позволяет изучить их строение на уровне отдельных пикселов. Эти три базовые фигуры были нарисованы несколькими способами — прямыми вызовами GDI API, созданием и выводом региона, преобразованием региона в траекторию и преобразованием траектории в регион. Все способы были проверены как в совместимом, так и в расширенном графическом режиме. Из рисунка видно, что в совместимом режиме функции Rectangle, Ellipse и RoundRectangle исключают правую и нижнюю стороны, а в расширенном режиме эти стороны включаются в расчеты. Функция CreateRectRgn всегда исключает
Регионы 509 правую и нижнюю стороны, а функции CreateRoundRectRgn и CreateEllipticRgn исключают их дважды. Однако из рисунка не видно, что фигура, нарисованная функцией CreateEllipticRgn, несколько отличается по форме от эллипса, нарисованного функцией Ellipse, даже если учесть поправку и увеличить ее размер на единицу. Если вам нужна стопроцентная точность (например, если созданный регион требуется для отсечения результата вызова Ellipse), Microsoft рекомендует использовать функцию региона. R 3 R R О О П п я п w й Прямой вызов функций GDI API Создание и вывод региона Преобразование региона в траекторию Преобразование траектории в регион GM_COMPATIBLE GM_ADVANCED GM_COMPATIBLE GM_ADVANCED GM_COMPATIBLE GM_ADVANCED Рис. 9.15. Функции CreateRectRgn, CreateRoundRectRgn и CreateEllipticRgn Функция CreatePolygonRgn создает регион, состоящий из всех внутренних точек многоугольника. Как упоминалось в разделе «Многоугольники», вопрос о принадлежности точки многоугольнику решается с учетом действующего режима заполнения многоугольников. Чтобы функция CreatePolygonRgn не зависела от контекста устройства, режим заполнения передается ей в последнем параметре. Обе функции включают все координаты в свои внутренние представления регионов, однако при закраске региона правая и нижняя стороны исключаются. Следовательно, площадь региона, созданного в результате вызова CreatePolygonRgn, меньше площади прямоугольника, созданного функцией Polygon с теми же параметрами. Последняя функция создания регионов, PathToRegion, преобразует текущую траекторию контекста устройства в регион. Объект траектории отличается от остальных объектов GDI тем, что он всегда остается связанным с конкретным контекстом устройства на уровне GDI API, поэтому GDI имеет возможность хранить объекты траекторий в координатах устройства, а не в логических координатах. Функция PathToRegion замыкает все незамкнутые фигуры траектории и преобразует их в регион в соответствии с текущим режимом заполнения многоугольников, выбранным в контексте устройства. Созданный регион использует систему координат устройства данного контекста — в отличие от функции GetPath, которой требуется обратное преобразование для перевода данных траектории из координат устройства в логические координаты. Хотя при построении региона функция PathToRegion задействует все исходные координаты, в процессе использования региона происходит исключение его правой и нижней сторон. Подведем итоги. Различия в площади региона и фигуры, нарисованной соответствующей функцией GDI, объясняется тремя причинами. Во-первых, функции CreateRectRgn, CreateRectRgnlndirect, CreatePolygonRgn, CreatePolyPolygonRgn
510 Глава 9. Замкнутые области и PathToRgn при построении внутреннего представления региона используют исходные координаты, а функции CreateRoundRectRgn, CreateEllipticRgn и CreateEllip- ticRgnIndirect уменьшают координаты правой и нижней сторон ограничивающего прямоугольника на единицу. Вероятно, это обстоятельство следует считать дефектом реализации, а не сознательным архитектурным решением. Во-вторых, при использовании региона в контексте устройства (с целью отсечения или при рисовании) его правая и нижняя стороны всегда исключаются. В-третьих, функции создания регионов одинаково ведут себя в обоих графических режимах, а функции рисования прямоугольников, эллипсов и прямоугольников с закругленными углами включают правую и нижнюю стороны в расширенном графическом режиме. Операции с объектами регионов Регион представляет собой множество точек двумерного пространства, поэтому определение операций над множествами для объектов регионов выглядит вполне естественно. В GDI предусмотрен богатый ассортимент функций для получения информации, перемещения, преобразования, сброса и объединения регионов. Прототипы этих функций приведены ниже. BOOL PtlnRegiorKHRGN hrgn, int X, int Y); BOOL RectInRegion(HRGN hrgn. CONST RECT * Iprc); BOOL EqualRgn(HRGN hSrcRgnl. HRGN hSrcRgn2); int GetRgnBox(HRGN hrgn. LPRECT Iprc); int CombineRgnCHRGN hrgnDest. HRGN hrgnSrcl. hrgnSrc2. int fnCombineMode); int OffsetRgnCHRGN hrgn.int nXOffset. int nYOffset): DWORD GetRegionData(HRGN hRgn. DWORD dwCount. LPRGNDATA lpRgnData); HRGN ExtCreateRegion(CONST XFORM * IpXForm, DWORD nCount. CONST RGNDATA * lpRgnData); Получение информации о регионе Функция PtlnRegion проверяет, принадлежит ли точка (х,у) множеству точек региона. Считается, что правая и нижняя стороны региона ему не принадлежат. Например, для пустого региона, созданного вызовом CreateRectRgn(0,0,0,0), функция PtlnRegion всегда возвращает FALSE; для региона из одной точки, созданного вызовом CreateRectRgn(0,0,l,l), функция PtlnRegion возвращает TRUE только для точки (0,0). Функция PtlnRegion чрезвычайно полезна при реализации экзотических разновидностей кнопок или интерактивных областей, изменяющих цвет под курсором мыши (что говорит о том, что щелчок на этой области обрабатывается каким-то особым образом). Приложение должно лишь создать объект региона, соответствующий интерактивной области, и вызвать функцию PtlnRegion при обработке сообщения WMM0USEM0VE для изменения изображения. Аналогичные действия следует включить и в обработку сообщений мыши, чтобы обнаружить щелчок внутри интерактивной области.
Регионы 511 В листинге 9.1 приведен класс KButton для работы с интерактивными кнопками, а также два производных класса для работы с прямоугольными и эллиптическими кнопками. Функция DefineButton задает ограничивающий прямоугольник кнопки. Виртуальная функция DrawButton создает объект региона и рисует кнопку в зависимости от того, был ли на ней сделан щелчок мышью. Функция IsOnButton при помощи PtlnRegion проверяет, находится ли точка (х,у) внутри кнопки. Функция UpdateButton обновляет изображение кнопки в соответствии с текущей позицией курсора мыши. Листинг 9.1. Класс KButton class KButton { protected: HRGN mJiRegion; bool m_bOn; int m_x, m_y, m_w. m_h; public: KButtonО { mJiRegion = NULL: m bOn = false; virtual -KButtonO { } void DefineButton(int x, int y, int w, int h) { m_x = x; m_y = y; m_w = w; m_h = h; } " virtual void DrawButton(HDC hDC) { void UpdateButton(HDC hDC. LPARAM xy) { if ( m_bOn != IsOnButton(xy) ) { m_bOn = ! m_bOn: DrawButton(hDC); bool IsOnButton(LPARAM xy) const { return PtlnRegionCmJiRegion. LOWORD(xy). HIWORD(xy)) != 0: Продолжение &
512 Глава 9. Замкнутые области Листинг 9.1. Продолжение class KRectButton : public KButton { public: void DrawButton(HDC hDC) { RECT rect = { m_x, m_y, m_x+m_w, m_y+m_h }; if ( mJiRegion == NULL ) m_hRegion = CreateRectRgnIndirect(& rect); InflateRect(&rect. 2. 2); FillRect(hDC. & rect. GetSysColorBrush(COLOR_BTNFACE)); InflateRect(&rect. -2. -2); DrawFrameControKhDC. &rect. DFC_CAPTION. DFCS_CAPTIONHELP | (m_bOn ? 0 : DFCSJNACTIVE)); } }: class KEllipseButton : public KButton { publi с: void DrawButtonCHDC hDC) { RECT rect = { m_x. m_y. m_x+m_w. m_y+m_h }; if ( mJiRegion == NULL ) m_hRegion = CreateEllipticRgnIndirect(& rect); if ( m_bOn ) { FillRgn(hDC. mJiRegion, GetSysColorBrush(COLOR_CAPTIONTEXT)); FrameRgn(hDC. m_hRegion. GetSysColorBrush(COLOR_ACTIVEBORDER). 2, 2); } else { FillRgn(hDC. m_hRegion. GetSysColorBrush(COLORJNACTIVECAPTIONTEXT)); FrameRgn(hDC. mJiRegion. GetSysColorBrush(COLORJNACTIVEBORDER). 2. 2); } } }: Код следующего фрагмента отображает клиентскую область с двумя интерактивными кнопками, изменяющими цвет при наведении на них курсора мыши. Если щелкнуть мышью на любой из этих кнопок, на экране появляется окно с сообщением. LRESULT KMyCanvas::WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM lParam) { switch( uMsg )
Регионы 513 { case WM_CREATE: rbtn.DefineButtondO. 10. 50. 50): ebtn.DefineButtondO. 70. 50. 50); return 0; case WM_PAINT: { PAINTSTRUCT ps; HDC hDC = BeginPaint(m_hWnd. &ps); rbtn.DrawButton(hDC); ebtn.DrawButton(hDC); EndPaint(m_hWnd. &ps); } return 0; case WM_MOUSEMOVE: { HDC hDC = GetDC(hWnd) rbtn.UpdateButton(hDC ebtn.UpdateButton(hDC ReleaseDCChWnd. hDC); } return 0; case WM_LBUTTONDOWN: if ( rbtn.IsOnButton(lParam) ) MessageBox(hWnd. "Rectangle Button Clicked". NULL. MB_OK); if ( ebtn.IsOnButton(lParam) ) MessageBoxChWnd. "Ellipse Button Clicked". NULL. MB_OK); return 0; default: lr = DefWindowProcChWnd. uMsg. wParam. IParam); } } Еще одна функция, RectinRegi on, проверяет, принадлежат ли какие-либо из точек прямоугольника, заданного параметром lprc (за исключением правой и нижней сторон), заданному региону. Обратите внимание: функция не проверяет, находится ли весь прямоугольник внутри региона. Возможно, ее следовало бы переименовать в RectTouchRegion. Функция Equal Region сравнивает два региона и проверяет, содержат ли они одинаковые множества точек. Если в двух параметрах передаются одинаковые манипуляторы, несомненно, регионы совпадают. Но даже разные манипуляторы могут соответствовать одинаковым множествам точек. Например, вызовы CreateRectRgn(0,0,0,0) и CreateRectRgnQ, 1,1,1) создают пустые регионы, которые с точки зрения функции Equal Rect являются равными. По наличию функции Equal Region можно сделать обоснованное предположение о том, что объекты регионов обладают однозначным внутренним представлением, то есть каждому множеству точек соответствует ровно одно представлерше. В противном случае функция Equal Region работала бы очень медленно. IParam); IParam);
514 Глава 9. Замкнутые области Функция GetRgnBox возвращает ограничивающий прямоугольник региона. Для пустого множества точек ограничивающий прямоугольник всегда определяется квартетом {0,0,0,0}. Для других прямоугольных регионов ограничивающий прямоугольник представляет собой исходный прямоугольник региона, нормализованный таким образом, чтобы поле left было меньше right, a top — меньше bottom. Как говорилось выше, для регионов в форме эллипса или прямоугольника с закругленными углами GDI удаляет по одной единице с правой и нижней сторон, поэтому ограничивающий прямоугольник получается меньше прямоугольника, указанного при определении региона. Например, CreateEl I i pti cRgn(10,10,1,1) возвращает регион с ограничивающим прямоугольником {1,1,9,9}. По ограничивающему прямоугольнику региона можно быстро узнать, принадлежит ли отдельная точка или какие-либо точки области заданному региону; это особенно важно при критических требованиях по быстродействию. Прямоугольник, возвращаемый функцией GetRgnBox, позволяет приложению выполнить быструю проверку без применения функций GDI и переходов из пользовательского режима в режим ядра. Прямоугольник rcPaint в структуре PAINTSTRUCT, заполняемой функцией BeginPaint, содержит данные ограничивающего прямоугольника для системного региона окна. При помощи этого прямоугольника многие приложения определяют, нужно ли перерисовывать те или иные объекты при обработке сообщения WMPAINT. Операции с множествами Функция CombineRgn позволяет выполнять с объектами регионов некоторые полезные операции, позаимствованные из теории множеств. Функция получает три объекта регионов hrgnDest, hrgnSrcl и hrgnSrc2, а также целочисленный параметр fnCombineMode. При вызове CombineRgn параметр hrgnDest должен содержать манипулятор действительного объекта региона. Функция заменяет объект региона, представленный этим манипулятором, объектом, сгенерированным при вызове функции. Параметр fnCombi neMode определяет операцию, выполняемую с регионами hrgnSrcl и hrgnSrc2, — копирование, пересечение, объединение, вычитание или симметричная разность. Операции с регионами, обеспечивающие пять различных режимов комбинирования регионов, были перечислены в главе 7 (см. табл. 7.1), а графическое представление этих операций приведено на рис. 9.16. Два региона RGN_AND RGN_OR RGN_XOR RGN_DIFF RGN_COPY Рис. 9.16. Операции с регионами
Регионы 515 Функции GetRgnBox и CombineRgn возвращают целочисленный код сложности сгенерированного региона или код ошибки. Возможные результаты перечислены в табл. 9.1. Таблица 9.1. Результаты вызовов функций GetRgnBox и CombineRgn Константа Описание NULLREGION Пустой регион SIMPLEREGION Регион определяется одним прямоугольником C0MPLEXREGI0N Регион определяется несколькими прямоугольниками ERROR Ошибка — недопустимые значения параметров или нехватка памяти. Регион не создается Если регион представляет собой множество точек, как должно выглядеть универсальное множество (то есть множество, содержащее все возможные точки)? В Win32 GDI логические координаты задаются в виде 32-разрядных целых чисел, а координаты устройства в системах семейства NT задаются 27-разрядными неотрицательными целыми числами. В системах, не входящих в семейство NT, координаты усекаются до 16-разрядных целых чисел. Следовательно, универсальное множество для регионов должно определяться ограничивающим прямоугольником [0x80000000,0x80000000,0x7FFFFFFF,0x7FFFFFFFl. Однако в системах семейства NT, похоже, GDI усекает эти числа до 28-разрядных целых, поэтому ограничивающий прямоугольник универсального множества уменьшается до [-(1«27),-(1«27),(1«27)-1,(1«27)-1]. Действует и другое недокументированное ограничение: при использовании функций регионов значения логических координат ограничиваются 28-разрядными целыми числами со знаком вместо 32-разрядных целых чисел со знаком. Операции с множествами очень полезны при геометрических вычислениях. Если вы хотите узнать, перекрываются ли две замкнутые траектории, можно преобразовать их в многоугольники функцией FlattenPath и самостоятельно реализовать алгоритм проверки перекрытия для многоугольников, но сделать это не так уж просто. Существует другое решение: преобразовать траектории в регионы и вычислить их пересечения функцией CombineRgn(RGN_AND). Если пересечение не пусто, значит, две исходные траектории пересекаются друг с другом. Такие проверки часто встречаются при программировании игр, где соприкосновение двух объектов обычно сопровождается теми или иными действиями. Используя операции с множествами, можно легко определить, содержится ли регион внутри другого региона. Выше уже говорилось о том, что функция RectlnRegion проверяет лишь факт соприкосновения, то есть наличия общих точек у прямоугольника и региона. Приведенная ниже функция проверяет, содержится ли прямоугольник внутри региона. Для этого она вычисляет объединение прямоугольника с регионом функцией CombineRgn и затем при помощи функции Equal Rgn проверяет, совпадает ли объединенный регион с исходным. BOOL RectContainedlnRegiorKHRGN hrgn. CONST RECT * Iprc) { HRGN hCombine = CreateRectRgnIndirect(Iprc);
516 Глава 9. Замкнутые области CombineRgrU hCombine. hrgn, hCombine, RGN_0R); BOOL rslt = EqualRgnChCombine. hrgn); DeleteObject(hCombine); return rslt; Преобразования данных регионов GDI поддерживает преобразования смещения, зеркального отражения и масштабирования между страничной системой координат и системой координат устройства. В системах семейства NT интерфейс GDI поддерживает более общие аффинные преобразования между мировыми и страничными координатными пространствами, обеспечивающие возможность поворота и сдвига. Все эти преобразования поддерживаются и для объектов регионов с одним логичным ограничением — повороты и сдвиг поддерживаются напрямую только в системах семейства NT. Функция OffsetRgn обеспечивает простейшее преобразование — смещение. Она получает величины смещений по осям х и г/, прибавляет их ко всем координатам объекта региона и возвращает код сложности региона. Функция OffsetRgn может применяться для многократного рисования объектов на поверхности устройства (прорисовкой самого региона или его применением для отсечения). Приложение может использовать регион, переместить его в другое место функцией OffsetRgn и воспользоваться им снова. Кроме того, при помощи этой функции можно отслеживать движущиеся объекты в игре или анимационном ролике. Если, например, регион описывает контуры гоночной машины, то при движении машины должен перемещаться и регион, используемый для обнаружения столкновений. Более общие преобразования выполняются двумя функциями: GetRegionData и ExtCreateRegion. Функция GetRegionData преобразует внутреннюю структуру данных региона в структуру RGNDATA, которая может использоваться в программе. Функция ExtCreateRegion получает структуры RGNDATA и XF0RM (определение аффинного преобразования), преобразует данные и создает новый регион. Важнейшая структура RGNDATA определяется следующим образом: typedef struct _RGNDATAHEADER { DWORD dwSize; // sizeof(RGNDATAHEADER) DWORD iType; // RDH_RECTANGLES DWORD nCount; // количество прямоугольников в регионе DWORD nRgnSize; // размер буфера с данными региона RECT rcBounds; // ограничивающий прямоугольник } RGNHEADER; typedef struct _RGNDATA { RGNDATAHEADER rdh; char Buffer[l]; // переменный размер } RGNDATA; При знакомстве со структурой RGNDATA следует обратить внимание на некоторые интересные обстоятельства. Во-первых, RGNDATA не является внутренней структурой данных, используемой для представления регионов в GDI. В системах семейства NT регионы представляются более эффективной структурой данных — динамическим массивом REGI0N0BJ, содержащим массив структур SCAN. Структу-
Регионы 517 pa SCAN описывает «строку развертки региона», то есть пересечение региона с областью, ограниченной двумя горизонтальными линиями, при условии, что пересечение контура региона с этой областью состоит только из вертикальных отрезков. В структуре SCAN хранится массив координат х этих отрезков, причем количество элементов массива всегда четно. Нет никаких фактов, которые бы подтверждали, что регионы представляются трапециевидными фигурами, как заявлено в документации Microsoft. Описание региона массивом структур SCAN позволяет хранить для каждого пересечения только координату х, поскольку координаты у у них одинаковые; тем самым обеспечивается экономия памяти. Кроме того, упорядоченность массива структур SCAN сверху вниз и слева направо обеспечивает однозначное представление регионов и эффективные операции с ними. Например, при объединении нескольких мелких регионов в один большой регион функцией CombineRgn внутреннее представление итогового региона не должно зависеть от порядка объединения регионов. За подробностями обращайтесь к разделу «WinDbg и расширение отладчика GDI» в главе 3. В системах, не входящих в семейство NT, вместо 32-разрядных координат используются 16-разрядные. Объем памяти, занимаемой структурой REGI0N0BJ, зависит от сложности региона. Предположим, регион делится на N строк развертки и среднее количество пересечений на строку равно М. Минимальная высота строки развертки равна единице, но может быть равна и нескольким единицам. Объем структуры REGI0N0BJ вычисляется по формуле: sizeof(REGIONOBJ) = (4*М + 16)*(N+2)+40 Для прямоугольного региона одна строка развертки занимает весь прямоугольник, поэтому N - 1, М = 2; объем структуры равен всего 112 байтам. GDI может хранить только ограничивающий прямоугольник и специальный флаг, который указывает на то, что это простой регион. Для эллиптического региона количество строк развертки приближается к 2/3 высоты эллипса, М = 2. При создании региона для эллипса, занимающего всю страницу на принтере с разрешением 600 dpi, N = 2/3 х И х 600 = 4400, sizeof (REGI0N0BJ) = 111 Кбайт. Благодаря регионам приложение может реализовать цветовые ключи; для этого регион создается на базе всех пикселов растра, цвет которых отличается от цветового ключа. Этот регион используется для отсечения при выводе растра, в результате чего все пикселы, цвет которых совпадает с цветом ключа, не выводятся. В худшем случае значение N равно высоте растра, М — половине ширины растра, а структура REGI0N0BJ содержит по 2 байта на каждый пиксел. Если ваше приложение интенсивно работает с регионами, не забывайте о затратах памяти. В действительности графический механизм выделяет больше памяти, чем необходимо для представления региона; излишек предназначен для возможного увеличения размера растра. Аналогичная стратегия используется при работе с динамическими массивами для сведения к минимуму затрат на динамическое выделение памяти и копирование данных. Структура REGI0N0BJ фактически является двумерной; первое измерение представляет собой массив структур SCAN, упорядоченных по возрастанию координаты у, а второе измерение — упорядоченный массив координат х. Такая архитектура обеспечивает приемлемое быстродействие операций с регионами.
518 Глава 9. Замкнутые области Предположим, требуется узнать, принадлежит ли точка региону. Если точка прошла проверку на принадлежность ограничивающему прямоугольнику, ее координату у можно сравнить с координатой у каждой структуры SCAN методом линейного поиска. Размер структуры SCAN хранится в ее начале и в конце, что значительно упрощает переход к следующей структуре. После нахождения нужной структуры SCAN производится следующий линейный поиск по координате х. Таким образом, время выполнения PtlnRegion имеет порядок 0(N) + 0(М). Оптимальный алгоритм с применением бинарного поиска обеспечивает порядок OClog(N)) + 0(log(M)), но это требует усложнения структуры данных. GDI по возможности старается использовать небольшие структуры данных, объединяемые указателями, чтобы свести к минимуму динамическое выделение памяти. Функция CombineRgn для объединения, пересечения и вычитания регионов обладает аналогичной сложностью в отношении количества необходимых сравнений. Впрочем, копирование данных в новый регион требует дополнительного времени. Таким образом, при объединении п регионов функцией CombineRgn в худшем случае сложность имеет порядок 0(п2), то есть с удвоением количества регионов затраты времени возрастают в четыре раза. Подобных алгоритмов следует по возможности избегать. Структура RGNDATA обеспечивает единый интерфейс для работы с регионами в приложениях Win32, работающих на разных платформах. Кроме того, структура RGNDATA используется интерфейсом IDirectDrawClipper DirectDraw. Эта структура содержит заголовок фиксированного размера с информацией о размере региона, типе и ограничивающем прямоугольнике, а также массив структур RECT. В RGNDATA двумерное внутреннее представление региона в GDI преобразуется в одномерную структуру данных. Для представления региона с N строками развертки и средним количеством пересечений на строку, равным М, необходимо М/2 х N прямоугольников. Общие затраты памяти вычисляются по следующей формуле: sizeof(RGNDATA) = 8 * М * N + 32 Для региона, состоящего из одной выпуклой фигуры (например, прямоугольника, эллипса или прямоугольника с закругленными углами) М = 2, поэтому структура RGNDATA занимает примерно 2/3 от объема REGI0N0BJ. При больших значениях М объем структуры RGNDATA почти вдвое превышает объем REGI0N0BJ. Структура RGNDATA (как и структура REGI0N0BJ) генерируется GDI, и ее элементы всегда располагаются в строго определенном порядке. Входящие в нее структуры RECT упорядочиваются слева направо, сверху вниз. Все структуры RECT нормализованы, то есть поле left меньше right, a top меньше bottom. Поскольку структура RGNDATA представляет собой линейный массив прямоугольников, приложение может ускорить работу некоторых алгоритмов. Например, проверку наличия общих точек у прямоугольника с регионом, представленным структурой RGNDATA, можно осуществить с применением бинарного поиска в массиве вместо линейного, что позволяет уменьшить сложность до 0(log(M x N)). С другой стороны, при операциях с множествами, использующими CombineRgn, производится копирование данных, при этом затраты времени связаны линейной зависимостью с объемом данных. Функция GetRegionData записывает структуру RGNDATA в буфер, предоставленный приложением. Впрочем, перед вызовом GetRegionData точный размер струк-
Регионы 519 туры обычно неизвестен приложению. Одна из возможных стратегий выглядит так: приложение берет размер RGNDATA, подходящий для 80 % случаев, выделяет буфер соответствующего размера (вероятно, в стеке) и вызывает функцию GetRegionData, передавая ей размер буфера и указатель на него. Если буфер окажется достаточно большим, он заполняется структурой RGNDATA, точный размер которой возвращается функцией. Если буфер слишком мал, функция GetRegionData возвращает 0 и буфер не заполняется. В этом случае приложение вызывает GetRegionData, передавая 0 в параметре dwCount и NULL в параметре IpRgnData; GDI возвращает требуемый размер буфера. Приложение выделяет память (как правило, из кучи) и снова вызывает GetRegionData, передавая точный размер буфера и указатель на него. Конечно, приложение может отказаться от самого первого вызова и сразу вызвать GetRegionData для получения размера буфера. На рис. 9.17 показано, как выглядит структура RGNDATA для регионов в виде прямоугольника, прямоугольника с закругленными углами, эллипса и треугольника; все эти регионы имеют одинаковый ограничивающий прямоугольник {0,0,21,21}. Прямоугольный регион состоит из единственного прямоугольника; регион в форме закругленного прямоугольника содержит 7 прямоугольников, в основном для закругленных углов; эллиптический регион содержит 13 прямоугольников, а у треугольного региона количество прямоугольников достигает 21. Ограничивающие прямоугольники RGNDATA на рисунке обведены черным пером, а прямоугольники массива RECT окрашены попеременно в темно-серый и светло-серый цвета. CreateRectRgn: (0,0,21,21) rcBound: (0,0,21,21) nCount: 1 CreateRoundRectRdn: (0,0,21,21,10,10) rcBound: (0,0,20,20) nCount: 7 CreateEllipticRgn: (0,0,21,21) rcBound: (0,0,20,20) nCount: 13 CreatePolygonRgn: (0,0,21,0,10,21) rcBound: (0,0,21,21) nCount: 21 Размер: 48 байт Размер: 144 байта Размер: 240 байт Размер: 368 байт Рис. 9.17. Структура RGNDATA для разных видов регионов Функция ExtCreateRegion позволяет создать объект региона по структуре RGNDATA с возможностью применения аффинного преобразования к данным региона. Структуру RGNDATA можно получить либо непосредственно от GDI при помощи функции GetRegionData, либо сгенерировать в приложении. При вызове ExtCreateRegion все структуры RECT должны быть нормализованы, а поле rcBounds структуры RGNDATA должно содержать общий ограничивающий прямоугольник. В противном случае попытка вызова завершится неудачей или регион будет сгенерирован неверно.
520 Глава 9. Замкнутые области Первый параметр функции ExtCreateRegion содержит указатель на матрицу аффинного преобразования (в системах, не входящих в семейство NT, преобразование не может включать сдвиги и повороты). Преобразования регионов очень часто требуются в приложениях. Например, регион, возвращаемый функцией PathToRegion, определяется в системе координат устройства. Если регион используется непосредственно для рисования, а не для отсечения, приложение должно преобразовать его в логическую систему координат. Для простейшего смещения достаточно функции Of fsetRgn, но для более общих преобразований следует воспользоваться функцией ExtCreateRegion. Структура RGNDATA представляет регион в целочисленных координатах; кривые аппроксимируются отрезками, как при вызове FlattenPath для траектории. Следовательно, при масштабировании часто возникают «зазубрины». Если регион можно определить в виде траектории, преобразование траектории с последующим переходом к региону обеспечит более точный результат. По имеющейся информации функция ExtCreateRegion в системах, не входящих в семейство NT, не может одновременно работать более чем с 4000 прямоугольников. Существует обходное решение — разделить большую структуру RGNDATA на несколько меньших, вызвать ExtCreateRegion для каждой структуры, а затем объединить результаты функцией Combi neRgn. В листинге 9.2 приведен простой класс для работы с функциями GetRegion- Data и ExtCreateRegion. Листинг 9.2. Класс KRegion: работа с данными региона class KRegion { public: int mjiRegionSize; i nt mjiRectCount ; RECT * m_pRect; RGNDATA * m_pRegion; KRegionO { mjiRegionSize mjiRectCount m_pRegion m_pRect } void Reset(void) { if ( m_pRegion ) delete [] (char *) m_pRegion; m_pRegion = NULL; mjiRegionSize = 0; mjiRectCount = 0: m_pRect = NULL; } - 0; = 0; « NULL; = NULL; -KRegionO
Регионы 521 ResetO; BOOL GetRegionData(HRGN hRgn); HRGN CreateRegionCXFORM * pXForm); BOOL KRegion::GetRegionDataCHRGN hRgn) { ResetO; mjiRegionSize = : :GetRegionData(hRgn. 0, NULL); if ( m_nRegionSize==0 ) return FALSE; m_pRegion = (RGNDATA *) new char[mjiRegionSize]; if ( m_pRegion==NULL ) return FALSE; ::GetRegi onData(hRgn, mjiRegi onSi ze, m_pRegi on); mjiRectCount = m_pRegion->rdh.nCount; m_pRect = (RECT *) & m_pRegion->Buffer; return TRUE; HRGN KRegion::CreateRegion(XFORM * pXForm) { return ExtCreateRegion(pXForm, mjiRegionSize. m_pRegion); } Функции GetRegi onData и ExtCreateRegi on также позволяют приложениям самостоятельно строить и преобразовывать структуры RGNDATA и передавать их GDI для создания регионов. Такая возможность может пригодиться для реализации поворотов или сдвигов в системе, не входящей в семейство NT, или для преодоления нежелательных затрат 0(п2) при объединении п регионов функцией CombineRgn. Прорисовка регионов В GDI предусмотрено несколько функций для прорисовки области, занимаемой регионом с заданным манипулятором: BOOL FilIRgnCHDC hDC, HRGN hrgn, HBRUSH hbr); BOOL PaintRgn(HDC hDC, HRGN hrgn); BOOL FrameRgn(HDC hDC, HRGN hrgn. HBRUSH hbr, int nWidth, int nHeight); BOOL InvertRgn(HDC hDC. HRGN hrgn); Все эти функции получают манипулятор контекста устройства и манипулятор региона. Координаты региона задаются в логической системе координат,
522 Глава 9. Замкнутые области а не в системе координат устройства, как координаты регионов отсечения. Следовательно, этим функциям нельзя непосредственно передать манипулятор региона, возвращаемый функцией PathToRegion (разве что логические координаты идентичны координатам устройства или же вы действуете сознательно). Графический механизм преобразует объект региона в координаты устройства с исключением правой и нижней сторон. Функция FillRgn закрашивает регион кистью, определяемой параметром hbr. Функция PaintRgn делает то же самое, но задействует текущую кисть контекста устройства. В GDI для этих двух функций используется одна и та же реализация. Функция FrameRgn обводит контур региона кистью, ширина и высота которой определяются при вызове функции. Это позволяет создавать контуры переменной толщины; при использовании обычного пера, которое всегда рисует линии постоянной толщины, это невозможно. Функция FrameRgn интерпретирует свое «перо» как прямоугольник, параллельный осям, причем весь вывод осуществляется только внутри региона и никогда не выходит за его пределы. Функция InvertRgn инвертирует пикселы кадрового буфера устройства так же, как при использовании растровой операции R2N0T. По принципу работы она напоминает функцию InvertRect. Первые три функции, FillRgn, PaintRgn и FrameRgn, используют текущую бинарную растровую операцию и учитывают действующий режим заполнения фона. Функция InvertRgn инвертирует весь регион операцией R2_N0T. На рис. 9.18 показано, как перечисленные функции трансформируют закругленный прямоугольник, нарисованный функцией RoundRect. PaintRgn FrameRgn(1,1) FrameRgn(10,1) InvertRgn RoundRect FillRgn FrameRgnfUO) FrameRgn(10,10) Рис. 9.18. Функции PaintRgn, FillRgn, FrameRgn и InvertRgn На первый взгляд функции регионов принципиально не отличаются от других функций GDI, однако создание объектов регионов и операции с ними связаны со значительными затратам времени и памяти, особенно при усложнении формы региона. Если форму региона можно легко воспроизвести другими средствами GDI (функциями рисования прямоугольников, эллипсов, закругленных прямоугольников и траекторий), предпочтение следует отдать этому способу. Функции прорисовки регионов следует использовать для замены более дорогостоящих операций — например, функций вывода отдельных пикселов или заливок. Допустим, приложение рисует на экране два перекрывающихся круга и хочет закрасить общую область некоторой кистью. В современных реализациях GDI получить определения двух дуг, ограничивающих эту область, не так просто, зато средствами GDI можно легко вычислить пересечение двух круговых регионов.
Градиентные заливки 523 Градиентные заливки До недавнего времени средства GDI позволяли закрасить замкнутую область одноцветной однородной кистью, двуцветной штриховой кистью или узорной кистью, количество цветов в которой определялось количеством цветов в растре. Но с распространением видеоадаптеров и принтеров, обладающих повышенной цветовой глубиной, приложения начали использовать большее количество цветов, чтобы изображение выглядело более привлекательно. Одной из разновидностей цветовых эффектов являются градиентные заливки — заполнение области многочисленными цветами, сгенерированными по определенному правилу. Поддержка градиентных заливок впервые была реализована в профессиональных приложениях (таких, как Photoshop, CorelDraw и Microsoft Office). Начиная с Windows 98 и Windows 2000, градиентные заливки стали частью GDI. В Win32 GDI поддержка градиентных заливок обеспечивается одной функцией, работа которой определяется тремя новыми структурами данных. typedef struct _TRIVERTEX { LONG x; LONG y; C0L0R16 Red; C0L0R16 Green; C0L0R16 Blue; C0L0R16 Alpha; } TRIVERTEX. * PTRIVERTEX, * LPTRIVERTEX; typedef struct _GRADIENT_TRIANGLE { ULONG Vertexl; ULONG Vertex2; ULONG Vertex3; } GRADIENTJRIANGLE. *PGRADIENTJRIANGLE. *LPGRADIENTJRIANGLE: typedef struct _GRADIENT_RECT { ULONG UpperLeft; ULONG LowerRight; } GRADIENT_RECT. *PGRADIENT_RECT. *LPGRADIENT_RECT; BOOL GradientFilKHDC hDC. CONST PTRIVERTEX pVertex. DWORD dwNumVertex. CONST PVOID pMesh, DWORD dwNumMesh. DWORD dwMode); Функция GradientFm обладает рядом отличительных особенностей. Во-первых, перед типами указателей отсутствуют префиксы long и far, унаследованные от Win 16. Во-вторых, к традиционному 3-канальному формату RGB добавился новый альфа-канал. В-третьих, 8-разрядных цветовых каналов оказывается недостаточно, поэтому используются 16-разрядные каналы. Все это наглядно свидетельствует о постепенном совершенствовании API. Функция GradientFill заполняет один или несколько прямоугольников (или треугольников — в зависимости от последнего параметра dwMode). В настоящий момент параметр dwMode может принимать три допустимых значения, перечисленных в табл. 9.2.
524 Глава 9. Замкнутые области Таблица 9.2. Режимы функции GradientFill Значение параметра dwMode Смысл GRADIENTFILLRECTH Прямоугольник заполняется цветами, изменяющимися слева направо. По вертикали цвет остается постоянным GRAD I ENTF ILLRECTV Прямоугольник заполняется цветами, изменяющимися сверху вниз. По горизонтали цвет остается постоянным GRAD I ENTF ILLRECTTRI ANGLE Треугольник заполняется цветами, интерполированными по трем вершинам Отдельный прямоугольник или треугольник называется «ячейкой» (mesh) — этот жаргонный термин пришел из программирования компьютерных игр. Количество ячеек передается в параметре dwNumMesh; указатель pMesh ссылается на массив структур (либо GRADIENT_RECT, либо GRADIENTJRIANGLE). Структура GRADIENT_ RECT содержит индексы левого верхнего и правого нижнего угла прямоугольника. Структура GRADIENTTRI ANGLE содержит индексы трех вершин треугольника. Индексы относятся к массиву TRIVERTEX, на который ссылается параметр pVertex. Параметр dwNumVertex определяет количество элементов в массиве TRIVERTEX. Итак, для вершины каждого прямоугольника или треугольника существует структура TRIVERTEX, определяющая ее позицию и цвет. Позиция задается в логической системе координат с использованием 32-разрядных значений. Их цвет определяется четырьмя 16-разрядными каналами (красный, зеленый, синий и альфа-канал). Для горизонтальной градиентной заливки прямоугольника, если левый верхний угол имеет координаты (хО,уО), а правый нижний — (х1,у1), цвет точки (х,у) вычисляется по формуле: С(х.у) - ( C(xl.yl) * (х-хО) + С(хО.уО) * (xl-x) ) / (xl-xO) Здесь С(х,у) означает интенсивность одного из цветовых каналов в точке (х,у). При вертикальной градиентной заливке прямоугольников используется аналогичная формула, зависящая от координаты у: С(х.у) - ( C(xl.yl) * (у-уО) + С(хО.уО) * (yl-y) ) / (yl-yO) С градиентными заливками треугольников дело обстоит несколько сложнее. Если три вершины имеют координаты (хО,уО), (х1,у1) и (х2,у2)> то из внутренней точки (х,у) можно провести три отрезка, разделяющие треугольник на три меньших треугольника. Если ai — площадь треугольника, противолежащего по отношению к точке (xi,yi), цвет в точке (х,у) вычисляется по формуле: С(х.у) - ( С(хО.уО) * аО + C(xl.yl) * al + C(x2.y2) * д2 ) / (аО + al + a2) Для прямоугольников формула интерполяции зависит от расстояния, поэтому вполне естественно, что формула интерполяции для треугольников зависит от площади. Для прямоугольников цвет образует прямую линию на плоскости, образованной одной из осей и каждым цветовым каналом. При градиентной заливке треугольника цвет образует плоскость в трехмерном пространстве, образованном осями х, у и каждым цветовым каналом.
Градиентные заливки 525 Градиентная заливка прямоугольников Чтобы изучить использование функции GradientFill на конкретном примере, давайте попробуем создать разные градиентные заливки для одного прямоугольного региона. Сколько вариантов вы сможете изобрести? 14 самых распространенных комбинаций изображены на рис. 9.19. Рис. 9.19. Градиентная заливка прямоугольной области В верхних четырех заливках цвет изменяется в одном направлении — слева направо, сверху вниз или по диагонали. В следующем ряду прямоугольник делится на две части, и заполнение осуществляется от центра в противоположных направлениях. В нижнем ряду заливка распространяется из одного угла на весь прямоугольник. В двух последних примерах (справа) заливка идет от наружного контура в центр. Программный код, при помощи которого был построен этот рисунок, частично приведен в листинге 9.3. Листинг 9.3. Градиентная заливка прямоугольных областей inline C0L0R16 R16CC0L0RREF с) { return GetRValue(c)«8; } inline C0L0R16 G16CC0L0RREF с) { return GetGValue(c)«8; } inline C0L0R16 B16CC0L0RREF c) { return GetBValue(c)«8; } inline C0L0R16 R16(C0L0RREF cO. COLORREF cl) { return ((GetRValue(cO)+GetRValue(cl))/2)«8; } inline C0L0R16 G16CC0L0RREF cO, COLORREF cl) { return ((GetGValue(cO)+GetGValue(cl))/2)«8; } inline C0L0R16 B16(C0L0RREF cO. COLORREF cl) { return ((GetBValue(cO)+GetBValue(cl))/2)«8; } BOOL GradientRectangleCHDC hDC, int xO, int yO. int xl, int yl. COLORREF cO. COLORREF cl. int angle) { TRIVERTEX vert[4] = { { xO. yO. R16(c0). G16(c0). B16(c0). 0 }. { xl. yl. R16(cl). G16(cl). B16(cl). 0 }. Продолжение #
526 Глава 9. Замкнутые области Листинг 9.3. Продолжение { хО. yl. R16(c0. cl). G16(c0. cl). B16(c0. cl). О }. { xl. уО. R16(c0. cl). G16(c0. cl). B16(c0. cl). О } }: ULONG Index[] = { 0. 1. 2. 0. 1. 3}: switch ( angle % 180 ) { case 0: return GradientFilKhDC. vert. 2. Index. 1, GRADIENT_FILL_RECT_H); case 45: return GradientFilKhDC. vert. 4. Index.2. GRADIENTJILLJRIANGLE); case 90: return GradientFilKhDC. vert. 2. Index. 1. GRADIENT_FILL_RECT_V): case 135: vert[0].x = xl; vert[3].x = xO: vert[l].x = xO; vert[2].x = xl: return GradientFilKhDC. vert. 4. Index. 2. GRADIENTJILLJRIANGLE): } return FALSE: BOOL CornerGradientRectangle(HDC hDC. int xO. int yO. int xl. int yl. COLORREF cO. COLORREF cl. int corner) { TRIVERTEX vert[] = { { xO. yO. R16(cl). G16(cl). B16(cl). 0 }. { xl. yO. R16(cl). G16(cl). B16(cl). 0 }. { xl. yl. R16(cl). G16(cl). B16(cl). 0 }. { xO. yl. R16(cl). G16(cl). B16(cl). 0 } vert[corner].Red = R16(c0) vert[corner].Green = G16(c0) vert[corner].Blue = B16(c0) ULONG Index[] = { corner, (согпег+Ш4. (corner+2)X4. corner. (corner+3)U4, (corner+2U4 }: return GradientFilKhDC. vert. 4. Index. 2. GRADIENTJILLJRIANGLE): } Функция GradientRectangle рисует четыре заливки из первого ряда; в первом и третьем многоугольнике используется простая прямоугольная заливка.
Градиентные заливки 527 Второй и четвертый примеры нарисованы посредством треугольной заливки. Функция CornerGradientRectangle рисует четыре заливки в третьем ряду, во всех случаях используется комбинация двух треугольников. В приведенном фрагменте определено несколько подставляемых функций для преобразования 8-разрядных значений RGB в 16-разрядные, используемые в структуре TRI VERTEX, и вычисления усредненных цветов. Обратите внимание: в приведенном примере не задействованы структуры GRADIENTRECT и GRADIENTTRI ANGLE; вместо этого мы напрямую работаем с массивами длинных беззнаковых индексов. Применение градиентных заливок для создания объемных кнопок Комбинация нескольких градиентных заливок создает интересные эффекты. Благодаря механизму отсечения градиентные заливки можно применять и к непрямоугольным областям; например, это позволяет имитировать объемный вид кнопок. На рис. 9.20 изображены три объемные кнопки, созданные при помощи функции GradientRectangle. Рис. 9.20. Применение градиентных заливок для создания объемных кнопок Первая прямоугольная кнопка нарисована путем градиентной заливки от темного цвета к светлому и последующей закраски меньшего участка от светлого цвета к темному. В результате возникает впечатление искривленной поверхности. Следующие две кнопки созданы аналогично, но в них использовано отсечение по закругленным прямоугольникам и эллипсам. На самом деле все три кнопки отсекаются по регионам в виде закругленных прямоугольников с разной степенью закругления углов. Функция создания кнопок приведена ниже. void RoundRectButton(HDC hDC. int xO, int yO. int xl. int yl. int w, int d. COLORREF cl. COLORREF cO) { for (int i=0; i<2; i++) { POINT P[3] = { xO+d*i. yO+d*i, xl-d*i, yl-d*i. xO+d*i+w, yO+d*i+w }; LPtoDP(hDC, P. 3); HRGN hRgn = CreateRoundRectRgn(P[0].x. P[0].y,
528 Глава 9. Замкнутые области Р[1].х. Р[1].у. Р[2].х-Р[0].х. Р[2].у-Р[0].у); SelectClipRgn(hDC, hRgn): DeleteObject(hRgn); if ( i==0 ) GradientRectangle(hDC, xO. yO, xl. yl, cl. cO, 45); else GradientRectangleChDC, xO+d, yO+d, xl-d. yl-d. cO. cl, 45); } SelectClipRgnChDC. NULL); } Функция в цикле выполняет две градиентные заливки с разными размерами. Отсечение несколько усложняется тем, что для создания правильной области отсечения функция должна определять ее размеры и положение в системе координат устройства. Впрочем, эти небольшие дополнительные усилия позволяют использовать функцию в любой логической системе координат. Практическое использование заливок Заливки являются важным аспектом любых графических приложений, от простейших текстовых и графических редакторов до сложных пакетов профессиональной графики. В GDI поддерживаются три основных средства для создания заливок: О кисти и градиенты, определяющие цвет и узор заливки; О функции заливки, позволяющие непосредственно закрашивать простые геометрические фигуры; О механизм отсечения, обеспечивающий свободу выбора границ закрашиваемой области. Поддержка заливок в GDI достаточно близка к возможностям, поддерживаемым в современных графических пакетах: О одноцветные однородные заливки (включая полупрозрачные); О градиентные заливки; О текстурные заливки; О узорные заливки; О растровые заливки. Полупрозрачная заливка Одноцветные однородные заливки легко создаются при помощи однородных кистей GDI. При создании полупрозрачной заливки каждый второй пиксел закрашивается определенным цветом, а остальные пикселы приемника остаются без изменений. Для решения этой задачи можно воспользоваться шахматной узорной кистью и двумя бинарными растровыми операциями. Следующая функция создает полупрозрачную заливку в прямоугольнике.
Практическое использование заливок 529 void SemiFillRectCHOC hDC. int left, int top, int right, int bottom, COLORREF color) { int nSave = SaveDC(hDC); const unsigned short ChessBoard[] = { OxAA, 0x55, OxAA. 0x55. OxAA, 0x55, OxAA, 0x55 }; HBITMAP hBitmap = CreateBitmap(8. 8, 1, 1, ChessBoard); HBRUSH hBrush = CreatePatternBrush(hBitmap); DeleteObject(hBitmap); HGDIOBJ hOldBrush = SelectObject(hDC, hBrush); HGDIOBJ hOldPen = SelectObject(hDC, GetStockObject(NULL_PEN)); SetROP2(hDC, R2_MASKPEN); SetBkColor(hDC, RGB(0xFF, OxFF, OxFF)); // Без изменений цвета SetTextColor(hDC, RGB(0, 0, 0)); // Черный цвет Rectangle(hDC. left, top, right, bottom); SetROP2(hDC. R2_MERGEPEN); SetBkColor(hDC, RGB(0x0. 0x0. 0x0)); // Без изменений цвета SetTextColor(hDC, color); // Заданный цвет RectangleChDC. left, top, right, bottom); SelectObjectChDC. hOldBrush); SelectObjectChDC, hOldPen); DeleteObject(hBrush); RestoreDC(hDC, nSave); } Функция Semi Fill Rect создает узорную кисть с шахматным узором. При первом вызове функции Rectangle используется растровая операция R2MASKPEN, в результате чего основные пикселы окрашиваются в черный цвет (0), а фоновые пикселы остаются без изменений. При втором вызове функции Rectangl e операция R2_MERGEPEN окрашивает основные пикселы в заданный цвет, а фоновые пикселы по-прежнему остаются неизмененными. Тернарные растровые операции (см. следующую главу) позволяют обойтись всего одним вызовом функции при использовании шахматной кисти. Реализация градиентных заливок в цветовом пространстве HLS В Windows 98 и Windows 2000 на уровне GDI реализована неплохая поддержка градиентных заливок, и все же без проблем не обошлось. По имеющейся информации градиентные заливки в Windows 98 приводят к утечке ресурсов, поэтому часто пользоваться ими не рекомендуется. В Windows NT 4.0 и Windows 95 градиентные заливки на уровне GDI не поддерживаются, если не считать линейной интерполяции в пространстве RGB. По этим причинам в приложениях иногда возникает необходимость в самостоятельной реализации градиентных заливок. Заливки треугольников лучше выполняются при помощи операций с растрами, но градиентные заливки прямоугольников легко имитируются закраской проме-
530 Глава 9. Замкнутые области жуточных полос с постепенным изменением цвета. Функция HLSGradientRectangle демонстрирует создание градиентных заливок в цветовом пространстве HLS. Функция GradientFill GDI в ней не используется. void HLSGradientRectangle(HDC hDC, int xO, int yO. int xl. int yl, COLORREF crefO, COLORREF crefl. int nPart) { KColor cO(crefO); cO.ToHLSO: KColor cl(crefl): cl.ToHLSO: for (int i=0; i<nPart; i++) { KColor c; c.hue = ( cO.hue * (nPart-1-i) + cl.hue * i ) / (nPart-1); c.lightness = ( cO.lightness * (nPart-1-i) + cl.lightness * i ) / (nPart-1); c.saturation = ( cO.saturation* (nPart-1-i) + cl.saturation* i ) / (nPart-1): c.ToRGBO: HBRUSH hBrush = CreateSolidBrush(c.GetColorRefO); RECT rect = { xO+i*(xl-xO)/nPart, yO, xO+(i+l)*(xl-xO)/nPart, yl }; FillRect(hDC, & rect. hBrush); DeleteObject(hBrush); } } Преобразование цветов между пространствами RGB и HLS выполняется классом KColor. Интерполяция происходит в пространстве HLS, а не в пространстве RGB. Прямоугольник делится на заданное количество полос, закрашиваемых одноцветной кистью. Цветовое пространство HLS позволяет легко регулировать яркость цвета без изменения оттенка и насыщенности или же изменять оттенок при постоянной яркости и насыщенности. В цветовом пространстве RGB у этих операций не находится столь простого и естественного представления. Радиальные градиентные заливки В радиальных градиентных заливках цвет изменяется в зависимости от расстояния от заданной точки (как правило, от центра круга). Радиальные заливки часто применяются для имитации бликов на объемных сферических поверхностях. Хотя в GDI радиальные градиентные заливки не поддерживаются, они легко реализуются делением круга на треугольники и постепенным изменением цвета от центра к периметру многоугольника. Пример создания радиальных градиентных заливок приведен ниже. BOOL RadialGradientFilKHDC hDC, int xO. int yO. int xl. int yl, int r, COLORREF cO. COLORREF cl, int nPart) { const double PI2 « 3.1415927 * 2; TRIVERTEX * pVertex = new TRIVERTEX[nPart+l]: ULONG * pMesh = new UL0NG[(nPart+l)*3];
Практическое использование заливок 531 pVertex[0].x = xl; pVertex[0].y = yl; pVertex[0].Red = R16(c0) pVertex[0].Green = G16(c0) pVertex[0].Blue = G16(c0) pVertex[0].Alpha = 0; for (int i=0; i<nPart; i++) { pVertex[i+l].x = xO + (int) (r * cos(PI2 * i / nPart)): pVertex[i+l].y = yO + (int) (r * sin(PI2 * i / nPart)); pVertex[i+l].Red = R16(cl): pVertex[i+l].Green = G16(cl): pVertex[i+l].Blue = B16(cl): pVertex[i+l].Alpha - 0; pMesh[i*3+0] = 0; pMesh[i*3+l] - i+1: pMesh[i*3+2] = (i+1) % nPart+1: BOOL rslt - GradientFill(hDC. pVertex. nPart+1. pMesh. nPart. GRADIENT FILL TRIANGLE); delete [] pVertex; delete [] pMesh; return rslt; } Функция аппроксимирует круг многоугольником и делит его на несколько треугольников, закрашиваемых функцией GradientFill. Настоящий центр круга находится в точке (хО,уО), а точка (х1,г/1) является общей вершиной всех градиентных треугольников и имитирует различные углы зрения. На рис. 9.21 показаны примеры разбиения круга на 8, 16 и 256 треугольников. Рис. 9.21. Радиальные градиентные заливки Приведенная функция подойдет для рисования одной-двух кнопок с искривленной поверхностью, но она определенно не соответствует высокому качеству трехмерной графики, которое может быть получено средствами Direct3D или OpenGL. На периметре многоугольника используются одинаковые цвета, да и количество треугольников, вероятно, следовало бы увеличить.
532 Глава 9. Замкнутые области Текстурные и растровые заливки Текстурной заливкой (texture fill) называется заполнение области растром, изображающим текстуру конкретного материала — скажем, бумаги, мрамора, гранита, песка или дерева. Для реализации текстурных заливок можно было бы воспользоваться узорными кистями GDI, но при этом возникает пара проблем. Во-первых, в системах, не входящих в семейство NT, узорные кисти ограничиваются размерами 8x8 пикселов. Во-вторых, в GDI узоры определяются в координатах устройства и не масштабируются в соответствии с разрешением устройства. Растры 8x8 годятся разве что для очень мелких текстур, отображаемых на экране. Текстурный растр, который хорошо смотрится на экране с разрешением 96 dpi, будет практически неразличим на принтере с разрешением 1200 dpi. Например, текстура, имитирующая деревянную поверхность, сильно зависит от разрешения устройства. Под растровой заливкой (bitmap fill) понимается растяжение растра по размерам заполняемой области. Текстурные и растровые заливки связаны с растрами, подробно описанными в следующей главе, поэтому мы оставляем эту тему на будущее. Узорные заливки GDI предоставляет в распоряжение программиста несколько стандартных штриховых узоров для закраски замкнутых фигур двумя цветами. Штриховые кисти первоначально ориентировались на экранный вывод. Хотя в NT интерфейс DDI позволяет драйверам принтеров предоставлять собственные масштабированные растры для реализации штриховых кистей, эта возможность используется лишь немногими драйверами принтеров. Если приложение задействует штриховые кисти для вывода на экран, штриховой узор не масштабируется в режимах с разрешением 72, 96 или 120 dpi. При изменении масштаба изображения узор остается прежним. Если приложение задействует штриховые кисти при печати, разглядеть полученный узор удастся разве что под микроскопом. Узорные заливки довольно просто имитируются последовательностью линий, причем это дает возможность задавать переменную толщину пера и координаты в логическом координатном пространстве. Простая функция, приведенная ниже, с использованием линий строит наклонный узор в виде «кирпичной кладки». void BrickPatternFill(HDC hDC. int xO. int yO. int xl. int yl. int width, int height) { width = abs(width); height = abs(height); if ( xOxl ) { int t = xO: xO = xl; xl = t; } if ( yOyl ) { int t = yO; yO = yl; yl = t; } for (int y=yO; y<yl: у += height ) for (int x=xO; x<xl: x += width ) { MoveToEx(hDC, x. y, NULL); LineTo(hDC. x+width, y+height); MoveToEx(hDC, x+width, y, NULL);
Итоги 533 LineTo(hDC, x+width/2. y+height/2); } } Функция использует только логические координаты, поэтому построенный узор легко преобразуется. В приведенном примере не поддерживается отсечение по определяющему прямоугольнику, непрозрачная закраска фона и выравнивание базовой точки кисти. Пример вывода иллюстрирует рис. 9.22. Рис. 9.22. Смешение при рисовании однородной кистью на устройствах, использующих палитру Итоги В этой главе рассматриваются средства GDI, предназначенные для заполнения замкнутых областей — кисти, заливки, регионы и модные градиентные заливки. В отличие от перьев, обладающих собственными геометрическими размерами, кисть определяет только способ размещения цветового шаблона внутри замкнутой области. Мы достаточно подробно изучили ситуации, при которых ограниченные возможности кистей GDI не соответствуют требованиям современных приложений, разобрались в проблемах несовместимости между операционными системами и рассмотрели некоторые обходные пути, решения и общие рекомендации. Кисть, создаваемая средствами GDI, представляет собой логическую спецификацию реальной кисти, которая задействуется драйвером устройства при рисовании и обычно является аппаратно-зависимой. При первом использовании новой логической кисти графический механизм обращается к драйверу устройства с требованием реализовать логическую кисть, то есть создать физическую структуру данных на основании логической кисти. После этого реализованный объект кисти передается всем функциям драйвера, использующим кисть. Дополнительная информация о внутренней структуре данных кисти приведена при описании других объектов GDI в главе 3 (раздел «WinDbg и расширение отладчика GDI»). В GDI предусмотрено довольно много функций для рисования простых геометрических фигур (прямоугольников, закругленных прямоугольников, эллипсов и многоугольников). Контуры таких фигур обводятся пером, а внутренняя часть закрашивается кистью. Более сложные фигуры строятся с использова-
534 Глава 9. Замкнутые области нием траекторий, объединяющих разные типы кривых. На уровне DDI практически все контуры преобразуются в траектории, а большая часть вызовов заполнения замкнутых областей обрабатывается внутренней реализацией функции StrokeAndFi 11 Path. Даже многоугольники и совокупности многоугольников представляют собой траектории, состоящие только из прямых линий. Единственным исключением являются прямоугольники в совместимом графическом режиме; для них используется более простая точка входа DDL GDI относится к числу базовых интерфейсов графического программирования и поэтому не поддерживает достаточно полный набор геометрических операций. При усложнении фигур точное вычисление их контуров становится трудной, а то и вовсе невыполнимой задачей. Простейший выход заключается в использовании регионов. При помощи операций из теории множеств можно создавать новые регионы как комбинации существующих регионов и применять их для графического вывода или отсечения. С другой стороны, использование регионов требует значительных затрат памяти и процессорного времени, а при большом увеличении региона ухудшается качество изображения. В GDI существует пара специальных функций для получения данных внутреннего представления регионов и применения к ним преобразований. Это открывает немало интересных возможностей — например, применение преобразований перспективы к данным региона. В новых реализациях Win32 GDI средства API для закраски плоских фигур вышли в третье, цветовое измерение — появилась поддержка градиентных заливок. Градиентные заливки часто применяются для имитации бликов на различных поверхностях. Вероятно, в будущем они будут все чаще встречаться в приложениях. Итак, к настоящему времени мы познакомились с функциями рисования отдельных пикселов и линий/кривых, а также закраски замкнутых областей. Начиная со следующей главы, мы займемся изучением различных растров, поддерживаемых в GDI, и их постоянно расширяющейся областью применения. Пример программы К этой главе прилагается всего один пример программы Areas (табл. 9.3). Эта программа иллюстрирует все темы, рассмотренные в настоящей главе, и строит все рисунки, приведенные в тексте. Таблица 9.3. Программа главы 9 Каталог проекта Описание Samples\Chapt_09\Area Меню Test содержит больше десятка команд, иллюстрирующих смешение цветов, применение штриховых и узорных кистей, кистей системных цветов, рисования прямоугольников, эллипсов, секторов, сегментов, закругленных прямоугольников, многоугольников, наборов многоугольников, регионов и траекторий, а также градиентных заливок
Глава 10 Основные сведения о растрах Как было показано в трех последних главах, пикселы, линии и замкнутые области могут использоваться для построения финансовых диаграмм, инженерных чертежей, геометрических узоров и т. д. Геометрические объекты, входящие в изображение, описываются точными математическими формулами. Эта область программирования компьютерной графики обычно называется векторной графикой (vector graphics). В другой, не менее важной области компьютерной графики используются оцифрованные изображения, полученные из окружающего мира. Эта область называется растровой графикой (bitmap graphics). Растровое изображение представляет собой прямоугольный массив элементов (пикселов), каждый из которых имеет определенный цвет. Растровые изображения часто являются результатом обработки информации, введенной со сканера, цифрового фотоаппарата или видеокамеры. Растры — слишком обширная тема, поэтому в книге этот материал разделен на три главы. Эта глава посвящена форматам растровых изображений и их отображению на графическом устройстве. Мы рассмотрим три основных растровых формата, поддерживаемых в GDI, — DIB (Device-Independent Bitmap), DIB-сек- ции и DDB (Device-Dependent Bitmap). В следующих главах будут рассматриваться практические применения — прозрачный вывод растров, альфа-наложение на фоновый рисунок, постепенная «проявка» и исчезновение, повороты растров и т. д. Аппаратно-независимые растры При вводе оцифрованной графики с устройств данные изображения необходимо преобразовать в формат, подходящий для хранения на жестком диске компьютера или другом носителе, а также для передачи на удаленное устройство. В наши дни с форматами графических изображений возникает немало хлопот. Разные операционные системы, фирмы-разработчики аппаратуры и даже при-
536 Глава 10. Основные сведения о растрах ложения работают с графикой, хранящейся в разных форматах. К числу наиболее распространенных растровых форматов относятся следующие: О JPEG (разработчик —Joint Photographic Experts Group) — 24-разрядный цветной формат со сжатием и потерей данных; О TIFF (разработчик — Aldus ) — очень гибкий графический формат с поддержкой различных субформатов, порядка байтов MAC и PC, а также сжатия LZW; О GIF (разработчик — CompuServe) — графический формат для небольших изображений, содержащих не более 256 цветов, с поддержкой пошагового вывода и прозрачности; О PNG (www.cdrom.com/pub/png/), Portable Network Graphics — графический формат с поддержкой многочисленных экзотических возможностей; на сегодняшний день отличается от остальных форматов применением незапатентованных алгоритмов и свободным распространением исходных текстов. Традиционным графическим форматом операционной системы Microsoft Windows является формат BMP. По сравнению с другими графическими форматами это очень простой формат, который проектировался в основном для упрощения графического программирования в приложениях. Поддержка цветовой глубины в формате BMP достаточно универсальна, от 1-, 2-, 4- и 8-разрядных индексированных изображений до 16-, 24- и 32-разрядного цвета в модели RGB. Изображения в формате BMP обычно занимают очень много места, поскольку этот формат поддерживает лишь простейшую форму сжатия по алгоритму RLE в 4- и 8-разрядных индексированных форматах. Например, 24-разрядное изображение размером 1024 х 768 пикселов в формате BMP занимает 2,55 Мбайт, а в формате JPEG оно обычно сжимается примерно до 200 Кбайт. Сохранять такие большие изображения на диске или передавать их через Интернет не рекомендуется. Файловый формат BMP Растры в формате BMP обычно называются аппаратно-независимыми (Device- Independent Bitmap, DIB). Определение «аппаратно-независимый» означает, что формат содержит полную информацию об изображении и позволяет воспроизвести его на разных устройствах. Первоначально этот термин не означал, что растр кодируется в аппаратно-независимом цветовом пространстве, хотя новые версии операционных систем Microsoft включают в формат BMP данные цветовых профилей, чтобы компенсировать зависимость от цветовых устройств. Ап- паратно-независимым растрам противопоставляется другой формат изображений, используемых во внутренней работе графической системы Windows — аппарат - но-зависимые растры (Device-Dependent Bitmaps, DDB). В этом разделе мы сначала рассмотрим DIB как фундаментальный графический формат Windows, а затем перейдем к DDB и другому растровому формату — DIB-секциям. Аппаратно-независимый растр, или DIB, хранящийся в файле на диске, состоит из трех основных компонентов: заголовка растрового файла, блока описания растра и массива пикселов. Блок описания растра может дополнительно делиться на заголовок, массив масок и цветовую таблицу (в зависимости от цветовой глубины растра). На рис. 10.1 показана структура изображения формата DIB в дисковом файле.
Аппаратно-независимые растры 537 Заголовок растрового файла 1 (BITMAPFILEHEADER) 1 Bitmap Information Заголовок блока 1 с информацией о растре 1 (BITMAPCOLORHEADER, 1 BITMAPINFOHEADER, 1 BITMAPV4HEADER, 1 orBITMAPV5HEADER) 1 Битовая маска 1 (DWORD Ц) 1 Цветовая таблица 1 (RGBTRIPLE[ ], RGBQUAD [ ]) I Массив пикселов 1 (Pixel [][]) Рис. 10.1. Файловый формат BMP Заголовок растрового файла Заголовок растрового файла содержит простую информацию, по которой приложения идентифицируют BMP-файлы. Он состоит из трех основных компонентов: сигнатуры BMP-файла, поля длины файла и смещения массива пикселов. Заголовок определяется в структуре BITMAPFILEHEADER. typedef struct tagBITMAPFILEHEADER { WORD bfType; // Сигнатура BMP-файла DWORD bfSize; // Общий размер файла DWORD bfReservedl; // 0 DWORD bfReserved2; // 0 DWORD bfOffBits; // Смещение массива пикселов от начала файла } BITMAPFILEHEADER; Сигнатура bfType в BMP-файлах состоит из двух ASCII-символов, «В» и «М», поэтому файл всегда начинается со значения 0x4D42, или "М" * 256 + "В". В поле bfSize хранится общий размер графического файла (это удобно при загрузке файлов с удаленного компьютера). В последнем поле структуры хранится смещение массива пикселов от начала графического файла. Следует помнить о том, что структура BITMAPFILEHEADER изначально проектировалась для 16-разрядных версий Windows, поэтому она выравнивается по границе слов, а не двойных слов. Общий размер структуры равен 14 байтам, в результате чего заголовок блока описания растра тоже не выравнивается по границе двойного слова. Это обстоятельство может вызвать проблемы при попытке сохранения DIB-секции в растровом файле, отображаемом на память (memory- mapped).
538 Глава 10. Основные сведения о растрах Заголовок описания растра Заголовок растрового файла всего лишь сообщает приложениям, что файл содержит данные в формате BMP, а подробное описание хранится в следующем за ним информационном блоке, который также начинается с заголовка. Если заголовок растрового файла пережил несколько поколений операционных систем Windows без малейших изменений, заголовок блока описания с информацией о растре неоднократно изменялся в прошлом и продолжает изменяться. В нем содержатся сведения о формате растрового изображения, его размерах, схеме сжатия, размере цветовой таблицы, цветовых профилях и т. д. В настоящее время существует четыре разных версии этого заголовка. Самая простая из них — структура BITMAPCOREHEADER, первоначально спроектированная для операционной системы OS/2. typedef struct tagBITMAPCOREHEADER { DWORD bcSize; // sizeof(BITMAPCOREHEADER) WORD bcWidth; // ширина растра в пикселах WORD bcHeight: // высота растра в пикселах + ориентация WORD bcPlanes; // количество плоскостей, должно быть равно 1 WORD bcBitCount; // количество бит на пиксел } BITMAPCOREHEADER; Чаще всего в BMP-файлах используется заголовок в формате структуры BITMAPINFOHEADER, значительно расширенный по сравнению с OS/2-версией. typedef struct tagBITMAPCOREHEADER { DWORD bcSize; // sizeof(BITMAPCOREHEADER) WORD bcWidth; // ширина растра в пикселах WORD bcHeight; // высота растра в пикселах + ориентация WORD bcPlanes; // количество плоскостей, должно быть равно 1 WORD bcBitCount; // количество бит на пиксел DWORD biCompression: // алгоритм сжатия DWORD biSizelmage; // размер массива пикселов LONG biXPelsPerMeter; // горизонтальное разрешение LONG biYPelsPerMeter; // вертикальное разрешение DWORD biClrUsed; // общий размер цветовой таблицы DWORD bi CIrImportant; // количество цветов, необходимых для вывода } BITMAPCOREHEADER; Структура BITMAPINFOHEADER обычно называется «версией 3» описания растра. Все аспекты Win32 API, появившиеся во времена Windows 3.1, обычно относятся к «версии 3»; новые возможности, добавленные в Windows 95 и Windows NT, именуются «версией 4», а новые возможности Windows 98 и Windows 2000 относятся к «версии 5». В Windows 95 и Windows NT 4.0 появилась новая структура BITMAPV4HEADER, а в Windows 98 и Windows 2000 была добавлена структура BITMAPV5HEADER. Начало этих новых структур в точности совпадает с BITMAPINFOHEADER (если не считать того, что поле размера содержит соответственно sizeof(BITMAPV4HEADER) или sizeof(BITMAPV5HEADER)). В структуре версии 4 появились новые поля для цветовых масок RGBA, цветовых пространств, конечных точек и гамма-коррекции, что предназначалось для поддержки ICM 1.0. R структуре версии 5 добавились новые типы цветовых пространств, рекомендации по воспроизведению и данные
Аппаратно-независимые растры 539 цветового профиля, ориентированные на поддержку ICM 2.0. Подробные описания этих структур приведены в MSDN. По иронии судьбы тот факт, что графический компонент Win98 генерирует BMP-файлы с заголовком V5, считается недостатком, а не достоинством, поскольку даже Visual Basic не читает новые BMP-файлы. Однако хорошо написанное приложение должно по крайней мере учитывать возможность получения заголовков BMP-файлов в четырех разных форматах, даже если оно при этом игнорирует новые поля V4 и V5 и интерпретирует заголовок как структуру BITMAPINFOHEADER. В структурах заголовка первое поле определяет размер структуры и является единственным признаком, по которому можно определить, какая версия заголовка используется. Если поле равно sizeof (BITMAPCOREHEADER), приложение должно работать с DIB в формате OS/2. Поле размера также определяет смещение, по которому находится цветовая таблица DIB. В двух следующих полях хранится ширина и высота DIB в пикселах. Обратите внимание: в DIB формата OS/2 эти значения хранятся в виде 16-разрядных слов (WORD), тогда как в новых версиях используется 32-разрядный тип LONG. Высота DIB обычно является положительной величиной, но она может быть и отрицательной. Знак определяет порядок следования строк развертки в массиве пикселов. Положительная высота DIB соответствует обратному порядку строк (снизу вверх), при котором первый пиксел массива является первым пикселом последней строки развертки изображения; такие DIB-растры называются перевернутыми (bottom-up). Отрицательная высота DIB соответствует более привычному прямому порядку следования строк развертки (сверху вниз). В большинстве BMP-файлов используется обратный порядок следования строк развертки. Поля bcPlanes и bcBitCount определяют формат строк развертки массива пикселов. В двухцветных изображениях, частным случаем которых являются черно- белые изображения, для представления пиксела достаточно одного бита. В 256- цветных изображениях пиксел представляется 8 битами. В разных графических устройствах может использоваться разная структура строк развертки (с одной или несколькими цветовыми плоскостями), но формат DIB поддерживает изображения лишь с одной плоскостью, поэтому поле bcPlanes должно быть равно 1. Поле bcBitCount полностью определяет размер каждого пиксела и количество цветов, представляемых одним пикселом. Допустимые значения этого поля перечислены в табл. 10.1. Таблица 10.1. Допустимые значения поля bcBitCount в формате DIB Значение Максимальное количество Размер пик- Описание цветов села, байт 0 Зависит от внедренного изображения 1 2 (21) 1/8 Поддерживается только в Windows 98/2000; используется для внедрения изображений в формате JPEG или PNG Монохромное изображение Продолжение ^>
540 Глава 10. Основные сведения о растрах Таблица 10.1. Продолжение Значение Максимальное количество цветов Размер пик- Описание села, байт 4 8 16 24 32 4 (23) 1/4 16 (24) 1/2 256 (28) 1 32 768 (215) или 65 536 (216) 2 166 777 216 (224) 3 166 777 216 (224) 4 4-цветное изображение, используемое в WinCE 16-цветное изображение 256-цветное изображение High Color True Color True Color Если количество бит на пиксел меньше либо равно 8, после заголовка в ВМР- файле следует цветовая таблица. Используемая в OS/2 структура BITMAPCOREHEADER заканчивается полем bcBitCount, а в других структурах присутствуют дополнительные поля. Базовый формат DIB следует интерпретировать в приложении таким образом, чтобы отсутствующим полям присваивались значения по умолчанию. В поле biCompression хранится информация об алгоритме сжатия, применяемом к массиву пикселов. Допустимые значения перечислены в табл. 10.2. Таблица 10.2. Алгоритмы сжатия DIB Значение Описание BIRGB Несжатое изображение BIRLE8 Изображение с кодировкой 8 бит/пиксел, сжатое с использованием алгоритма RLE. Только для перевернутых DIB-растров BIRLE4 Изображение с кодировкой 4 бит/пиксел, сжатое с использованием алгоритма RLE. Только для перевернутых DIB-растров BIBITFIELDS Несжатые изображения с кодировкой 16 и 32 бит/пиксел. В изображение включаются три битовые маски, определяющие способ хранения компонентов RGB BIJPEG Массив пикселов содержит внедренное изображение в формате JPEG. Поддерживается только в Windows 98/2000 BIPNG Массив пикселов содержит внедренное изображение в формате PNG. Поддерживается только в Windows 98/2000 Чаще всего поле biCompression равно BIRGB (сжатие отсутствует). Visual Studio и графические редакторы от Microsoft генерируют BMP-файлы только в несжатом формате. При отсутствии сжатия каждая строка развертки DIB представляет собой упакованный массив пикселов. Пиксел с 1-битной кодировкой занимает 1/8 байта, пиксел с 2-битной кодировкой занимает 1/4 байта, а пикселы
Аппаратно-независимые растры 541 с 4-битной кодировкой занимают 1/2 байта. В этих трех случаях один байт может содержать данные нескольких пикселов, от старшего бита к младшему. Для изображений с большим количеством бит/пиксел каждый пиксел занимает biBitCount/8 байт. Строки развертки в аппаратно-независимых растрах всегда выравниваются по ближайшей границе двойного слова (при необходимости строка дополняется нулями). В DIB с кодировкой 4 и 8 бит/пиксел для уменьшения размеров растра может применяться необязательное сжатие но алгоритму RLE (Run-Length Encoding). Для 8-битных изображений этот алгоритм ищет последовательность смежных байтов с одинаковым значением и заменяет их двумя байтами: счетчиком повторений и кодом повторяющегося байта. Предусмотрены особые служебные последовательности для неповторяющихся байтов, конца строки и конца изображения. Алгоритм RLE обеспечивает наилучший результат в том случае, если каждая строка развертки состоит из одинаковых пикселов. В худшем случае результат занимает больше места, чем исходное несжатое изображение. Ниже приведено описание формата сжатого изображения с применением метода BIRLE8: <изображение> :: = <серия_пикселов> { <серия_пикселов> } <серия_пикселов> ::= <кодированные_данные> | <непосредственные_данные<@062> <кодированные_данные> ::= <конец_строки> | <конец_изображения> | <дельта> | <повторение> <конец_строки> : := О О <конец_изображения> ::= 0 1 <дельта> ::= 0 2 dx dy <непосредственные__данные> ::= 0 счетчик { байт } <повторение> ::= счетчик_повторений повторяемый_байт Сжатое изображение в формате RLE кодируется в виде последовательности серий пикселов, существующих в пяти формах. Если первый байт серии пикселов отличен от нуля, он является счетчиком повторений (от 1 до 255) и указывает, сколько раз повторяется следующий байт. Если первый байт равен нулю, следующий байт либо должен быть равен 0 (конец строки), 1 (конец изображения), 2 (дельта) или 3-255 (несжатые пикселы). Дельта-серия смещает текущую позицию в декодировашюм изображении с заданными смещениями по осям х и у, что позволяет быстро преодолеть несколько строк развертки. Признаки конца строки pi конца изображения также позволяют преждевременно обрывать строки развертки или изображения, однако значения пропущенных пикселов считаются неопределенными. Таким образом, на практике дельта-серии практически не встречаются; признаки конца строки и конца изображершя обычно размещаются за последним пикселом строки или всего изображенрря. Другими словами, каждая строка развертки обычно кодируется отдельно от остальных без пропуска пикселов, что позволяет 1рзбежать неопределенных значений пикселов. Непосредствершые серии описывают последовательности неповторяющихся пикселов в изображении. Серия начинается с 0 и счетчржа, принимающего значенрш из интервала 3-255, поскольку значершя 0-2 зарезервированы для признаков конца строки, корща ркзображения pi дельта-серий. За счетчиком следует точное колршество байт. Каждая непосредственная серрш должна состоять из четного количества байт, поэтому счетчрш должен быть четным. Это гарантирует, что каждая серрш пикселов в закодированном изображении всегда вырав-
542 Глава 10. Основные сведения о растрах нивается по границе слова, что заметно упрощает процессы кодирования/восстановления информации и повышает их эффективность. Если в изображении в кодировке RLE пикселы не пропускаются, его синтаксис представляется в следующем упрощенном виде: <изображение> :: = <строка_развертки> { <строка_развертки> } [ <конец_изображения<@062> ] <строка_развертки> ::= <серия_пикселов> { <серия_пикселов> } [ <конец_строки> ] <серия_пикселов> ::= <счетчик_повторений> | <непосредственная_серия> Четырехбитные изображения в кодировке BIRLE4 имеют такую же базовую структуру, как и изображения в формате BIRLE8. Однако в этом случае каждый пиксел представляется только 4 битами. Счетчик непосредственных данных содержит количество пикселов, поэтому следующие за ним данные должны состоять из значений (счетчик+1)/2 байт. Счетчик повторений тоже содержит количество пикселов; следующий за ним байт содержит два пиксела, которые используются попеременно для заполнения заданного количества пикселов. Для 16- и 32-разрядных DIB-растров поле biCompression должно быть равно BIBITFIELDS. Это значение не соответствует реально существующему методу сжатия; оно всего лишь позволяет задать размер и порядок следования красной, зеленой и синей составляющих в пикселе. Если поле bi Compression содержит BIFIELDS, после заголовка блока описания растра и перед цветовой таблицей добавляются три двойных слова — маски для извлечения красной, зеленой и синей составляющих из 16- или 32-разрядных упакованных пикселов. На первый взгляд кажется, что маски обладают чрезвычайной гибкостью и позволяют создавать всевозможные экзотические форматы DIB, но в действительности они должны подчиняться целому ряду ограничений. В системах семейства NT маски должны состоять из смежных пикселов и не должны перекрываться. Впрочем, вы все же можете создать DIB с нестандартным порядком каналов RGB. В системах, не входящих в семейство NT, поддерживается всего три разновидности масок. Для 16-разрядных изображений поддерживаются только форматы RGB 5-5-5 и 5-6-5. В формате 5-5-5 синяя маска равна OxlF, зеленая маска равна ОхЗЕО, а красная маска равна 0х7С00, и каждый канал занимает 5 бит. В формате 5-6-5 синяя маска равна OxlF, зеленая маска равна 0х7Е0, а красная маска равна 0xF800; из этих трех каналов только зеленый канал занимает 6 бит. Для 32-разрядных изображений поддерживается только формат 8-8-8, при этом синяя маска равна OxFF, зеленая маска равна OxFFOO, а красная маска равна OxFFOOOO. На самом деле битовые маски разрабатывались для решения проблем совместимости, связанных с различиями в реализациях режимов High Color. В «PC 99 System Design Guide» говорится, что видеоадаптер должен поддерживать 16-разрядный кадровый буфер в формате 5-5-5 или 5-6-5 или же оба формата одновременно. Если поддерживается только формат 5-5-5, видеоадаптер должен сообщать о нем как о 16-разрядном, а не 15-разрядном, поскольку в противном случае это может нарушить работу некоторых приложений. Для 32-разрядного кадрового буфера обязательна поддержка формата 8-8-8-8, где старшие 8 бит содержат данные альфа-канала. Как ни странно, альфа-канал не документируется для блока описания растра.
Аппаратно-независимые растры 543 При виде типов BIJPEG и BI_PNG создается впечатление, что GDI наконец-то пытается решить проблему больших несжатых DIB-растров в форматах High Color и True Color, однако предлагаемое решение — не более чем полумера. Эти два режима сжатия поддерживаются только в Windows 98 и Windows 2000 и с определенными ограничениями. GDI и базовый графический механизм не обеспечивают никакой поддержки декодирования изображений в форматах JPEG и PNG. Эта поддержка не обеспечивается и видеодрайверами; только драйверы принтеров по желанию могут реализовать ее. Чтобы проверить факт поддержки JPEG или PNG, приложение должно обратиться с запросом к контексту устройства принтера при помощи функции ExtEscape; только после получения положительного ответа приложение может передать драйверу устройства сжатый растр JPEG или PNG, «завернутый» в DIB. В этом случае GDI просто передает данные драйверу принтера. Это лишь отчасти решает проблему с огромными затратами памяти на хранение больших DIB-растров в форматах High Color или True Color. Тип BIJPEG рассматривается в главе 17. Давайте вернемся к структурам заголовка блока описания растра. За признаком сжатия следует поле biSizelmage, в котором хранится размер массива пикселов изображения. При использовании значения BIRGB поле biSizelmage может быть равно 0; GDI вычисляет размер изображения по ширине, высоте и количеству бит на пиксел. Но при сжатии RLE, JPEG или PNG это поле должно содержать фактический размер данных изображения. Два последних поля структуры ВITMAPINF0HEADER содержат информацию о цветовой таблице. В поле biClrllsed хранится количество элементов в цветовой таблице. Для DIB с количеством цветов, не превышающим 256, нулевое значение поля biClrUsed означает максимально возможное количество, то есть 2А(бит/пик- сел). Дисковый файл DIB должен содержать полную цветовую таблицу с максимальным количеством элементов. Неполная цветовая таблица может использоваться только в DIB-растрах, хранящихся в памяти. Поле biClrlmportant определяет количество элементов, реально необходимых для отображения растра. Как и прежде, нулевое значение означает, что значимыми являются все цвета в таблице. Каждый элемент цветовой таблицы обычно занимает 4 байта (кроме старого формата OS/2), что в общей сложности дает 1024 байта для DIB с кодировкой 8 бит/пиксел. Конечно, в мире Winl6 с 64-килобайтной кучей GDI такие затраты памяти приходилось оптимизировать. В программировании Win32 на 1024 байта никто не обращает внимания, если только ваша программа не работает с сотнями или тысячами изображений. Поле biClrlmportant всего лишь сообщает прикладной программе, сколько цветов реально используется в изображении. На основании этой информации программа может сгенерировать палитру в точности необходимого размера для вывода изображения в кадровом буфере. Для цветных DIB-растров в форматах High Color или True Color цветовая таблица не нужна, поскольку каждый пиксел содержит полную информацию обо всех цветовых составляющих RGB. С другой стороны, эти растры могут содержать ненулевые поля biClrUsed и biClrlmportant и цветовую таблицу. Цветовая таблица в изображениях High Color и True Color может использоваться для построения палитры для вывода DIB на устройствах с поддержкой палитры. Палитры рассматриваются в главе 13.
544 Глава 10. Основные сведения о растрах Битовые маски Если в 16- или 32-разрядном DIB-растре поле bi Compression равно BIBITFIELDS, за заголовком блока описания растра следуют битовые маски, хранящиеся в виде массива DWORD. Всегда используются три маски в традиционном порядке «красный — зеленый — синий». В GDI отсутствуют какие-либо структуры данных или функции API для работы с битовыми масками. Цветовая таблица В DIB-растрах, содержащих не более 256 цветов, каждый пиксел массива содержит индекс цветовой таблицы, по которой индексы преобразуются в значения RGB. DIB-растры в форматах True Color и High Color тоже могут содержать цветовые таблицы для построения логических палитр в системах, использующих палитру. Количество элементов в цветовой таблице задается в поле biClrUsed заголовка блока описания растра. Если это поле равно 0 (а также в DIB формата OS/2), предполагается максимальное количество элементов. Элементы цветовой таблицы делятся на три типа. В DIB формата OS/2 каждый элемент представляется структурой RGBTRIPLE, а в других форматах DIB — структурой RGBQUAD. Для DIB, хранящихся в памяти, каждый элемент может быть 16-разрядным словом, которое представляет собой индекс следующего уровня. И в RGBTRIPLE и в RGBQUAD цвет задается 8-разрядными значениями RGB. Как видно из приведенных ниже определений, эти структуры отличаются только наличием зарезервированного поля. typedef struct tagRGBTRIPLE { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; } RGBTRIPLE; typedef struct tagRGBQUAD { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; BYTE rgbtReserved; } RGBQUAD; GDI определяет две дополнительные структуры ВITMAPCOREINF0 и BITMAPINFO, в которых заголовок блока описания растра объединяется с цветовой таблицей. typedef struct tagCOREINFO { BITMAPCOREHEADER bmciHeader; RGBTRIPLE bmciColorsCl]; } BITMAPCOREINFO; typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[l]; } BITMAPINFO; При использовании этих структур необходима осторожность, поскольку в обеих структурах резервируется место лишь для одного элемента цветовой таблицы.
Аппаратно-независимые растры 545 Следовательно, для хранения заголовка описания растра и цветовой таблицы приложение должно выделить дополнительную память за пределами этих структур. Поле bmiHeader структуры BITMAPINFO может относиться к типу BITMAPINFOHEADER, BITMAPV4HEADER или BITMAPV5HEADER, поэтому смещение поля bmi Colors не является фиксированной величиной. Даже если вы ограничиваетесь структурой BITMAPINFOHEADER, место для битовых масок в 16- и 32-разрядных DIB-растрах не резервируется. При поиске цветовой таблицы растра приложение не должно полагаться на содержимое структуры BITMAPINFO. Вместо этого смещение цветовой таблицы следует вычислять во время работы программы на основании данных из заголовка блока описания растра. Массив пикселов Пикселы изображения хранятся в массиве пикселов. Обычно изображение представляет собой последовательность строк развертки, дополненных до ближайшей 32-разрядной границы. По умолчанию строки развертки хранятся в обратном порядке, если только поле biHeight заголовка описания не является отрицательной величиной. Обратный порядок следования строк развертки означает, что первый пиксел массива в действительности соответствует первому пикселу последней строки развертки при выводе на экран в режиме ММ_ТЕХТ. Внутри строк развертки пикселы упаковываются для экономии места. Строки дополняются битами до границы двойного слова. Количество байт на строку развертки, одна из важных характеристик DIB, вычисляется следующей функцией: int inline Scan"! ineSize( int width, int bitcount) { return (width * bitcount + 31)/32; } Для DIB с режимом сжатия BI_RGB обращение к отдельным пикселам массива является простой операцией, которая реализуется достаточно эффективно. Прямой доступ к пикселам играет важную роль при реализации графических алгоритмов и при усовершенствовании средств вывода растров, поддерживаемых в GDI. Кроме того, эта методика чрезвычайно важна в программировании DirectDraw, где графическая поверхность фактически представляет собой DIB. Подробности будут рассмотрены ниже. Упакованный аппаратно-независимый растр Файловый формат BMP предназначен для хранения DIB-растров в виде файлов на диске. Как упоминалось выше, BMP-файл состоит из заголовка файла, блока описания растра и массива пикселов. Заголовок файла содержит информацию, используемую при загрузке DIB в память. Но после того, как файл окажется в памяти, необходимость в заголовке отпадает. Если требуется, заголовок файла можно восстановить по заголовку блока описания растра. DIB без заголовка файла называется упакованным (packed) DIB-растром. Термин «упакованный» в данном случае не имеет никакого отношения к упаковке пикселов в строке развертки. Он лишь указывает на то, что остальные компоненты DIB следуют друг за другом в смежных блоках памяти.
546 Глава 10. Основные сведения о растрах Упакованный DIB-растр начинается с заголовка блока описания растра, за которым следуют массив масок, цветовая таблица и массив пикселов. В качестве указателя на упакованный DIB-растр в Win32 API обычно используется указатель на структуру BITMAPINFO. Хотя эта структура не содержит ссылок на массивы масок и пикселов, из нее по крайней мере можно узнать о наличии цветовой таблицы. Достаточно большое количество функций API получает и возвращает упакованные DIB-растры. Если DIB входит в исполняемый файл в виде ресурса, для получения указателя на упакованный DIB-растр можно воспользоваться функциями FindResource, LoadResource и LockResource. Функция CreateDIBPatternBrushPt использует упакованный DIB-растр для создания узорной кисти. Кроме того, упакованные DIB-растры используются и в работе буфера обмена Windows. В упакованном DIB-растре, хранящемся в памяти, цветовая таблица может содержать индексы логической палитры. Например, если параметр i Usage функции CreateDIBPatternBrushPt равен DIBPALC0L0RS, цветовая таблица является массивом индексов. Однако такой DIB-растр не следует передавать другим приложениям или записывать на диск, если только другая сторона не осведомлена об этом факте. В файловом формате DIB не существует флага, который бы сообщал, что цветовая таблица содержит индексы неизвестной палитры. Разделенный аппаратно-независимый растр Содержимое упакованного DIB-растра можно разделить на две части: массив пикселов и информация о формате растра (заголовок блока описания растра, маски и цветовая таблица). Хранить эти две части вместе неудобно. Например, графический редактор для поддержки многоуровневой отмены операций может хранить несколько промежуточных DIB-растров; все они содержат абсолютно одинаковую форматную информацию и отличаются только массивом пикселов. Встречаются и другие ситуации — например, приложение может получать изображение в другом формате (PCX, TIFF или GIF), создавать структуру BITMAPINFO в памяти, строить массив пикселов по восстановленным данными и затем пытаться передавать эти два блока в виде DIB. Многие графические функции GDI обладают достаточной гибкостью и не требуют обязательной передачи упакованного DIB-растра. Вместо этого функции передаются два параметра — указатель на структуру BITMAPINFO и указатель на массив пикселов. Подобное решение обеспечивает необходимую гибкость при построении DIB в памяти. Иногда разделенный аппаратно-независимый растр (неупакованный DIB- растр) для экономии места содержит неполную цветовую таблицу. Например, при использовании DIB с 64 оттенками серого цвета можно выделить память для 64 элементов цветовой таблицы вместо 256. Класс для работы с DIB Хотя BMP считается одним из самых простых графических форматов, приведенное в предыдущем разделе описание не выглядит простым. Сложность
Класс для работы с DIB 547 BMP-файлов обусловлена постоянным развитием формата для поддержки новых возможностей и постоянными поисками компромисса между быстродействием и затратами памяти. Графическое программирование аппаратно-независимых растров — задача не из простых, а поддержка операций с растрами в GDI API весьма ограничена. Например, в GDI не существует функций, которые бы возвращали количество цветов в цветовой таблице упакованного DIB-растра или указатель на массив пикселов в упакованном DIB-растре. Программистам приходится самостоятельно писать код для анализа различных версий структур и получения нужной информации. На уровне GDI отсутствует поддержка и более сложных задач — например, вычисления адреса пиксела с координатами (х,у) в массиве пикселов или преобразования растра в оттенки серого. Операции с DIB хорошо инкапсулируются в классе C++, но даже библиотека Microsoft Foundation Classes не содержит специализированного класса для работы с DIB. В этом разделе мы начнем построение нетривиального класса, предназначенного для этого. Ниже перечислены основные цели проектирования. О Загрузка и отображение DIB во всех допустимых форматах DIB. Входные изображения могут поступать из разных источников, поэтому класс должен обеспечивать загрузку и отображение во всех форматах. О Эффективность работы с различными данными DIB. Большая часть информации DIB хранится в заголовке блока описания растра, который существует в четырех разных версиях с разными значениями по умолчанию. Хорошо спроектированный класс для работы с DIB должен как можно быстрее возвращать нужную информацию без многочисленных проверок. О Прямой доступ к пикселам в несжатом массиве пикселов — ключ к реализации многих графических алгоритмов. Короче говоря, мы хотим создать класс DIB, который загружает и отображает DIB во всех возможных форматах, а также обеспечивает эффективную работу с несжатыми изображениями в формате True Color. Объявление класса KDIB приведено в листинге 10.1. Листинг 10.1. Объявление класса KDIB typedef enum i DIB 1BPP. DIB 2BPP, DIB 4BPP, DIBJBPPRLE, DIB 8BPP. DIBJBPPRLE. DIBJ6RGB555. DIB 16RGB565. DIB 24RGB888, DIB 32RGB888. // // // // // // // // // // // // // // 2-цветное изображение с палитрой 4-цветное изображение с палитрой 16-цветное изображение с палитрой 16-цветное изображение с палитрой, сжатие RLE 256-цветное изображение с палитрой 2-цветное изображение с палитрой, сжатие RLE 15-разрядное цветное изображение RGB. 5-5-5, 1 бит не используется 16-разрядное цветное изображение RGB, 5-6-5 24-разрядное цветное изображение RGB. 8-8-8 32-разрядное цветное изображение RGB, 8-8-8. 8 бит не используются Продолжение &
548 Глава 10. Основные сведения о растрах Листинг 10.1. Продолжение DIB_32RGBA8888. // 32-разрядное цветное изображение RGBA. DIB 16RGBbitfields. DIB 32RGBbitfields. DIB_JPEG. DIB_PNG DIBFormat: // 16-разрядное цветное изображение RGB. // нестандартные маски, только в NT // 32-разрядное цветное изображение RGB. // нестандартные маски, только в NT // внедренное изображение в формате JPEG // внедренное изображение в формате PNG typedef enum { DIB_BMI_NEEDFREE = 1. DIB_BMI_READONLY = 2. DIB_BITS_NEEDFREE = 4. DIB BITS READONLY = 8 class KDIB { public: DIBFormat int BITMAPINFO BYTE m_nImageFormat; m_Flags; m_pBMI; m_pBits: // формат массива пикселов // DIB_BMI_NEEDFREE ' // BITMAPINFOHEADER + маска // цветовая таблица // массив пикселов RGBTRIPLE * m_pRGBTRIPLE; // цветовая таблица DIB OS/2 в m_pBMI RGBQUAD * m_pRGBQUAD: // цветовая таблица DIB V3.4.5 в m_pBMI int mjiClrUsed; // количество цветов в таблице int mjnClrlmpt: // количество используемых цветов DWORD * m_pBitFields; // маски для 16 и 32 бит/пиксел // в m_pBMI int m_nWidth; // ширина изображения в пикселах int mjnHeight; // высота изображения в пикселах // (положительная) int mjiPlanes: // количество плоскостей int m_nBitCount; // бит на плоскость int mjnColorDepth; // цветовая глубина int m_nImageSize; // размер массива пикселов int m nBPS; BYTE * int KDIBO; virtual m_pOrigin m_nDelta; -KDIBO: // Заранее вычисляемые значения: // размер строки развертки в байтах // (на каждую плоскость) // указатель на логическое начало растра // смещение следующей строки развертки // конструктор по умолчанию. // пустое изображение // виртуальный деструктор создает
Класс для работы с DIB 549 BOOL Creatednt width, int height, int bitcount); bool AttachDIB(BITMAPINFO * pDIB, BYTE * pBits. int flags); bool LoadFile(const TCHAR * pFileName); bool LoadBitmap(HMODULE hModlue. LPCTSTR pBitmapName); void ReleaseDIB(void): // освобождение памяти int GetWidth(void) const { return mjiWidth; } int GetHeight(void) const { return mjiHeight; } int GetDepth(void) const { return mjiColorDepth; } BITMAPINFO * GetBMI(void) const { return m_pBMI; } BYTE * GetBits(void) const { return m_pBits; } int GetBPS(void) const { return m_nBPS; } bool IsCompressed(void) const { return (m_nImageFormat == DIB_4BPPRLE) || (m_nImageFormat == DIBJBPPRLE) 11 (mjnlmageFormat == DIB_JPEG) || (mjnlmageFormat == DIB_PNG); } }: Первые четыре переменные класса KDIB содержат важнейшие сведения о растрах, по которым можно получить значения всех остальных переменных. DIB-растры существуют в разных растровых форматах, зависящих от количества бит/пиксел, признака сжатия и даже битовых масок. Наличие одного значения, однозначно определяющего растровый формат, заметно упростит реализацию графических алгоритмов. По этой причине мы и определяем перечисляемый тип DIBFormat. Из определения ясно видно, что формат BMP поддерживает 15 разновидностей растровых форматов. В Windows NT/2000 DDK используется аналогичный подход к определению растровых форматов. Например, функции EngCreateBitmap (создание поверхности, находящейся под управлением GDI) передаются такие константы, как BMF4RLE, BMF8BPP и BMF32BPP. Однако помимо структуры ВITMAPIN F0HEADER, класс KDIB содержит множество других полей. Экономия десятка-другого байтов в данном случае несущественна; быстродействие гораздо важнее. Экземпляры класса KDIB будут находиться в памяти компьютера, поэтому они представляют DIB-растр, хранящийся в памяти, а не на диске; следовательно, структура BITMAPFILEHEADER не понадобится. Переменная mpBMI содержит указатель на блок описания растра. В переменной mpBits хранится указатель на массив пикселов растра. Раздельное хранение указателей на блок описания растра и массив пикселов позволяет классу KDIB поддерживать как упакованные, так и неупакованные растры. Растры поступают из разных источников — это загрузка из файла или ресурса, вставка из буфера и даже построение на программном уровне. Класс растра должен знать, доступны ли эти два указателя только для чтения, или же данные, на которые они ссылаются, должны удаляться из памяти при удалении экземпляра класса KDIB. Для этого в класс была включена переменная m_Flags, значение которой представляет собой комбинацию четырех флагов: О DIBBMINEEDFREE — указатель m_pBMI ссылается на блок памяти, выделенный из кучи, который должен освобождаться в деструкторе;
550 Глава 10. Основные сведения о растрах О DIBBMIREADONLY — указатель mpBMI ссылается на данные, доступные только для чтения; О DIBBITSNEEDFREE — указатель mpBits ссылается на блок памяти, выделенный из кучи, который должен освобождаться в деструкторе; О DIB_BITS_READONLY — указатель mpBits ссылается на данные, доступные только для чтения. Во второй группе из пяти переменных хранятся указатели на цветовые таблицы в формате RGBTRIPLE или RGBQUAD, общее количество цветов и количество значащих цветов. Мы не поддерживаем цветовую таблицу с индексами палитры, которые не являются частью формата DIB. Только один из указателей mpRGBTRIPLE и m_pRGBQUAD может быть отличен от NULL. Переменная mpBitsFields указывает на битовые маски (если они используются). Первая часть класса KDIB содержит прямые указатели на заголовок блока описания растра, цветовую таблицу и битовые маски. Третья группа переменных класса подробно описывает формат изображения. Здесь хранится ширина и высота изображения (всегда положительная), количество плоскостей, количество бит/пиксел, цветовая глубина и размер изображения. Обратите внимание: в заголовке высота растра может быть отрицательной величиной, если растр хранится в памяти не в перевернутом виде. Из-за отрицательной высоты возникают проблемы во многих графических алгоритмах, поэтому в классе KDIB высота нормализуется, а ориентация растра в памяти отражается в одной из переменных следующей группы. Четвертая группа переменных содержит часто используемые значения, вычисленные на основании упоминавшихся выше переменных. Переменная n_nBPS содержит количество байт в строке развертки, дополненной до ближайшей границы DWORD. Переменная m_pOrigin указывает на логическое начало растра, то есть на пиксел (0,0), соответствующий первому байту массива пикселов для прямого (не перевернутого) растра. Переменная m_nDelta содержит смещение между строками развертки. Для растров с прямым порядком строк развертки переменная mjiDelta всегда положительна, в противном случае она отрицательна. По этим трем переменным всегда можно быстро вычислить адрес строки развертки, по которому легко найти адрес отдельного пиксела. Независимая переменная mjiDelta также может использоваться для хранения шага (pitch) поверхности DirectDraw, который может и не совпадать с m_nBPS. Класс KDIB содержит простой конструктор по умолчанию и виртуальный деструктор. Метод ReleaseDIB отвечает за освобождение ресурсов, выделенных для представления текущего изображения. Кроме того, мы определяем несколько функций, возвращающих геометрические характеристики изображения в виде констант. Метод AttachDIB выполняет основную работу по инициализации класса KDIB на основании данных упакованного или неупакованного DIB-растра. Метод LoadBitmap загружает ресурс BMP из модуля Win32 и инициализирует объект растра, доступного только для чтения, вызовом функции AttachDIB. Метод Load- File загружает BMP-файл с диска и инициализирует экземпляр KDIB вызовом AttachDIB. Эти три метода приведены в листинге 10.2.
Класс для работы с DIB 551 Листинг 10.2. Инициализация класса KDIB по BMP-файлу или ресурсу bool KDIB::AttachDIB(BITMAPINFO * pDIB. BYTE * pBits. int flags) { if ( IsBadReadPtr(pDIB. sizeof(BITMAPCOREHEADER)) ) return false; ReleaseDIBO; m_pBMI = pDIB; m_Flags = flags: DWORD size = * (DWORD *) pDIB; // Размер size всегда равен DWORD int compression; // Сбор информации из структур заголовка блока описания растра switch ( size ) { case sizeof(BITMAPCOREHEADER): { BITMAPCOREHEADER * pHeader - (BITMAPCOREHEADER *) pDIB; mjiWidth = pHeader->bcWidth; mjiHeight = pHeader->bcHeight; m_nPlanes = pHeader->bcPlanes; m_nBitCount - pHeader->bcBitCount; m_nImageSize= 0; compression - BI_RGB; if ( m_nBitCount <- 8 ) { mjiClrUsed - 1 « mjiBitCount; m_nClrImpt = m_nClrUsed; m_pRGBTRIPLE - (RGBTRIPLE *) ((BYTE *) m_pBMI + size); m_pBits - (BYTE *) & m_pRGBTRIPLE[m_nClrUsed]; } else m_pBits - (BYTE *) m_pBMI + size; break; } case sizeof(BITMAPINFOHEADER): case sizeof(BITMAPV4HEADER): case sizeof(BITMAPV5HEADER): { BITMAPINFOHEADER * pHeader = & m_pBMI->bmiHeader; m_nWidth = pHeader->biWidth; m_nHeight = pHeader->biHeight; m_nPlanes = pHeader->biPlanes; m_nBitCount - pHeader->biBitCount; m_nImageSize= pHeader->biSizeImage; compression = pHeader->biCompression; Продолжение &
552 Глава 10. Основные сведения о растрах Листинг 10.2. Продолжение m_nClrUsed = pHeader->biClrUsed; mjiClrlmpt = pHeader->bi CIrImportant: if ( m_nBitCount<=8 ) if ( mjiClrUsed==0 ) /7 0- полная цветовая таблица mjiClrUsed = 1 « mjiBitCount; if ( m_nClrUsed ) // Имеется цветовая таблица { if ( m_nClrImpt==0 ) // 0 - все цвета являются значимыми m_nClrlmpt = m_nClrUsed; if ( compression==BI_BITFIELDS ) { m_pBitFields = (DWORD *) ((BYTE *)pDIB+size); m_pRGBQUAD - (RGBQUAD *) ((BYTE *)pDIB+size + 3*sizeof(DWORD)); } else m_pRGBQUAD - (RGBQUAD *) ((BYTE *)pDIB+size); m_pBits = (BYTE *) & m_pRGBQUAD[m_nClrUsed]: } else { if ( compression==BI_BITFIELDS ) { m_pBitFields = (DWORD *) ((BYTE *)pDIB+size); m_pBits = (BYTE *) m_pBMI + size + 3 * sizeof(DWORD); } else m_pBits = (BYTE *) m_pBMI + size; } break; } default: return false; } if ( pBits ) m_pBits = pBits; // Вычисление основных параметров DIB mjiColorDepth = mjiPlanes * m_nBitCount; m_nBPS = (mjiWidth * m_nBitCount + 31) / 32 * 4; if (mjiHeight < 0 ) // Прямой порядок строк развертки { mjiHeight = - mjiHeight; // Перейти к положительной величине mjiDelta = m_nBPS; // Смещение вперед m_pOrigin = m_pBits; // scanO .. scanN-1 } else
Класс для работы с DIB 553 { mjiDelta = - mjiBPS: // Смещение назад m_pOrigin = m_pBits + (m_nHeight-l) * m_nBPS * mjiPlanes; // scanN-1..scanO } if ( mjiImageSize==0 ) mjiImageSize = m_nBPS * m_nPlanes * mjiHeight: // Определить формат изображения по режиму сжатия switch ( mjiBitCount ) { case 0: if ( compression==BI_JPEG ) mjiImageFormat = DIB_JPEG; else if ( compression==BI_PNG ) m_nImageFormat = DIB_PNG; else return false; case 1: mjiImageFormat = DIB_1BPP; break; case 2: mjiImageFormat - DIB_2BPP; break; case 4: if ( compression==BI_RLE4 ) mjiImageFormat = DIB_4BPPRLE; else mjiImageFormat = DIB_4BPP; break; case 8: if ( compression==BI_RLE8 ) mjiImageFormat = DIBJBPPRLE: else m_nImageFormat = DIB_8BPP: break; case 16: if ( compression==BI_BITFIELDS ) mjiImageFormat - DIB_16RGBbitfields: else m_nImageFormat = DIB_16RGB555; // См. ниже break; case 24: mjiImageFormat = DIB_24RGB888; break; case 32: if ( compression — BI_BITFIELDS ) Продолжение^
554 Глава 10. Основные сведения о растрах Листинг 10.2. Продолжение mjiImageFormat else mjiImageFormat break; default: return false; } // Разобраться с битовыми полями if ( compression==BI_BITFIELDS ) { DWORD red - m_pBitFields[0]; DWORD green = m_pBitFields[l]; DWORD blue = m_pBitFields[2]: if ( (blue—OxOOlF) && (green==0x03E0) && (red==0x7C00) ) mjiImageFormat = DIB_16RGB555; else if ( (blue==0x001F) && (green==0x07E0) && (red==0xF800) ) mjiImageFormat - DIB_16RGB565; else if ( (blue==OxOOFF) && (green==OxFFOO) && (red==OxFFOOOO) ) mjiImageFormat - DIB_32RGB888; } return true: bool KDIB::LoadBitmap(HMODULE hModule. LPCTSTR pBitmapName) { HRSRC hRes - FindResource(hModule. pBitmapName. RTJITMAP); if ( hRes—NULL ) return false; HGLOBAL hGlb - LoadResource(hModule. hRes); if ( hGlb—NULL ) return false; BITMAPINFO * pDIB - (BITMAPINFO *) LockResource(hGlb): if ( pDIB—NULL ) return false; return AttachDIBCpDIB. NULL. DIB_BMIREADONLY | DIB_BITS_READONLY); bool KDIB::LoadFile(const TCHAR * pFileName) { if ( pFileName—NULL ) return false; HANDLE handle - CreateFile(pFileName. GENERIC_READ. FILE_SHARE_READ. NULL. OPEN EXISTING. FILE ATTRIBUTEJORMAL. NULL): - DIB_32RGBbitfields; = DIB 32RGB888; // См. ниже
Класс для работы с DIB 555 if ( handle == INVALID_HANDLE_VALUE ) return false; BITMAPFILEHEADER bmFH; DWORD dwRead = 0: ReadFile(handle, & bmFH. sizeof(bmFH). & dwRead. NULL); if ( (bmFH.bfType == 0x4D42) && (bmFH.bfSize<=GetFileSize(handle. NULL)) ) { BITMAPINFO * pDIB = (BITMAPINFO *) new BYTE[bmFH.bfSize]; if ( pDIB ) { ReadFile(handle. pDIB. bmFH.bfSize. & dwRead, NULL); CloseHandle(handle); return AttachDIBCpDIB, NULL. DIB_BMI_NEEDFREE); } } CloseHandle(handle); return false; } Метод LoadBitmap получает манипулятор модуля и имя ресурса растра. Он ищет ресурс функцией FindResource, получает манипулятор ресурса функцией LoadResource и вызывает функцию LockResource для получения указателя на упакованный DIB-растр. Учтите, что в среде Win32 последовательность вызовов FindResource, LoadResource и LockResource не приводит к фактическому выделению ресурсов, за исключением того, что соответствующие страницы загружаются с диска в память. Значение, возвращаемое функцией LockResource, представляет собой указатель на образ модуля, содержащего ресурс. Следовательно, данные, на которые ссылается этот указатель, доступны только для чтения и освобождать их после использования необязательно. Функция LoadBitmap вызывает AttachDIB для инициализации экземпляра класса KDIB данными упакованного растра, доступного только для чтения. При этом функции AttachDIB передаются флаги DIB_ BMI_READONLY | DIB_BITS | READONLY, а удаление экземпляра класса KDIB не требует освобождения памяти в куче. Функция LoadFile открывает файл, читает структуру BITMAPFILEHEADER и проверяет сигнатуру BMP-файла с размером файла. Если проверка прошла успешно, функция выделяет блок памяти для упакованного DIB-растра и загружает в него оставшуюся часть файла. Указатель на блок передается AttachDIB для дополнительной проверки и инициализации переменных класса KDIB. Функция AttachDIB вызывается с флагом DIBJ3MI_NEDFREE, поэтому выделенный блок будет освобожден в деструкторе. Функция AttachDIB использует всю информацию, упоминавшуюся при описании формата DIB в предыдущем разделе, для инициализации десятка переменных класса. Сначала мы выбираем нужную версию заголовка блока описания растра из четырех возможных, а затем декодируем формат изображения.
556 Глава 10. Основные сведения о растрах В конце кода функции мы проверяем, соответствует ли изображение, находящееся в режиме сжатия BIBITFIELD, трем группам битовых масок, поддерживаемых в Windows 95/98. Функция работает как с упакованными, так и неупакованными DIB-растрами. Для неупакованных DIB-растров функции AttachDIB передаются два указателя. Несмотря на всю простоту, этот класс позволит нам загрузить любой ВМР- файл и начать эксперименты с растровыми изображениями. Отображение DIB в контексте устройства В Win32 GDI предусмотрено две функции для вывода аппаратно-независимого растра в контексте устройства: int StretchDIBitsCHDC hdc. int xDest, int yDest, int nDestWidth. int nDestHeight, in XSrc, int YSrc, int nSrcWidth, int nSrcHeight. CONST VOID * lpBits. CONST BITMAPINFO * IpBitsInfo, UINT iUsage, DWORD dwRop); int SetDIBitsToDevice(HDC hdc, int xDest. int yDest. DWORD dwWidth. DWORD dwHeight, in XSrc. int YSrc. UINT nStartScan, UINT cScanLines. CONST VOID * IpvBits. CONST BITMAPINFO * Ipbmi. UINT fuColorUse); StretchDIBits Функция StretchDIBits занимает в GDI исключительно важное место, поэтому мы начнем именно с нее. В первом параметре, конечно, передается манипулятор контекста устройства. Параметры XDest, YDest, nDestWidth и nDestHeight определяют (в логических координатах) прямоугольник, который будет выводиться на поверхности устройства. Затем следует еще одна четверка XSrc, YSrc, nSrcWidth и nSrcHeight, определяющая прямоугольный участок DIB-растра. Указатель lpBits ссылается на массив пикселов DIB, а указатель IpBitsInfo — на одну из версий структуры BITMAPINFO. В совокупности они определяют DIB-растр, упакованный или неупакованный. Параметр iUsage обычно равен DIBRGBC0L0RS (для цветовой таблицы RGB) или DIBPALC0L0RS (для цветовой таблицы, содержащей индексы логической палитры). Последний параметр содержит признак растровой операции, который заслуживает особого разговора. Пока мы будем использовать простейшую растровую операцию SRCC0PY. Функция StretchDIBits выделяет участок изображения DIB, выполняет отсечение, масштабирует выделенный участок по размерам приемного прямоугольника, преобразует к цветовому формату приемной поверхности и записывает полученные данные в приемную поверхность (при использовании растровой операции SRCC0PY). С концептуальной точки зрения процесс состоит из шести этапов: выбор источника, преобразование, отсечение, масштабирование, преобразование цветового формата и растровая операция. Исходный прямоугольник Первый этап (выбор источника) достаточно прост — источник определяется соответствующей четверкой параметров. Если вы хотите отобразить весь растр,
Отображение DIB в контексте устройства 557 передайте значения [0, 0, ширина изображения, высота изображения]. Помните, что для растров с прямым порядком строк развертки поле biHeight структуры BITMAPINFOHEADER отрицательно; используйте абсолютную величину (модуль). В GDI исходный прямоугольник определяется четверкой [XSrc,YSrc,XSrc+nSrcWidth, YSrc+nSrcHeight] с исключением правой и нижней сторон. Если приложение передает при вызове StretchDIBits значения [ширина изображения, высота изображения, -ширина изображения, -высота изображения], используется прямоугольник [ширина изображения, высота изображения, 0, 0]. Чем же этот прямоугольник отличается от прямоугольника [0, 0, ширина изображения, высота изображения]? GDI интерпретирует его как отображение системы координат и выводит весь растр, но с зеркальным отражением по вертикали и горизонтали. Используя параметры исходного прямоугольника, можно выделить фрагмент изображения. Если какая-либо часть заданного прямоугольника выходит за границы растра, она считается отсеченной. Некоторые комбинации параметров исходного прямоугольника приведены в табл. 10.3. Таблица 10.3. Параметры XSrc, YSrc, nSrcWidth и nSrcHeight функции StretchDIBits Значения Исходный прямоугольник 0, 0, ширина, высота Все изображение, исходная ориентация ширина, 0, -ширина, высота Все изображение, зеркальное отражение по горизонтали 0, высота, ширина, -высота Все изображение, зеркальное отражение по вертикали ширина, высота, -ширина, -высота Все изображение, зеркальное отражение по горизонтали и вертикали 0, 0, ширина, 1 Первая строка развертки 0, 0, 1, высота Первый столбец пикселов Обратите внимание: параметры исходного изображения интерпретируются как логические координаты, а не физические. Вертикальная координата 0 означает первую логическую строку развертки изображения, а не первую физическую строку. В растрах с прямым порядком строк развертки первая логическая строка развертки соответствует первой физической строке, но при обратном порядке строк первая логическая строка соответствует последней физической строке развертки в массиве пикселов. Приемный прямоугольник и режимы масштабирования Приемник можно определить аналогичным образом — отображением [XDst, YDst, Xdst+nDestWidth, YDst+nDestHeight] из логических координат в физические с исключением правой и нижней сторон. Если прямоугольник не нормализован,
558 Глава 10. Основные сведения о растрах выполняется зеркальное отражение. Таким образом, окончательная ориентация изображения зависит как от исходного, так и от приемного прямоугольников. Выбранный фрагмент исходного растра масштабируется по размерам приемного прямоугольника. Возможны три принципиально различающихся случая: сохранение исходного масштаба, увеличение или уменьшение. При сохранении масштаба все просто — один пиксел исходного изображения соответствует ровно одному пикселу приемной поверхности, не больше и не меньше. При увеличении один исходный пиксел может соответствовать нескольким приемным пикселам, причем масштабный коэффициент может быть дробным. При уменьшении несколько исходных пикселов преобразуются в один пиксел приемника (масштабный коэффициент тоже может быть дробным). Существует много способов масштабирования, причем ни одному из них нельзя отдать однозначного предпочтения. Способ масштабирования определяется одним из атрибутов контекста устройства — режимом масштабирования (stretch mode). Управление режимом масштабирования в GDI осуществляется двумя функциями: int SetStretchBltModeCHDC hDC. int iStretchMode); int GetStretchBltMode(HDC hDC); Функция SetStretchBltMode присваивает значение атрибуту режима масштабирования в контексте устройства, а функция GetStretchBUMode читает его. Допустимые значения перечислены в табл. 10.4. Таблица 10.4. Режимы масштабирования Режим масштабирования Описание (прежнее название) STRETCH_ANDSCANS (BLACK0NWHITE) Пикселы комбинируются поразрядной логической операцией И. В режиме RGB сохраняются черные пикселы STRETCH_ORSCANS (WHITE0NBLACK) Пикселы комбинируются поразрядной логической операцией ИЛИ. В режиме RGB сохраняются черные пикселы STRETCH_DELETESCAN (C0L0R0NC0L0R) Сохраняется один пиксел, остальные удаляются STRETCH_HALFTONE (HALFTONE) Вычислить средний цвет по нескольким пикселам. Поддерживается только в системах семейства NT. После установки этого режима следует выровнять базовую точку кисти функцией SetBrushOrgEx Режим масштабирования учитывается только при уменьшении, то есть при выводе большого исходного изображения в маленьком приемном прямоугольнике. Увеличение реализуется простым повторением пикселов. Если вы не хотите, чтобы в увеличенном растре возникали «зазубрины» на контурах, реализуйте собственный алгоритм масштабирования. Режимы STRETCHANDSCANS и STRETCH_ORSCANS предназначены для черно-белых изображений. Если вы хотите, чтобы тонкие черные линии на белом фоне не исчезали и не прерывались в результате масштабирования, воспользуйтесь режимом STRETCH_ANDSCANS, поскольку
Отображение DIB в контексте устройства 559 логическая операция И отдает предпочтение черному цвету (0) перед белым (1). Если вы хотите сохранить белые линии на черном фоне, используй- те операцию STRETCH_ORSCANS, поскольку она отдает предпочтение белому цвету. В цветных изображениях эти два режима приводят к искажению цветов, поэтому в этом случае используют следующие два режима. При выборе режима STRETCH_ DELETESCAN лишние данные попросту игнорируются. Этот способ работает быстро, но не всегда дает хорошие результаты, поскольку при уменьшении изображения лишние пикселы просто отбрасываются, что приводит к потере информации. В режиме STRETCH_HALFTONE вычисляется средний цвет группы пикселов, что улучшает восприятие уменьшенных объектов человеческим глазом. С другой стороны, этот режим работает гораздо медленнее. Другая проблема заключается в том, что режим STRETCH_HALFTONE реализован только в системах семейства NT. Преобразование цветового формата Цветное изображение может выводиться на черно-белом принтере, а черно-белое изображение может отображаться на цветном экране. В таких случаях GDI приходится преобразовывать пикселы из формата исходного изображения в формат приемного контекста устройства. Если форматы источника и приемника совпадают, преобразование касается только формата хранения данных. Изображения DIB всегда являются цветными. Даже двуцветный растр должен содержать цветовую таблицу с двумя элементами. Цветовая таблица преобразует индексы пикселов в цветовые значения. Если палитра не используется, пикселы могут содержать непосредственные значения RGB. При выводе на устройство с поддержкой палитры в отображении значений RGB на индексы палитры участвуют две палитры: логическая и системная. Операции с палитрой рассматриваются в главе 13. Чтобы вывести DIB с палитрой на RGB-устройстве, индексы, хранящиеся в растре, приходится преобразовывать в значения RGB по цветовой таблице растра. Задача вывода цветного изображения на монохромном устройстве не имеет однозначного решения. В режиме STRETCHHALFTONE функция StretchDIBits осуществляет полутоновое преобразование цветных изображений в черно-белый формат; в других режимах StretchDIBits подбирает ближайшие цвета. Для сравнения стоит заметить, что это поведение отличается от отображения аппаратно- зависимого растра в черно-белом контексте устройства. Растровая операция Итак, после преобразования цветового формата мы имеем преобразованный массив пикселов, готовый к записи на приемную поверхность. По аналогии с бинарными растровыми операциями, определяющими способ объединения цвета пера/кисти с цветом приемника, в GDI предусмотрены растровые операции, определяющие окончательное значение приемного пиксела. Растровые операции подробно рассматриваются в следующей главе. А пока мы ограничимся простейшей растровой операцией SRCCOPY, которая сводится к простому копированию пиксела исходного растра на приемную поверхность.
560 Глава 10. Основные сведения о растрах Пример использования функции StretchDIBits Ниже приведен небольшой пример, демонстрирующий применение функции StretchDIBits. Для начала необходимо добавить в класс KDIB функцию для отображения DIB. int DrawDIBCHDC hDC. int dx, int dy. int dw, int dh, int sx, int sy, int sw, int sh, DWORD гор) { if ( m_pBMI ) return ::StretchDIBits(hDC. dx, dy, dw, dh, sx, sy, sw. sh, m_pBits. m_pBMI. DIB_RGB_COLORS, гор); else return GDIJRROR; } После добавления этой функции мы можем воспользоваться классом KDIB для загрузки и отображения DIB. Код следующего фрагмента загружает растровый рисунок со львом и отображает его в четырех разных ориентациях. KDIB lion; if ( lion.LoadFile(_T("1ion.bmp")) ) { int w - DIB.GetWidthO; int h = DIB.GetHeightO: DIB.DrawDIB(hDC, 5, 5. w, h, 0, 0. w, h, SRCCOPY) DIB.DrawDIB(hDC. 10+w. 5, w. h. 0. 0. -w. h, SRCCOPY) DIB.DrawDIB(hDC, 5. 10+h. w. h. 0, 0, w. -h. SRCCOPY) DIB.DrawDIB(hDC. 10+w. 10+h. w. h. 0. 0. -w. -h. SRCCOPY) } Рис. 10.2. Зеркальное отражение рисунка с использованием функции StretchDIBits Этот пример приведен только для демонстрационных целей. Изображения в программе должны загружаться один раз, а не каждый раз, когда их потребуется
Отображение DIB в контексте устройства 561 вывести. Программа Bitmap, описываемая в этой главе, позволяет выбрать изображения DIB в диалоговом окне и отобразить их в дочерних окнах MDL С каждым дочерним окном связан экземпляр класса KDIB, который один раз загружает изображение и многократно отображает его. Одно из этих дочерних окон показано на рис. 10.2. SetDIBitsToDevice На фоне других функций GDI API функция SetDIBitsToDevice выглядит одиноко. Вероятно, компании Microsoft следовало бы исключить эту функцию из Win32 API. Если приложение импортирует ее, то, скорее всего, это делается косвенно через класс CDC MFC. Функция выводит DIB (полностью или частично) с сохранением исходной ориентации и масштаба, независимо от текущего мирового преобразования или режима отображения окна на область просмотра. Из всех параметров в логической системе координат задается лишь позиция приемника (xDest,yDest). Параметры XSrc, YSrc, dwWidth и dwHeight определяют часть DIB. He пытайтесь проделывать такие же фокусы со знаком параметров, как при вызове StretchDIBits — высота и ширина передаются в виде беззнаковых целых чисел. Передавать размеры приемного прямоугольника не нужно; в системе координат устройства они всегда соответствуют размерам источника. Но самое интересное в функции SetDIBitsToDevice — это способ передачи DIB- растра (или его части). В параметре lpbmi, как и прежде, передается указатель на заголовок блока описания растра. Параметр lpvBits указывает на буфер, содержащий несколько строк развертки или весь растр. Функция спроектирована таким образом, чтобы в lpvBits можно было передавать указатель на часть, а не на весь DIB-растр. Расположение данных в буфере определяется двумя дополнительными параметрами. Параметр uStartScan содержит последовательный номер строки развертки в изображении, на первую строку которого ссылается lpvBits, а параметр cScanLines содержит количество строк развертки в буфере. Функция SetDIBitsToDevice всегда копирует исходные пикселы в приемник, поэтому указывать растровую операцию не нужно. Последний параметр, fuColorUse, идентифицирует способ интерпретации цветовой таблицы. Функция SetDIBitsToDevice копирует cScanLines из буфера на приемную поверхность, начиная с (xDest, yDest+uStartScan), с учетом отсечения исходного прямоугольника и отсечения, действующего в приемном контексте устройства. Учтите, что координаты приемника должны задаваться в системе координат устройства. В следующем фрагменте показано, как при помощи функции SetDIBitsToDevice вывести все изображение, начиная с точки приемника (х,у). SetDIBitsToDevice(hDC. х, у, mjiWidth. abs(m_nHeight), О, О, О, abs(mjiHeight). m_pBits, (const BITMAPINFO *) m_pDIB, DIB_RGB_C0L0RS); Единственным преимуществом SetDIBitsToDevice перед StretchDIBits является снижение затрат памяти. Если приложение Win 16, работающее на портативном компьютере с 4 Мбайт памяти, должно вывести 1-мегабайтный растр в формате BMP, оно не сможет полностью загрузить его в память. При использовании функции SetDIBitsToDevice можно загрузить в память заголовок блока
562 Глава 10. Основные сведения о растрах описания растра и цветовую таблицу, получить все параметры, а затем в цикле читать из буфера строки развертки и вызывать SetDIBitsToDevice для каждой строки. В этом случае можно обойтись буфером, в котором помещается всего одна строка развертки, а при наличии свободной памяти можно одновременно читать несколько строк развертки. Функция StretchDIBits тоже позволяет реализовать принцип последовательной загрузки, но вам придется модифицировать поле высоты в заголовке блока описания растра в соответствии с количеством строк развертки в буфере, а также изменять параметры исходного и приемного прямоугольника при каждом вызове. В приложениях Win32 затраты памяти уже не столь критичны, как в приложениях Win 16. Если возникает необходимость вывести большой графический файл, приложение может воспользоваться файлами, отображаемыми на память (memory-mapped files). При этом графика отображается в виртуальную память, находящуюся под управлением диспетчера памяти операционной системы. В системах Windows 95/98 вывод больших изображений одним вызовом StretchDIBits нередко вызывает проблемы с быстродействием системы. Реализация GDI в этих системах фактически состоит из 16-разрядного кода. При каждом графическом выводе происходит переход от 32-разрядного GDI к 16-разрядному, при этом доступ к GDI со стороны других программных потоков блокируется, поскольку 16-разрядная реализация не является безопасной в отношении многопоточного доступа. GDI может потратить несколько секунд на обработку одной функции с огромным объемом данных, и на это время даже курсор мыши застывает в одном положении. Приложения, работающие в Windows 95/98, очень часто делят большие изображения на несколько меньших фрагментов. Функция SetDIBitsToDevice не масштабирует изображение. Следовательно, когда возникает необходимость в масштабировании, приложению приходится реа- лизовывать собственный алгоритм. Конечно, это существенный недостаток функции SetDIBitsToDevice. Если приложение работает в режиме отображения ММ_ТЕХТ, функция SetDIBitsToDevice может использоваться для преобразования фрагментов изображения в уменьшенном буфере. В следующем примере растр инвертируется во время отображения. if ( ! m_DIB.Compressed() ) { int bps - m_DIB.GetBPS(); BYTE * buffer = new BYTE[bps]; for (int i=0; i<m_DIB.GetHeight(); i++) { memcpy(buffer, m_DIB.GetBits() + bps*i. bps); for (int j=0; j<bps; j++) buffer[j] = - buffer[j]; SetDIBitsToDevice(hDC. 10, 10. m_DIB.GetWidth(). m_DIB.GetHeight(). 0. 0, i, 1. buffer. m_DIВ.GeBMI(), DIB_RGB_C0L0RS); } delete [] buffer; }
Совместимые контексты устройств 563 Для сжатых изображений этот код не работает, поскольку сжатие существенно затрудняет переход между строками развертки. Каждая строка развертки копируется в буфер, инвертируется и отображается на экране вызовом Set- DIBitsToDevice. Строки обрабатываются последовательно; в параметрах изменяется только значение uStartScan. Совместимые контексты устройств Контексты устройств, рассматривавшиеся до настоящего момента, всегда соответствовали реальному физическому устройству, которое обслуживалось специальным драйвером. Контекст устройства предоставляет в распоряжение программ, использующих GDI, абстрактное графическое устройство. В своей внутренней реализации GDI поддерживает для каждого контекста устройства таблицу функций драйвера графического устройства, вызываемых через интерфейс DDL Такое описание напоминает виртуальные функции C++ или методы СОМ; действительно, в работе этих механизмов имеется определенное сходство. Абстрактный подход позволяет GDI полностью имитировать графическое устройство в памяти — в том же смысле, в каком виртуальный диск имитирует жесткий диск. Для работы с графическими устройствами, имитируемыми в памяти, применяются совместимые контексты устройств (memory device context). По историческим причинам совместимые контексты устройств не являются полностью независимыми от физических графических устройств. В действительности совместимый контекст устройства всегда связывается с физическим графическим устройством. Выражаясь точнее, в GDI поддерживается всего одна функция для создания контекста устройства, совместимого с существующим контекстом: HDC CreateCompatibleDC(HDC hDC); Эталонный контекст устройства, передаваемый этой функции, должен поддерживать растровые операции, иначе совместимый контекст не принесет особой пользы. Для создания совместимых контекстов обычно используется экранный контекст, поскольку современные видеоадаптеры обеспечивают полную и правильную реализацию растровых операций. Напротив, контекст устройства принтера вряд ли является хорошим кандидатом для создания совместимого контекста устройства. Принтеры обладают различным уровнем поддержки цветов и растровых операций. Например, в драйвере принтера PostScript поддержка растровых операций обычно ограничена. GDI даже позволяет передавать манипулятор NULL; в этом случае создается контекст устройства, совместимый с текущим экраном. Работа совместимого контекста устройства основана на использовании растра. Все графические команды реализуются как вывод на растре, а не на физическом устройстве. Между этим растром и совместимым контекстом устройства не существует жесткой связи. Базовый растр является атрибутом контекста; его можно выбирать и исключать, как манипулятор объекта пера или кисти. Для получения этого атрибута можно вызвать функцию GetCurrentObject с типом OBJBITMAP. При создании совместимого контекста устройства GDI присваивает
564 Глава 10. Основные сведения о растрах этому атрибуту монохромный растр, состоящий из одного пиксела. По крайней мере, вы можете получить и задать цвет этого пиксела. Чтобы использовать совместимый контекст устройства, необходимо создать и выбрать в нем базовый растр. Аппаратно-независимые растры, описанные в предыдущем разделе, для этого не подходят. В качестве поверхности для совместимого контекста устройства GDI разрешает использовать только аппарат- но-зависимые растры и DIB-секции. Эти два типа растров рассматриваются в следующих двух разделах. Совместимые контексты устройств чрезвычайно важны для графического программирования Windows, но мы временно оставим эту тему и вернемся к ней после знакомства с аппаратно-зависимыми растрами и DIB-секциями. Аппаратно-зависимые растры Аппаратно-независимые растры (DIB) позволяют легко получать изображения из внешних источников, выполнять с ними программные операции, отображать или передавать графические данные другим приложениям или компьютерам. Основная проблема заключается в том, что GDI не поддерживает прямую запись в DIB. Для этой цели в GDI предусмотрен другой класс растров — аппаратно-зависимые растры. Аппаратно-зависимый растр (Device-Dependent Bitmap, DDB) представляет собой объект GDI, который находится под управлением GDI и драйверов устройств и обладает тем же статусом, что и объект логического пера, логической кисти или региона. При создании DDB-растра GDI и драйвер графического устройства определяют его внутренний формат данных и выделяют память из области памяти GDI. После этого все операции с DDB выполняются через манипулятор объекта GDI. Манипулятору аппаратно-зависимого растра в GDI присваивается тип HBITMAP. DDB-растры также часто называют «растровыми объектами GDI». В GDI предусмотрен богатый набор функций для работы с аппаратно-зависимыми растрами, поскольку они широко используются самой операционной системой. В частности, DDB-растры могут применяться в операциях с геометрическими перьями, узорными кистями, каретками, меню и стандартными элементами управления. Существует несколько способов создания растровых объектов GDI: HBITMAP CreateBitmap(int nWidth, int nHeight. UINT cPlanes, UINT cBitsPerPel. CONST VOID * IpvBits); HBITMAP CreateBitmapIndirect(CONST BITMAP * lpbm): HBITMAP CreateCompatibleBitmap(HDC hDC. int nWidth, int nHeight); HBITMAP CreateDiscardableBitmap(HDC hDC. int nWidth, int nHeight); HBITMAP CreateDIBitmap(HDC hdc. CONST BITMAPINFOHEADER * Ipbmih, DWORD fdwlnit. CONST VOID * Ipblnit. CONST BITMAPINFO * lpbmi. UINT fuUsage); HBITMAP LoadBitmapCHINSTANCE hlnstance, LPCTSTR IpBitmapName); Между DDB и DIB существует несколько принципиальных различий. По своей исходной архитектуре DDB зависит от устройства. Это означает, что любое гра-
Аппаратно-зависимые растры 565 фическое устройство может выбрать для представления DDB свой собственный внутренний растровый формат. Реальный формат DDB может изменяться при работе приложения на разных компьютерах и даже на одном компьютере в разных видеорежимах. Аппаратно-зависимый растр, как и DIB, содержит массив пикселов, но при передаче или чтении данных DDB строки развертки всегда следуют в прямом порядке (сверху вниз), поэтому отдельно обрабатывать отрицательную высоту для перевернутых растров не нужно. В отличие от DIB-раст- ров, всегда использующих строки развертки с одной цветовой плоскостью, DDB- растры могут использовать несколько цветовых плоскостей, чтобы обеспечить совместимость с конкретным графическим устройством для получения оптимального быстродействия. Массивы пикселов, передаваемые функциям создания DDB, должны выравниваться по 16-разрядной границе слов. DDB не содержит цветовой таблицы, поэтому реальный цвет каждого пиксела изображения зависит от устройства, на котором оно выводится. CreateBitmap DDB определяется шириной, высотой, количеством плоскостей, количеством бит на пиксел и массивом цветов (или индексов) пикселов. Эти пять характеристик передаются при вызове функции CreateBitmap. Функция создает растр nWidth* nHeight, с числом цветовых плоскостей, равным cPlanes, и кодировкой cBitsPerPel бит/пиксел. Параметр IpvBits содержит указатель на исходный массив пикселов; предполагается, что размер этого массива равен (nWidth*cBitsPerPel+15)/16*2* cP1anes*nWidth*nHeight. GDI выделяет блок памяти соответствующего размера и копирует в него данные инициализации. Если параметр IpvBits равен NULL, созданный растр не инициализируется. С точки зрения системы между DIB и DDB существуют значительные различия. Упакованный DIB-растр определяется одним указателем, а неупакованный — двумя указателями. Эти указатели относятся к адресному пространству пользовательского режима, базирующемуся на файле, отображаемом в память, либо на системном файле подкачки. Максимальный размер DIB ограничивается только объемом дискового пространства и 2-гигабайтным объемом адресного пространства пользовательского режима. В Windows 95/95 DDB-растры хранятся в 32-разрядной куче GDI, хотя реализация GDI в этих системах фактически полностью состоит из 16-разрядного кода. Максимальный размер DDB в этих системах равен 16 Мбайт. Размер строки развертки не может превышать 64 Кбайт. В системах семейства NT, начиная с Windows NT 4.0, память для DDB выделяется из выгружаемого пула, находящегося в адресном пространстве ядра. В выгружаемом пуле хранятся многие объекты GDI (в том числе регионы, контексты устройств, траектории) и другие объекты, с GDI не связанные. Максимальный размер DDB равен 48 Мбайт, тогда как объем всего выгружаемого пула не превышает 192 Мбайт. Кроме того, на DDB тратится еще один потенциально ограниченный системный ресурс — манипуляторы объектов GDI. Короче говоря, вместо ресурсов уровня процесса DDB поглощает общесистемные ресурсы, поэтому при создании больших DDB-растров (или большого количества DDB- растров), а также утечке ресурсов необходимо действовать очень осторожно.
566 Глава 10. Основные сведения о растрах У DDB существует всего один стандартный формат — одноплоскостной монохромный формат с кодировкой 1 бит/пиксел. В других форматах параметры nPlanes и cBitsPerPel всего лишь определяют минимальные требования к растру. Во внутренней работе современных графических устройств используется стандартный формат DIB с одной цветовой плоскостью. GDI поручает драйверу устройства выбор ближайшего доступного формата с кодировкой по крайней мере nPlanes*cBitsPerPel бит/пиксел. Например, на запрос формата с 3 плоскостями и 8 битами/пиксел предоставляется DDB с одной плоскостью 24 бит/пиксел, а на запрос с 3 плоскостями и 10 битами/пиксел — DDB с одной плоскостью и 32 бит/пиксел. Параметры nPlanes и cBitsPerPel также определяют интерпретацию исходного содержимого массива пикселов. В текущей реализации GDI, если произведение nPlanes*cBitsPerPel больше 32, попытка создания растра завершается неудачей. Следующий фрагмент показывает, как создать DDB-растр с кодировкой 1 бит/пиксел, инициализированный шахматным узором 4x4, и неинициализированный DDB-растр с кодировкой 24 бита/пиксел: const WORD Data88_lpp[] = { OxCC, OxCC. 0x33. 0x33, OxCC. OxCC. 0x33, 0x33 }; HBITMAP hBmplbpp - CreateBitmap(8, 8. 1, 1. Data88_lpp); HBITMAP hBmp24bpp = CreateBitmap(8. 8. 3, 8. NULL); CreateBitmapIndirect Функция CreateBitmapIndirect позволяет создать DDB через указатель на структуру BITMAP, которая определяется следующим образом: typedef struct tagBITMAP { LONG bmType; // Тип растра, должен быть равен 0 LONG bmWidth; LONG bmHeight; LONG bmWidthBytes; WORD bmPlanes; WORD bmBitsPixel; LPV0ID bmBits; } BITMAP; При сравнении полей структуры со списком параметров CreateBitmap обнаруживаются три основных различия. Хотя в структуре появилось новое поле bmType, оно должно быть равно 0. В поле bmWidthBytes хранится размер строки развертки массива пикселов в байтах. Как и в случае с функцией CreateBitmap, оно должно быть четным числом. Поле bmBits содержит указатель на массив пикселов, но этот указатель не определяется как константный. В документации Microsoft ошибочно утверждается, что размер строки развертки должен быть кратен 32 битам. На самом деле это не обязательно. На практике GDI всегда стремится объединять вызовы разных функций в один системный вызов; функция CreateBitmapIndirect также реализуется вызовом CreateBitmap. Но если значение поля bmWidthBytes выходит за 16-разрядные границы, то GDI перед вызовом CreateBitmap выделяет временный блок памяти из системной кучи и копирует исходный массив пикселов.
Аппаратно-зависимые растры 567 GetObject и DDB При вызове CreateBitmap или CreateBitmapIndirect параметры всего лишь определяют требования к формату массива пикселов. GDI или драйвер графического устройства могут выбрать необходимость сохранения растра в формате, поддерживаемом устройством. Это вполне допустимо, поскольку формат является ап- паратно-зависимым. По манипулятору объекта DDB функция GetObject дает некоторое представление о реальном формате, используемом для представления растра. Приложение не имеет прямого доступа к аппаратно-зависимому растру, поэтому эта информация неполна. Например, в структуре, возвращаемой GetObject, поле bmBits всегда равно NULL, потому что GDI не хочет сообщать приложению, где хранятся графические данные растра. Поле bmWidthBytes всегда округляется до четного числа, но во внутреннем представлении растр может храниться в формате DIB (с выравниванием по границе DWORD), поддерживаемом графическим механизмом систем семейства NT. Пример использования CreateBitmapIndirect и GetObject: DWORD Chess44[] = { OxCC. OxCC, 0x33, 0x33, OxCC. OxCC, 0x33. 0x33 }; BITMAP bmp - { 0. 8. 8, sizeof(Chess44[0]). 1. 1, Chess44 }; HBITMAP hBmp - CreateBitmapIndirect(&bmp); GetObject(hBmp, sizeof(bmp), & bmp); DeleteObject(hBMP): Приведенный фрагмент создает DDB функцией CreateBitmapIndirect, используя массив пикселов, выровненный по границе DWORD, а затем получает информацию объекта DDB при помощи функции GetObject. В структуре BITMAP, заполняемой функцией GetObject, поле bmWidthBytes равно 2 вместо 4, а поле bmBits равно NULL. Если переопределить Chess44 как массив типа WORD, результат будет тем же. CreateCompatibieBitmap и CreateDiscardableBitmap Цветной растр, созданный функцией CreateBitmap или CreateBitmapIndirect, может оказаться несовместимым с контекстом устройства, в котором вы собираетесь его отобразить. Вполне нормальный DDB-растр, несовместимый с контекстом устройства, будет отвергнут при попытке использования его в данном контексте. Чтобы создаваемый растр был заведомо совместим с устройством, воспользуйтесь функцией CreateCompatibieBitmap. Функция CreateCompatibieBitmap выглядит гораздо проще — ей передается только манипулятор эталонного контекста устройства, а также требуемая ширина и высота растра. CreateCompatibieBitmap не нужно знать количество цветовых плоскостей и количество бит на пиксел, поскольку эти характеристики вычисляются на основании данных эталонного контекста. Если контекст устройства соответствует физическому графическому устройству, GDI задействует его характеристики для создания растра. Например, при использовании экранного контекста устройства режиме с 256 цветами CreateCompatibleDC создает DDB с кодировкой 8 бит/пиксел, а в 32-разрядном режиме True Color создается DDB с кодировкой 32 бит/пиксел. Следовательно, если приложение запрашивает DDB с размерами
568 Глава 10. Основные сведения о растрах 1024 х 1024, то необходимый объем памяти будет равен 1 Мбайт для режима с 256 цветами и 4 Мбайт для 32-разрядного режима True Color. Для совместимых контекстов устройств GDI создает растр с таким же форматом пикселов, как и у текущего растра, выбранного в контексте устройства. Как было сказано в предыдущем разделе, при создании совместимого контекста устройства в нем выбирается монохромный растр, состоящий из одного пиксела, поэтому функция CreateCompatibleBitmap для этого контекста устройства создает монохромный растр. Следующая функция отвечает на некоторые часто возникающие вопросы — почему функция CreateCompatibleBitmap отказывается создавать DDB и каков максимальный размер DDB-растра? Функция LargestDDB получает манипулятор контекста устройства и использует алгоритм бинарного поиска для определения размеров наибольшего DDB-растра, совместимого с этим контекстом. HBITMAP LargestDDBCHDC hDC) { HBITMAP hBmp; int mins = 1; int maxs = 1024 * 128; while ( true ) // Бинарный поиск наибольшего DDB { int mid = (mins + maxs)/2; hBmp = CreateCompatibleBitmap(hDC, mid. mid); if ( hBmp ) { HBITMAP h = CreateCompatibleBitmap(hDC, mid+1. mid+1); if ( h==NULL ) return hBmp; DeleteObject(h); DeleteObject(hBmp); mins = mid+1; } else maxs = mid; } return NULL; } При передаче только что созданного совместимого контекста устройства функция может генерировать довольно большой монохромный DDB-растр; если передается экранный контекст, наибольший DIB-растр имеет существенно меньшие размеры в пикселах из-за увеличившейся цветовой глубины. В табл. 10.5 приведены результаты, полученные при вызове функции LargestDDB для контекстов устройств с разной цветовой глубиной. На первый взгляд эта статистика выглядит просто, однако она может сильно повлиять на архитектуру ваших программ. Если приложение работает с DDB, то размер одного DDB-растра фактически ограничивается величиной в 3,96 мегапиксела для худшего случая — системы Windows 95/98 в экранном режиме с
Аппаратно-зависимые растры 569 32-разрядной кодировкой пикселов. Современные цифровые фотоаппараты нередко создают изображения, содержащие свыше 2 мегапикселов. Следовательно, приложение даже не сможет сохранить в DDB изображение, полученное с цифрового фотоаппарата, в масштабе 2:1, поскольку оно будет занимать 16 Мбайт. Таблица 10.5. Максимальные размеры совместимого DDB-растра Цветовая глубина DC Windows NT/2000 Windows 95/98 1 17 408x17 408; 36,125 Мбайт 11474x11474; 15,71 Мбайт 8 6144x6144; 36 Мбайт 4079x4079; 15,87 Мбайт 16 4352x4352; 36,125 Мбайт 2880x2880; 15,82 Мбайт 24 3584x3584; 36,76 Мбайт 2352x2352; 15,82 Мбайт 32 3072x3072; 36 Мбайт 2039x2039; 15,86 Мбайт Во времена Winl6 памяти вечно не хватало, поэтому в GDI была включена функция CreateDiscardableBitmap для создания освобождаемых растров. Идея состояла в том, чтобы интерфейс GDI мог освобождать ресурсы растра в случае их нехватки. Каждый раз, когда приложение хотело воспользоваться освобождаемым растром, оно должно было проверить его и воссоздать заново, если растр стал недействительным. Хотя функция CreateDiscardableBitmap входит и в Win32 GDI, она не создает освобождаемый растр. Вместо этого она просто вызывает CreateCompatibleBitmap. В 32-разрядных операционных системах затраты памяти на хранение аппаратно-зависимых растров по-прежнему остаются серьезной проблемой, особенно в экранных режимах True Color при высоком разрешении. Впрочем, программы Win32 могут использовать DIB-секции и тем самым переместить затраты памяти из системных ресурсов GDI на уровень приложения. CreateDIBitmap Описанные выше функции не позволяют легко создать инициализированный цветной DDB-растр. Хотя при вызове CreateBitmap и CreateBitmapIndirect можно передать указатель на массив пикселов, сложность цветного изображения при этом не учитывается. С другой стороны, аппаратно-независимый растр обладает хорошими средствами для описания стандартных цветовых форматов. По этой причине в GDI была предусмотрена функция CreateDIBitmap, которая создает инициализированный DDB-растр на базе DIB, то есть в каком-то смысле преобразует DIB в DDB. Функция CreateDIBitmap работает в два этапа: сначала она создает DDB, а затем преобразует DIB в DDB. В параметре hdc передается манипулятор эталонного контекста устройства, с которым должен быть совместим созданный DDB- растр. При передаче NULL создается монохромный DIB-растр. Параметр Ipbmih содержит указатель на структуру заголовка блока описания растра, но в ней используются только поля ширины и высоты. Если высота отрицательна, исполь-
570 Глава 10. Основные сведения о растрах зуется абсолютное значение. Другие поля (такие, как количество бит на пиксел и режим сжатия) не используются. Инициализация созданного DDB-растра необязательна и зависит от параметра fdwinit. Если параметр равен CBMINIT, следующие три параметра полностью описывают неупакованный DIB-растр. Параметр lpblnit указывает на массив пикселов, параметр 1 pbmi — на заголовок блока описания растра, а параметр fuUsage сообщает, содержит ли цветовая таблица индексы палитры или цвета RGB. Следующая функция класса KDIB преобразует DIB в DDB: HBITMAP ConvertToDDB(HDC hDC) { return CreateDIBitmap(hDC. & m_pBMI->bmiHeader, CBMJNIT, m_pBits. m_pBMI, DIB_RGB_C0L0RS); } Если в процессе преобразования DIB в DDB задействована палитра, то используется текущая палитра, выбранная в контексте устройства. LoadBitmap В Windows-программировании растры обычно присоединяются к модулю в виде ресурса и затем загружаются в виде DDB функцией LoadBitmap. Функция LoadBitmap получает два параметра: hlnstance — манипулятор модуля, содержащего растровый ресурс, и IpBitmapName — имя растрового ресурса. Если параметр hlnstance равен NULL, во втором параметре передаются константы 0BM_BTNC0RNERS, 0BM_CHECK и т. д., определяющие десятки стандартных системных растров. Эти растры либо берутся непосредственно из модуля USER32.dll, либо синтезируются этим модулем. Если для идентификации растра в ресурсном файле используется целочисленный идентификатор, преобразование целого числа в указатель на символьную строку выполняется с помощью макроса MAKEINTRESOURCE. Растровые ресурсы хранятся в модулях Win32 в формате упакованного DIB- растра. Функция LoadBitmap находит растровый ресурс, фиксирует его в памяти для получения манипулятора упакованного DIB-растра и затем создает DDB- растр, совместимый с текущим экранным режимом. Для монохромных растров (то есть DIB-растров, у которых цветовая таблица содержит только черный и белый цвет) GDI использует монохромный формат DDB вместо цветного формата, увеличивающего затраты памяти. При работе в 256-цветном экранном режиме с палитрой загрузка изображений True Color и High Color приводит к ухудшению качества изображения, поскольку приложение не может управлять процессом преобразования цветов. Код следующего фрагмента загружает растровое изображение панели инструментов из библиотеки BROWSEUI.dll: HINSTANCE hMod - LoadLi brary Cbrowseui.dll"); HBITMAP hBmp = LoadBitmap(hMod. MAKEINTRES0URCE(26D); FreeLibrary(hMod); В документации Microsoft сказано, что в Windows 95 при использовании функции LoadBitmap возникают проблемы с загрузкой растров объемом более 64 Кбайт из-за базовой 16-разрядной реализации. Если размер ресурса DIB пре-
Аппаратно-зависимые растры 571 вышает 64 Кбайт, внутренняя реализация LoadBitmap преобразует его в 16-разрядное значение со сдвигом влево, что может привести к потере младших битов размера. Обходное решение заключается в дополнении ресурса нулями для округления размера. В стандартной схеме применения LoadBitmap растр загружается и выводится один раз, после чего объект удаляется. Если вас беспокоит быстродействие программы, в эту схему можно внести изменения. Преобразование DIB в DDB выполняется медленно, a DDB тратит лишние системные ресурсы. В таких ситуациях быстрее и «дешевле» напрямую работать с DIB. Но если растр загружается один раз и используется многократно, использование DDB может сэкономить время, затрачиваемое на преобразование формата растра. Копирование растров между форматами DIB и DDB Кроме функций для создания новых DDB-растров в GDI предусмотрены две функции для копирования пикселов между DDB и DIB. int SetDIBitsCHDC hdc, HBITMAP hbmp. UINT uStartScan. UINT cScanLines. CONST VOID * lpvBits. CONST BITMAPINFO * lpbmi. UINT fuColorUse); int GetDIBitsCHDC hdc. HBITMAP hbmp. UINT uStartScan. UINT cScanLines. CONST VOID * lpvBits. CONST BITMAPINFO * lpbmi. UINT fuColorUse); Списки параметров этих двух функций совпадают, хотя в документации MSDN имена слегка различаются. Первый параметр определяет эталонный контекст устройства, палитра которого должна использоваться при преобразовании формата пикселов. Второй параметр содержит манипулятор существующего объекта аппаратно-зависимого растра. Пять оставшихся параметров определяют фрагмент неупакованного DIB-растра и интерпретацию его цветовой таблицы. Фрагмент может представлять собой как полный DIB-растр, так и группу смежных строк развертки. Подобное решение в основном предназначено для экономии памяти и для постепенного вывода фрагментов растра, загружаемого по медленному соединению. Параметр lpvBits содержит указатель на строки развертки, параметр uStartScan определяет номер первой строки развертки в буфере, а параметр cScanLines — количество строк развертки в буфере. Функция SetDIBits преобразует пикселы заданного фрагмента DIB в формат DDB и копирует результат в DDB. Функция GetDIBits преобразует пикселы из формата DDB в формат DIB и копирует результат в буфер фрагмента DIB. Функция SetDIBits в действительности реализуется функцией SetDIBitsToDevice с указанием в качестве приемника совместимого контекста устройства, в котором выбран DDB-растр. В процессе преобразования в совместимом контексте устройства выбирается палитра контекста, определяемого параметром hdc. Существует несколько способов преобразования DIB в DDB. DIB-растр, хранящийся в виде ресурса, можно загрузить в DDB функцией LoadBitmap. К сожалению, при этом вы не управляете процессом преобразования. Функция CreateDIBitmap создает на базе DIB абсолютно новый DDB-растр, совместимый с заданным контекстом устройства. Таким образом, эта функция позволяет в
572 Глава 10. Основные сведения о растрах определенной степени управлять преобразованием цветов и в то же время с ней легко работать. По сравнению с LoadBitmap и CreateDIBitmap функция SetDIBits обладает более широкими возможностями. Поскольку в DDB копируется не весь DIB-растр, а его фрагмент, вызывающая сторона может использовать буфер меньшего размера и выполнять преобразование постепенно; кроме того, она может объединить несколько маленьких DIB-растров в один большой DDB-растр и управлять форматом DDB. Как считается, самый распространенный способ преобразования DDB в DIB предлагает функция GetDIBits. Процесс преобразования DDB в DIB непрост, поскольку при этом приходится обеспечивать поддержку разных форматов DIB. Функция GetDIBits поддерживает все допустимые для DIB комбинации цветовых кодировок, форматов (RGB/палитра), наличия и отсутствия сжатия RLE в массиве пикселов, а также битовых полей. В параметре lpbmi передается указатель на информационный заголовок DIB-растра, определяющий его формат. При сжатии RLE приложение не может легко определить размер сжатого изображения. Функцию GetDIBits приходится вызывать дважды. При первом вызове в указателе на массив пикселов передается NULL, на что GDI возвращает необходимый размер буфера. При втором вызове выделенный буфер указанного размера заполняется данными изображения. В листинге 10.3 приведена функция BitmapToDIB, которая является удобной оболочкой для вызова функции GetDIBits. Функция получает манипулятор объекта палитры GDI, используемого для построения цветовой таблицы, манипулятор объекта DDB, количество байт на пиксел и флаг сжатия DIB. Функция вычисляет размер DIB, выделяет буфер нужного размера, записывает в него данные DDB и возвращает указатель на буфер. Листинг 10.3. Функция BitmapToDIB: преобразование DDB в DIB BITMAPINFO * BitmapToDIBCHPALETTE hPal, // Палитра для // преобразования цвета HBITMAP hBmp, // Преобразуемый DDB-растр int nBitCount, int nCompression) // Нужный формат { typedef struct { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[256+3]; } DIBINFO; BITMAP ddbinfo; DIBINFO dibinfo; // Получение данных DDB if ( GetObject(hBmp, sizeof(BITMAP), & ddbinfo)==0 ) return NULL; // Заполнение структуры BITMAPINFOHEADER // по данным размера и запрашиваемому формату memsetC&dibinfo, 0, sizeof(dibinfo)); di bi nfо.bmi Header.bi Si ze = sizeof(BITMAPINFOHEADER);
Аппаратно-зависимые растры 573 dibinfo.bmiHeader.bi Width = ddbi nfo.bmWi dth: dibinfo.bmiHeader.biHeight = ddbinfo.bmHeight: dibinfo.bmiHeader.biPlanes = 1: dibinfo.bmiHeader.biBitCount = nBitCount; dibinfo.bmiHeader.biCompression = nCompression; HDC hDC = GetDC(NULL); // Экранный контекст устройства HGDIOBJ hpalOld; if ( hPal ) hpalOld = SelectPalette(hDC, hPal. FALSE); else hpalOld = NULL; // Запросить у GDI размер изображения GetDIBitsChDC. hBmp. 0. ddbinfo.bmHeight. NULL. (BITMAPINFO *) & dibinfo. DIB_RGB_COLORS); int nlnfoSize = sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * GetDIBColorCount(dibinfo.bmiHeader); int nTotalSize = nlnfoSize + GetDIBPixelSize(dibinfo.bmiHeader); BYTE * pDIB = new BYTE[nTotalSize]; if ( pDIB ) { memcpy(pDIB. & dibinfo. nlnfoSize); if ( ddbinfo.bmHeight != GetDIBitsChDC. hBmp. 0. ddbinfo.bmHeight. pDIB + nlnfoSize. (BITMAPINFO *) pDIB. DIB_RGB_COLORS) ) { delete [] pDIB; pDIB = NULL; if ( hpalOld ) SelectObject(hDC. hpalOld); ReleaseDC(NULL. hDC); return (BITMAPINFO *) pDIB; } Для упрощения вызова функция BitmapToDIB не требует, чтобы вызывающая сторона передавала структуру BITMAPINFO. Она создает в стеке структуру DIBINFO с цветовой таблицей из 259 элементов; этого вполне достаточно для DIB-растра, использующего битовые поля и 256 цветов полной палитры. Ширина и высота DIB вычисляются по размерам DDB. После того как первый вызов GetDIBits вернет фактический размер изображения, функция выделяет память для буфера, копирует заголовок описания растра, а затем вызывает GetDIBits для загрузки всего DIB-растра.
574 Глава 10. Основные сведения о растрах Функция GetDIBits обладает и другой неочевидной особенностью. Если присвоить значение только полю biSize и оставить остальные поля равными 0, GDI заполнит их данными о количестве бит/пиксел и режиме сжатия, используемом контекстом устройства. Таким образом, приложение может точно определить формат пикселов, используемый контекстом устройства. Этот прием особенно полезен в том случае, если приложение должно напрямую работать с пикселами в видеорежиме с кодировкой 16 бит/пиксел. У 16-разрядной кодировки существует два стандартных подтипа: 5-5-5 и 5-6-5. В некоторых ситуациях приложение должно знать точный формат пикселов; задача решается функцией Pixel Format, приведенной в листинге 10.4. Листинг 10.4. Функция PixelFormat: определение формата пикселов контекста устройства int PixelFormatCHDC hdc) { typedef struct { BITMAPINFOHEADER bmiHeader: RGBQUAD bmiColors[256+3]: } DIBINFO: DIBINFO dibinfo; HBITMAP hBmp = CreateCompatibleBitmap(hdc, 1. 1): if ( hBmp==NULL ) return -1: memsetC&dibinfo. 0, sizeof(dibinfo)): dibinfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); // Первый вызов для получения значения biBitCount для hdc GetDIBits(hdc. hBmp, 0, 1. NULL, (BITMAPINF0*) & dibinfo, DIB_RGB_C0L0RS): // Второй вызов для получения цветовой таблицы или битовых полей GetDIBits(hdc, hBmp. 0. 1. NULL, (BITMAPINFO*) & dibinfo. DIB_RGB_C0L0RS): DeleteObject(hBmp): // Попытаться интерпретировать битовые поля if ( di bi nfo.bmi Header.bi BitCount==BI_BITFIELDS ) { DWORD * pBitFields = (DWORD *) dibinfo.bmiColors: DWORD red - pBitFields[0]: DWORD green = pBitFields[l]: DWORD blue = pBitFields[2]; if ( (blue—OxOOlF) && (green==0x03E0) && (red==0x7C00) ) return DIB_16RGB555: else if ( (blue—OxOOlF) && (green==0x007E) && (red==0xF800) ) return DIBJ6RGB565: else if ( (blue==0x00FF) && (green==0xFF00) && (red==0xFF0000) )
Аппаратно-зависимые растры 575 return DIBJ2RGB888; else return -1; } switch ( dibinfo.bmiHeader.biBitCount ) { case 1:return DIB_1BPP; case 2: return DIB_2BPP: case 4:return DIB_4BPP; case 8: return DIB_8BPP; case 24: return DIB_24RGB888: case 16: return DIBJ.6RGB555; case 32: return DIB_32RGB888: default: return -1: } } Функции SetDIBits и GetDIBits поддерживают и другой формат растров GDI, о которых речь пойдет в разделе «DIB-секции». В документации (KB Q230499) сказано, что при использовании GetDIBits для преобразования DIB-секций с кодировкой 1 или 4 бит/пиксел в DIB с кодировкой 8 бит/пиксел цветовая таблица DIB настраивается неправильно. Прямой доступ к массиву пикселов DDB Одна из главных особенностей аппаратно-зависимых растров заключается в том, что DDB-растры не имеют цветовой таблицы и могут иметь уникальный внутренний формат пикселов, определяемый производителем оборудования. Единственным стандартным форматом DDB считается монохромный формат. Из-за этого прямой доступ к графическим данным DDB не имеет особого смысла (особенно для цветных DDB-растров). Однако в GDI предусмотрена пара функций, при помощи которых приложение может работать с массивами пикселов DDB: LONG GetBitmapBits(HBITMAP hBmp, LONG cbBuffer, LPVOID IpvBits): LONG SetBitmapBits(HBITMAP hBmp. LONG cBytes, LPVOID IpBits): Функция GetBitmapBits копирует массив пикселов DIB в буфер, заданный параметрами cbBuffer и IpvBits. Но как узнать размер выделяемого буфера? В документации Microsoft не упоминается о том, что функция GetBitmapBits возвращает необходимый размер буфера, если размер равен 0, а указатель на буфер содержит NULL. Массив пикселов копируется без преобразования формата и цвета. Функция SetBitmapBits выполняет обратную операцию: она копирует содержимое буфера в массив пикселов растра. Найти разумное применение для этих двух функций нелегко. Один из возможных вариантов — реализация эффективных алгоритмов работы с DDB без применения совместимых контекстов. Например, вы можете легко реализовать инверсию каждого пиксела, зеркальное отражение и повороты строк развертки. Другое возможное применение — исследование внутреннего формата DDB. Приведенная ниже функция выводит содержимое массива пикселов DDB в текстовом окне (предполагается, что у нас имеется функция вывода шестнадцатерич-
576 Глава 10. Основные сведения о растрах ного дампа HexDump). В системах семейства Windows NT почти все видеоадаптеры используют кадровые буферы с одноплоскостным форматом DIB, поэтому у них массив пикселов DDB достаточно близок к массиву DIB. С другой стороны, в стандартных режимах VGA или в системах семейства Windows 95 формат DDB усложняется. void DumpBitmapCHWND hWnd. HBITMAP hBMP) { int size = GetBitmapBits(hBmp, 0, NULL); BYTE * pBuffer = new BYTE[size]; if ( pBuffer ) { GetBitmapBits(hBmp, size, pBuffer); HexDumpChWnd, pBuffer, size): delete [] pBuffer; } } Использование DDB-растров Аппаратно-зависимые растры широко используются в Windows-программировании. Предыдущий раздел был посвящен разным способам создания DDB и преобразования между DDB, DIB и непосредственным содержимым массива пикселов. В этом разделе рассматривается отображение DDB-растров и их использование в меню, панелях инструментов и т. д. Отображение DDB-растров Хотя DDB-растры играют очень важную роль в Windows-программировании, вы не найдете в GDI функции для непосредственного отображения DIB. Чтобы вывести DIB, приложение должно создать совместимый контекст устройства, выбрать в нем DDB и скопировать данные пикселов из совместимого контекста устройства в приемный контекст. Эта контекстно-ориентированная схема хороша тем, что DDB-растр может быть как источником, так и приемником для операции вывода. Более того, вы даже можете скопировать одну часть DDB в другую часть того же DDB-растра! Для сравнения стоит заметить, что GDI поддерживает только функции, отображающие содержимое DIB, — и ни одной функции для вывода в DIB. В GDI задача отображения DDB решается обобщенно, как задача пересылки прямоугольного массива пикселов с одного графического устройства на другое графическое устройство, каждое из которых представлено манипулятором контекста устройства. Такие операции пересылки традиционно обозначаются сокращением «BitBlt» от слов «Bit boundary Block Transfer»1. B GDI существует две основные функции блиттинга: 1 В русском языке обычно используется термин «блиттинг». — Примеч. перев.
Использование DDB-растров 577 BOOL BitBlKHDC hdcDst. int nXDst. int nYDst. int nWidth, int nHeight, HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop); BOOL BitBltCHDC hdcDst, int nXDst, int nYDst. int nWDst. int nHDst, HDC hdcSrc. int nXSrc. int nYSrc. nWSrc. int nHSrc. DWORD dwRop); Функция BitBlt передает прямоугольный блок пикселов с исходного устройства в прямоугольник приемного устройства. Исходный прямоугольник определяется параметрами nXSrc, nYSrc, nWidth и nHeight в логической системе координат исходного контекста устройства. Приемный прямоугольник определяется параметрами nXDst, nYDst, nWidth pi nHeight в логической системе координат приемного контекста устройства. Оба контекста устройства должны поддерживать растровые операции RCBITBLT. Например, если исходный контекст устройства является метафайловым контекстом, попытка вызова BitBlt завершится неудачей, поскольку метафайловый контекст не имеет кадрового буфера, содержимое которого можно прочитать. GDI также не справляется со случаями, когда в исходном контексте устройства действует преобразование поворота или сдвига, способное превратить исходный прямоугольник в параллелограмм или прямоугольник, стороны которого не параллельны осям. Если исходный и приемный прямоугольники имеют разные размеры в системах координат устройства, исходное изображение масштабируется по размерам приемного многоугольника. В приемном контексте устройства могут действовать любые преобразования, хотя в системах семейства Windows 95 мировые преобразования не поддерживаются. Как и в случае с функцией StretchDIBits, изменение знака в параметрах исходного и приемного прямоугольника позволяет выполнить зеркальное отражение растра по вертикальной и/или горизонтальной оси. Последний параметр dwRop определяет тернарную растровую операцию, то есть способ объединения исходного пиксела, приемного пиксела и кисти для формирования нового значения исходного пиксела. Пока мы ограничимся тернарной операцией SRCC0PY, при которой пикселы приемника попросту заменяются пикселами источника. Функция StretchBlt делает практически то же, что и функция BitBlt. Единственное различие заключается в независимом определении размеров исходного и приемного прямоугольников, поэтому функция StretchBlt обычно используется в ситуациях, когда исходный и приемный прямоугольники имеют разные размеры в логических координатах. Понадобится ли реальное масштабирование или нет — зависит от настройки логических систем координат. Случайная перестановка фрагментов экрана Давайте рассмотрим использование функций BitBlt/StretchBlt на конкретном примере. Мы напишем программу, которая копирует случайно выбранный прямоугольник экрана в другой случайно выбранный прямоугольник. Чтобы изображение выглядело поярче, мы задействуем случайно выбранную растровую операцию с однородной кистью случайно выбранного цвета. Приемный прямоугольник определяется с отрицательной шириной и высотой, поэтому исходный прямоугольник поворачивается на 180°. В результате масштабирования приемный прямоугольник увеличивается вдвое по сравнению с источником. После нескольких итераций экран начинает выглядеть довольно оригинально. Мы не собираемся писать полноценную экранную заставку (screen saver), поэтому код
578 Глава 10. Основные сведения о растрах просто выполняется в цикле 200 раз, а затем программа завершается запросом на перерисовку экрана. int WINAPI WinMain(HINSTANCE hlnst. HINSTANCE. PSTR, int) { HDC hDC = GetDC(NULL); int width = GetSystemMetrics(SM_CXSCREEN); int height = GetSystemMetrics(SM_CYSCREEN); for (int i=0; i<2000; i++) { HBRUSH hBrush = CreateSolidBrush(RGB(rand()*256. rand()*256.rand()a!256)): SelectObject(hDC. hBrush); BOOL rslt = StretchBlt(hDC, randO % width, randO % height, -64, -64, hDC. randO % width, randO % height. 32, 32, (randO % 256) « 16); SelectObject(hDC, GetStockObject(WHITE_BRUSH)): DeleteObject(hBrush); Sleep(l): ReleaseDC(NULL. hDC); RedrawWindow(NULL. NULL, NULL, RDWJNVALIDATE | RDW_ALLCHILDREN); return 0; Различные способы отображения DDB-растров Функции BitBlt и StretchBlt обычно применяются при выводе аппаратно-зави- симых растров. При правильном использовании эти две функции способны создавать разнообразные графические эффекты. В листинге 10.5 приведен простой класс для работы с DDB. Функция KDDB: :Draw позволяет рисовать обычные растры, растры, выровненные по центру и масштабированные по размерам приемника, растры с сохранением пропорций, а также мозаичные растры. Листинг 10.5. class KDDB { protected: HBITMAP mJiBitmap; HBITMAP mJiQldBmp; void ReleaseDDB(void); public: HDC mJiMemDC: bool Preparednt & width, int & height); typedef enum { drawjnormal. draw_center, draw_tile,draw_stretch, draw_stretchprop }; HBITMAP GetBitmap(void) const { return mJiBitmap; }
Использование DDB-растров 579 KDDBO { mJiBitmap = NULL: m_hMemDC = NULL: mJiOldBmp = NULL: } virtual -KDDBO { ReleaseDDBO: } BOOL Attach(HBITMAP hBmp): BOOL LoadBitmap(HINSTANCE hlnst. int id) { return Attach ( ::LoadBitmap(hInst. MAKEINTRESOURCE(id)) ): } BOOL DrawCHDC hDC. int xO. int yO. int w. int h. DWORD гор. int opt=draw_normal): // Запросить размер, подготовить совместимый контекст устройства // и выбрать в нем растр boo! KDDB::Prepare(int & width, int & height) { BITMAP bmp: if ( ! GetObject(m_hBitmap. sizeof(bmp). & bmp) ) return false: width = bmp.bmWidth; height = bmp.bmHeight; if ( m_hMemDC==NULL ) // Убедиться в том. что создание { // растра прошло успешно HDC hDC = GetDC(NULL): mJiMemDC = CreateCompatibleDC(hDC); ReleaseDCCNULL. hDC): m_h01dBmp = (HBITMAP) SelectObject(m_hMemDC. mJiBitmap): } return true: // Освобождение ресурсов void KDDB::ReleaseDDB(void) { if ( mJiMemDC ) { SelectObject(m_hMemDC. mJiOldBmp): DeleteObject(m_hMemDC): mJiMemDC = NULL: } Продолжение ^
580 Глава 10. Основные сведения о растрах Листинг 10.5. Продолжение if ( mJiBitmap ) { DeleteObject(m_hBitmap); mJiBitmap = NULL: } mJiOldBmp = NULL; BOOL KDDB::Attach(HBITMAP hBmp) { if ( hBmp==NULL ) return FALSE; if ( m_h01dBmp ) // Исключить mJiBitmap { SelectObject(m_hMemDC. m_h01dBmp); mJiOldBmp = NULL; } if ( mJiBitmap ) // Удалить текущий растр DeleteObject(mJiBitmap); m_hBitmap = hBmp; // Заменить новым растром if ( mJiMemDC ) // Выбрать в совместимом контексте устройства. { // если он есть mJiOldBmp = (HBITMAP) SelectObject(m_hMemDC. mJiBitmap): return mJiOldBmp != NULL; } else return TRUE; } BOOL KDDB::Draw(HDC hDC, int xO. int yO. int w. int h. DWORD гор. int opt) { int bmpwidth. bmpheight; if ( ! Prepare(bmpwidth. bmpheight) ) return FALSE; switch ( opt ) { case drawjiormal: return BitBlt(hDC. xO. yO. bmpwidth. bmpheight. mJiMemDC. 0. 0. гор); case draw_center: return BitBltChDC. xO + (w-bmpwidth)/2. yO + ( h-bmpheight)/2. bmpwidth. bmpheight. mJiMemDC. 0. 0. гор); break: case draw_tile: {
Использование DDB-растров 581 for (int j=0; j<h; j+= bmpheight) for (int i=0; i<w; i+= bmpwidth) if ( ! BitBltChDC. xO+i. yO+j. bmpwidth. bmpheight, m_hMemDC, 0. О, гор) ) return FALSE; return TRUE; } break; case draw_stretch; return StretchBlt(hDC. xO. yO, w. h. mJiMemDC. 0, 0, bmpwidth, bmpheight. гор); case draw_stretchprop: { int ww = w; int hh = h; if ( w * bmpheight < h * bmpwidth ) // Выбор оси hh = bmpheight * w / bmpwidth; // для масштабирования else ww = bmpwidth * h / bmpheight; // Пропорциональные масштабирование и центровка return StretchBlt(hDC, xO + (w-ww)/2. yO + (h-hh)/2. ww. hh. m_hMemDC. 0. 0. bmpwidth. bmpheight. гор); } default: return FALSE; } } Класс KDDB содержит три переменные: манипулятор совместимого контекста устройства и два манипулятора HBITMAP для нового DDB-растра и для старого DDB-растра, исключаемого из совместимого контекста. DDB-растры чаще всего создаются загрузкой из ресурсов. Экземпляры класса KDDB следует размещать вне обработчика сообщения WMPAINT, чтобы свести к минимуму затраты на преобразование ресурса из формата DIB в DDB и на создание совместимого контекста устройства. В методе KDDB:: Draw поддерживаются различные варианты рисования растра, определяемые последним параметром. В приведенной версии реализованы нормальный вывод, центровка, мозаичная раскладка, простое и пропорциональное масштабирование. В пользовательском интерфейсе растры все чаще используются для оформления заставочных окон (splash screens) и фона. Для небольших текстур часто применяется мозаичное повторение; растры, изображающие самостоятельные объекты, часто выводятся с центровкой и пропорциональным масштабированием. Сохранение окна/экрана После того как DDB-растр будет выбран в совместимом контексте устройства, вы можете выполнять с ним различные операции с помощью функций GDI.
582 Глава 10. Основные сведения о растрах Простейшей операцией является сохранение содержимого окна, и как частный случай — сохранение всего экрана. Задача решается приведенной ниже функцией CaptureWindow. HBITMAP CaptureWindow(HWND hWnd) { RECT wnd; if ( ! GetWindowRectChWnd. & wnd) ) return NULL; HDC hDC = GetWindowDC(hWnd); HBITMAP hBmp = CreateCompatibleBitmap(hDC, wnd.right-wnd.left, wnd.bottom - wnd.top); if (hBmp) { HDC hMemDC = CreateCompatibleDC(hDC); HGDIOBJ hOld = SelectObject(hMemDC. hBmp): BitBlt(hMemDC. 0. 0, wnd.right - wnd.left. wnd.bottom - wnd.top. hDC. 0. 0. SRCCOPY): SelectObject(hMemDC. hOld); DeleteObject(hMemDC); } ReleaseDC(hWnd. hDC); return hBmp; } Функция CaptureWindow возвращает манипулятор DDB, который затем можно преобразовать в DIB, сохранить в дисковом файле или скопировать в буфер обмена. Преобразование цветов DDB Два контекста устройств, исходный и приемный, могут иметь разный формат кадрового буфера или характеристики палитры. Например, монохромный исходный растр может копироваться на приемную поверхность с 32-разрядной кодировкой цвета, или наоборот — исходное изображение в формате True Color может копироваться на монохромную поверхность. В этом случае функция BitBlt/ StretchBlt преобразует пикселы из цветового формата источника к формату приемника. Если один из контекстов устройств является совместимым контекстом с выбранным DDB-растром, несовпадение возможно лишь в том случае, если один из контекстов является монохромным. Например, для экрана в режиме с 24-разрядным цветом совместимый контекст устройства обычно создается в соответствующем цветовом формате. Функции LoadBitmap и CreateCompatibleBitmap генерируют только 24-разрядные или монохромные растры. GDI позволяет выбрать в контексте устройства только 24-разрядный или монохромный DDB-растр. Если приложение создает растр с 8-разрядным цветом, создание растра пройдет
Использование DDB-растров 583 успешно, но попытка выбрать его в контексте устройства, совместимом с экраном, завершится неудачей. При выводе монохромного растра на цветной поверхности GDI не ограничивается простым отображением черного и белого цвета; вместо этого GDI позволяет раскрасить растр с использованием атрибутов основного и фонового цвета контекста устройства. По умолчанию фоновым цветом контекста устройства является белый цвет, а основным цветом (цветом текста) — черный, но вместо них можно выбрать любые другие цвета функциями SetBkColor и SetTextCol or. В монохромном растре значения пикселов равны 0 и 1. Считается, что пикселы со значением 0 относятся к основному цвету, а пикселы со значением 1 — к фоновому. При выводе пикселов основного цвета (0) GDI использует основной цвет приемного контекста устройства, а при выводе пикселов фонового цвета (1) — фоновый цвет приемного контекста. В следующем фрагменте показано, как создать мозаичную раскладку с использованием разных основных и фоновых цветов. const C0L0RREF ColorTable[] = { RGBCOxFF. 0. 0). RGB(0. OxFF. 0). RGB(0. 0. OxFF). RGB(0xFF, OxFF, 0). RGB(0. OxFF. OxFF). RGB(OxFF. 0. OxFF) }: for (int y=0: y<clientheight; y+= bmpheight ) for (int x=0: x<clientwidth; x+= bmpwidth ) { SetTextColor(hDC. ColorTable[y/bmpheight]); SetBkColor(hDC. ColorTable[x/bmpwidth] | RGB(0xC0, OxCO. 0xC0)); BitBlt(hDC. x. y. bmpwidth. bmpheight. hMemDC. 0. 0. SRCCOPY): } При выводе цветного растра в монохромном контексте устройства каждому цветному пикселу необходимо поставить в соответствие либо 0, либо 1. Мы знаем, что при выводе DIB в монохромном контексте устройства GDI пытается подобрать для каждого пиксела ближайший цвет, однако при выводе DDB интерфейс GDI действует совершенно иначе. Цвет каждого пиксела сравнивается с фоновым цветом исходного контекста устройства. Значения пикселов, совпадающих с фоновым цветом, преобразуются в 1 (белый), а остальные пикселы преобразуются в 0 (черный). Обратите внимание: в процессе преобразования учитывается только фоновый цвет, а основной цвет не используется. Этот на первый взгляд «наивный» способ преобразования цветных растров в монохромные на самом деле оказывается очень полезным. Он обеспечивает простые средства для деления пикселов растра на фоновые и не относящиеся к фону; сгенерированный при этом растр может использоваться в качестве маски. Маска может пригодиться в тернарных растровых операциях для отображения растров с прозрачными участками (спрайтов). Подробное описание вывода прозрачных растров вы найдете в главе 11. Ниже приведена новая функция класса KDDB, которая генерирует монохромный растр по заданному цвету фона. Функция CreateMask использует вызов Create- Bitmap для создания монохромного растра, устанавливает заданный цвет в качестве фонового в исходном совместимом контексте устройства, после чего преобразует цветной растр в монохромный функцией BitBlt.
584 Глава 10. Основные сведения о растрах HBITMAP KDDB::CreateMaskCCOLORREF crBackGround. HDC hMaskDC) { int width, height; if ( ! Prepare(width, height) ) return NULL; HBITMAP hMask - CreateBitmap(width, height, 1. 1. NULL); HBITMAP hOld = (HBITMAP) SelectObject(hMaskDC, hMask); SetBkColor(m_hMemDC, crBackGround); BitBltChMaskDC, 0. 0, width, height. mJiMemDC. 0, 0, SRCCOPY); return hOld: } На рис. 10.3 изображены 9 масок, созданных функцией KDDB: :CreateMask для каждого из цветов, задействованных в цветном изображении. На первом месте показан цветной растр, а затем следуют монохромные маски. При отображении масок используется основной и фоновый цвет по умолчанию; 1 соответствует белому цвету, а 0 — черному. Рис. 10.3. Разложение цветного DDB-растра на монохромные маски Использование растров в меню В программировании для Windows с каждой командой меню можно связать два маленьких растра. Эти растры выводятся рядом с командой; первый — когда команда активизирована (checked), а второй — когда команда пассивна (unchecked). По умолчанию Windows не выводит растры для пассивных команд, а активные команды помечаются стандартным растровым рисунком в виде «галочки». Впрочем, эти растры вовсе не обязаны соответствовать активному или пассивному состоянию команды. Скажем, маленький значок в виде принтера рядом с командой Print определенно делает меню более наглядным. Для изменения этих растров-меток используются функции SetMenuItemBitmaps и SetMenuItemlnfo. Хотя сами по себе эти функции просты, с подготовкой и обработкой растров дело обстоит сложнее. Чтобы растр сливался с фоном меню, фо-
Использование DDB-растров 585 новые пикселы растра должны быть окрашены в фоновый цвет меню. Кроме того, растры необходимо масштабировать по высоте команд меню. Растр, манипулятор которого передается функциям SetMenuItemBitmap и SetMenuItemlnfo, нельзя удалять до тех пор, пока меню не перестает использоваться. В листинге 10.6 приведен класс для работы с растрами-метками команд меню. Листинг 10.6. Использование растров в качестве меток для команд меню class KCheckMark { protected: typedef enum { MAXSUBIMAGES = 50 }; HBITMAP mJiBmp; int m_nSubImageId[MAXSUBIMAGES]; HBITMAP mJiSublmage [MAXSUBIMAGES]; int mjiUsed; public: KCheckMark () { m_hBmp = NULL; m nUsed = 0; -KCheckMarkO: void AddBitmapdnt id. HBITMAP hBmp); void LoadToo1bar(HMODULE hModule. int resid, bool transparent=false); HBITMAP GetSubImage(int id); BOOL SetCheckMarks(HMENU hMenu, UINT uPos. UINT uFlags, int unchecked, int checked); void KCheckMark::AddBitmap(int id. HBITMAP hBmp) { if ( m_nUsed < MAXSUBIMAGES ) { m_nSubImageId[m_nUsed] = id; mJiSublmage [m_nUsed++] = hBmp; } } void KCheckMark::LoadToolbar(HMODULE hModule. int resid. bool transparent) { mJiBmp - (HBITMAP) ::LoadImage(hModule. MAKEINTRES0URCE(resid). IMAGE_BITMAP. 0. 0. transparent ? LRJ.0ADTRANSPARENT ; 0); AddBitmap((int) hModule + resid. mJiBmp); KCheckMark:-KCheckMarkO Продолжение ё>
586 Глава 10. Основные сведения о растрах Листинг 10.6. Продолжение { for (int i=0: i<m_nUsed; i++) DeleteObject(m_hSubImage[i]); } HBITMAP KCheckMark::GetSubImage(int id) { if ( id < 0 ) return NULL; for (int i=0: i<m_nUsed; i++) if ( m_nSubImageId[i]==id ) return m_hSubImage[i]; BITMAP bmp; if ( ! GetObject(m_hBmp. sizeof(bmp). & bmp) ) return NULL; if ( id *bmp.bmHeight >= bmp.bmWidth ) return NULL; HDC hMemDCS = CreateCompatibleDC(NULL); HDC hMemDCD - CreateCompatibleDC(NULL); SelectObject(hMemDCS. m_hBmp); int w - GetSystemMetrics(SM_CXMENUCHECK); int h = GetSystemMetrics(SM_CYMENUCHECK); HBITMAP hRslt = CreateCompatibleBitmap(hMemDCS. w. h); if ( hRslt ) { HGDIOBJ hOld = SelectObject(hMemDCD. hRslt); StretchBltChMemDCD, 0. 0. w. h. hMemDCS. id*bmp.bmHeight. 0. bmp.bmHeight, bmp.bmHeight. SRCCOPY); SelectObject(hMemDCD. hOld); AddBitmap(id. hRslt); } DeleteObject(hMemDCS); DeleteObject(hMemDCD); return hRslt; } BOOL KCheckMark::SetCheckMarks(HMENU hMenu. UINT uPos. UINT uFlags. int unchecked, int checked) { return SetMenuItemBitmaps(hMenu. uPos. uFlags. GetSublmage(unchecked). GetSublmage(checked)); }
Использование DDB-растров 587 Класс KCheckMark загружает один растровый рисунок, состоящий из нескольких растров меньшего размера, расположенных рядом (наподобие растров, используемых при работе с панелями инструментов). Растр загружается функцией Loadlmage, которая обеспечивает замену фоновых пикселов стандартным цветом окна (C0L0R_WIND0W) при помощи флага LRJ.OADTRANSPARENT. Цвет окна по умолчанию обычно совпадает с фоновым цветом меню, и это помогает нам решить проблему слияния растра с фоном меню. Большая часть полезной работы в этом классе выполняется функцией GetSublmage, которая «вырезает» из растра небольшой фрагмент. Предполагается, что фрагменты расположены в одну строку, поэтому их размеры вычисляются по высоте общего растра. Функция получает размеры растров, используемых в качестве меток для команд меню, и масштабирует по ним фрагменты. Идентификатор и манипулятор растра-фрагмента сохраняются в таблице, чтобы их можно было задействовать в будущем. Выбор новых меток вместо назначенных ранее или используемых по умолчанию выполняет функция SetMenuImageltems. Поскольку операционная система Windows не создает копий растров, таблица манипуляторов используется в деструкторе класса для удаления растровых объектов. Экземпляры класса KCheckMark должны существовать на уровне окна или приложения, чтобы их деструкторы вызывались лишь тогда, когда растр перестает использоваться. На рис. 10.4 изображен результат применения растров для оформления некоторых стандартных команд меню. Исходный растр загружен из модуля browserui.dll, идентификатор ресурса 275. * frask | ФНттй %Ы ЦСору | paBedo QNew фОреп SSave fj|PjintePr&vtew jgfPmpeifes ИГНФ *,'''' 'фЩфт*. ' ''."// Рис. 10.4. Оформление стандартных команд меню растровыми метками
588 Глава 10. Основные сведения о растрах Растры также позволяют заменить обычный текст в командах в меню. Для этой цели используются функции AppendMenu, InsertMenuItem и SetMenuItemlnfo. В следующей программе показано, как создать подменю с растровыми командами. void KBitmapMenu::AddToMenu(HMENU hMenu. int nCount, HMODULE hModule, const int nID[]. int nFirstCommand) { m_hMenu = hMenu; mjiBitmap = nCount; mjiChecked = 0; mjiFirstCommand = nFirstCommand; for (int i=0; i<nCount; i++) { m_hBitmap[i] = LoadBitmap(hModule. MAKEINTRESOURCE(nID[i])); if ( m_hBitmap[i] ) AppendMenu(hMenu, MF_BITMAP, nFirstCommand + i, (LPCTSTR) m_hBitmap[i]); CheckMenuItem(m_hMenu, m_nChecked + nFirstCommand. MF_BYC0MMAND | MF_CHECKED); } На рис. 10.5 изображено растровое меню с вариантами текстур и окно, заполненное выбранной текстурой с помощью функции KDDB: :Draw. File Color View Window Oieqk Matk* j Textyres Шй j г —_ ^| i ,i i.-i..i i.i i rr i:.'i.:г.. :r y~r ыш- *'*3£*§ 'ь'-'Л', З&Ф'' - .ffl.lgjxlj I ] 1 pi- I pl„ j rV pr Li "41 Рис. 10.5. Меню с растровыми командами
Использование DDB-растров 589 В Win32 API применение растров в меню должно подчиняться некоторым ограничениям. Например, в экранном режиме с 256 цветами цветопередача растров-меток с большим количеством цветов искажается. Размер меток обычно ограничивается величиной 13 х 13 пикселов, что меньше растров 16 х 16 или 20 х 20, используемых на панелях инструментов. Многим также не нравится то, как система выделяет команды меню. Если вы хотите в полной мере управлять отображением растров в меню: воспользуйтесь меню, прорисовка которых выполняется владельцем (owner-drawn). Впрочем, эта тема выходит за рамки настоящей книги. Использование растра в качестве фона окна При работе с растрами часто возникает вопрос — как вывести растр в качестве фона окна (например, клиентского окна MDI, диалогового окна, страницы свойств или статического элемента управления)? Операции с фоном окна в Windows обычно выполняются при обработке сообщения WM_ERASEBKGND. Обработчик этого сообщения может нарисовать в фоне окна все, что сочтет нужным. Если сообщение не обработано, стандартный обработчик закрашивает фон фоновой кистью, указанной в определении класса окна. Итак, ключевой проблемой является обработка сообщения WM_ERASEBKGND. Как правило, обработчики сообщений для клиентских окон MDI, диалоговых окон, страниц свойств и статических элементов управления не предоставляются приложением, а реализуются операционной системой в модуле user32.dll или commctrl.dll. Следовательно, для вмешательства в процесс прорисовки фона придется воспользоваться методикой субклассирования. Главное — правильно установить перехватчик (hook), а вывод растра — задача несложная. В листинге 10.7 приведен родовой класс, обеспечивающий нестандартную прорисовку фона путем субклассирования. Листинг 10.7. Родовой класс прорисовки фона class KBackground { WNDPROC m_01dProc; virtual LRESULT EraseBackground(HWND hWnd, UINT uMsg. WPARAM wParam, LPARAM lParam); virtual LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM lParam); static LRESULT CALLBACK BackGroundWindowProc(HWND hWnd. UINT uMsg, WPARAM wParam. LPARAM lParam); public: KBackgroundO { m_01dProc = NULL; } virtual -KBackgroundO Продолжение &
590 Глава 10. Основные сведения о растрах Листинг 10.7. Продолжение { } BOOL Attach(HWND hWnd): BOOL Detatch(HWND hWnd); // Реализация KBackground const TCHAR Prop_KBackground[] - J("KBackground Instance"): LRESULT KBackground::EraseBackground(HWND hWnd. UINT uMsg, WPARAM wParam, LPARAM IParam) { return DefWindowProc(hWnd. uMsg. wParam, IParam); } LRESULT KBackground::WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM IParam) { if ( uMsg - WMJRASEBKGND ) return EraseBackgroundChWnd, uMsg. wParam, IParam); else return CaHWindowProc(m_01dProc, hWnd. uMsg. wParam, IParam); } LRESULT KBackground::BackGroundWindowProc(HWND hWnd. UINT uMsg, WPARAM wParam, LPARAM IParam) { KBackground * pThis - (KBackground *) GetProp(hWnd, Prop_KBackground): if ( pThis ) return pThis->WndProc(hWnd, uMsg, wParam, IParam); else return DefWindowProc(hWnd. uMsg. wParam. IParam); BOOL KBackground::Attach(HWND hWnd) { SetProp(hWnd, Prop_KBackground, this); m_01dProc - (WNDPROC) SetWindowLong(hWnd. GWL_WNDPROC, (LONG) BackGroundWindowProc); return m 01dProc!=NULL; BOOL KBackground::Detatch(HWND hWnd) { RemoveProp(hWnd, Prop_KBackground); if ( m_01dProc ) return SetWindowLong(hWnd, GWL_WNDPROC. (LONG) m_01dProc) — (LONG) BackGroundWindowProc; else return FALSE; }
Использование DDB-растров 591 В классе KBackground определяются два виртуальных метода (не считая виртуального деструктора). Метод EraseBackground рисует фон окна; реализация по умолчанию просто вызывает DefWindowProc. Метод WndProc обрабатывает все сообщения, хотя в данном случае нас интересует только сообщение WM_ERASEBKGND. Субклассирование существующего окна выполняется вызовом метода Attach. С окном ассоциируется свойство, значение которого представляет собой указатель на экземпляр класса KBackground, а функция окна переопределяется статической функцией BackGroundWindowProc. Получив сообщение, эта функция запрашивает значение свойства, чтобы получить указатель this для экземпляра KBackground, а затем передает вызов его методу WndProc. Обратите внимание — мы не можем сохранить указатель this в поле GWLJJSERDATA, как в классе KWindow, поскольку субклассируемое окно может быть создано другой стороной, использующей поле GWLJJSERDATA. He годятся и глобальные переменные, поскольку мы хотим использовать наш класс для одновременной поддержки нескольких окон, но при этом обойтись без создания глобальных диспетчерских таблиц, как в MFC. Класс KBackground решает общую задачу субклассирования и перехвата сообщения WM_ERASEBKGND. Однако существуют различные варианты прорисовки фона — линиями, образующими решетчатый узор, заливкой замкнутых областей, функциями вывода DIB или DDB. Эти варианты реализуются в специализированных классах, производных от родового класса KBackground. Реализация, ориентированная на вывод DDB, приведена в листинге 10.8. Листинг 10.8. Класс для прорисовки фона выводом DDB class KDDBBackground : public KBackground { KDDB m_DDB; int mjiStyle: virtual LRESULT EraseBackgroundCHWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); public: KDDBBackgroundO mjiStyle = KDDB::draw_tile; void SetStyleCint style) mjnStyle = style; void SetBitmapCHMODULE hModule. int nRes) m_DDB.LoadBitmap(hModule, nRes); }: LRESULT KDDBBackground::EraseBackgroundCHWND hWnd. UINT uMsg, WPARAM wParam, LPARAM 1 Param) { Продолжение &
592 Глава 10. Основные сведения о растрах Листинг 10.8. Продолжение if ( m_DDB.GetBitmap() ) { RECT rect; HDC hDC - (HDC) wParam; GetClientRectChWnd. & rect); HRGN hRgn = CreateRectRgnIndirect(&rect); SaveDC(hDC); SelectClipRgn(hDC, hRgn); DeleteObject(hRgn); m_DDB.Draw(hDC. rect.left. rect.top. rect.right - rect.left. rect.bottom - rect.top. SRCCOPY. mjiStyle): RestoreDC(hDC. -1): return 1; // Обработано } else return DefWindowProc(hWnd. uMsg. wParam. IParam); } Для загрузки и вывода DDB класс KDDBBackground использует класс KDDB. Он переопределяет метод EraseBackground и реализует в нем вывод фона. Использовать этот класс несложно. Все, что от вас потребуется, — создать экземпляр класса KDDBBackground, задать растр и стиль вывода, а затем субклассировать окно вызовом метода Attach. На рис. 10.6 показаны результаты субклассирования для диалогового окна, группирующей рамки и статической рамки (frame). Диалоговбе окно заполняется деревянной текстурой, в группирующей рамке кирпичная текстура выравнивается по центру, а в статической рамке та же текстура подвергается пропорциональному масштабированию. А самое замечательное — то, что для каждого окна задача решается всего тремя строками кода при обработке сообщения WMJNITDIAL0G. // KDDBBackground whole; // KDDBBackground groupbox; // KDDBBackground frame; whole.SetBitmap(m_hInstance. IDB_PAPER01); whole.SetStyle(KDDB::draw_tile): whole.Attach(hwnd); groupbox.SetBitmap(m_hInstance. IDB_BRICK02); groupbox.SetStyleCKDDB::draw_center); groupbox.Attach(GetDlgItem(hWnd. IDC_GR0UPB0X)); frame.SetBitmap(m_hInstance. IDB_BRICK02); frame.SetStyle(KDDB::draw_stretchprop); frame.Attach(GetDlgItem(hWnd. IDCJRAME));
Использование DDB-растров 593 Рис. 10.6. Использование класса KDDBBackground в диалоговом окне DIB-секции Мы рассмотрели два основных растровых формата, поддерживаемых в GDI: ап- паратно-независимые растры (DIB) и аппаратно-зависимые растры (DDB). DIB- растры могут существовать в различных стандартных цветовых форматах, выбор которых зависит от ситуации. DDB-растры по практическим соображениям либо являются монохромными, либо их цветовой формат совпадает с форматом устройства. Средства GDI позволяют выводить как DIB, так и DDB, однако GDI поддерживает рисование только на DDB-растре, выбранном в совместимом контексте устройства, и не поддерживает рисование на DIB. DIB-растры хороши тем, что их хранение организуется на уровне приложения, поэтому приложение может напрямую работать с цветовой таблицей и массивом пикселов, однако рассчитывать на помощь GDI в создании DIB не приходится. Преимущества DDB-растров — в том, что в них можно рисовать средствами GDI; с другой стороны, вы не имеете прямого доступа к внутреннему представлению DDB, поскольку оно находится под управлением GDI. Поскольку DDB-растры хранятся в системной памяти, существуют ограничения как для максимального размера одного DDB-растра, так и для общего размера всех DDB-растров в системе. С другой стороны, хранение DIB организуется приложением, поэтому размер DIB ограничивается только объемом виртуального адресного пространства процесса и свободным пространством на диске, выделенным для системного файла подкачки. Возникает естественный вопрос: существует ли тип растров, обладающий всеми достоинствами DIB и DDB? Да, существует. Это новый тип растров, поддерживаемый в Win32 GDI API — DIB-секции (DIB sections). Термин «DIB-секция» выглядит довольно странно. Вероятно, программист, работавший над реализацией, не удосужился подобрать нормальное имя, а специалисты по подготовке документации вообще не представляли, о чем идет речь. В документации Microsoft DIB-секция определяется как DIB-растр, в который приложение может напрямую записывать данные. Но приложения еще со времен Windows 3.1 напрямую записывают данные в DIB и без DIB-секций. Также
594 Глава 10. Основные сведения о растрах в документации утверждается, будто DIB-секция является частью DIB, но на самом деле DIB-секция всегда содержит полный DIB-растр. Во избежание дальнейших недоразумений стоит привести нормальное определение. DIB-секцией называется DIB-растр, обеспечивающий непосредственное чтение/запись со стороны как приложения, так и GDI. Вы спросите, при чем здесь «секция»? Дело в том, что массив пикселов DIB-секции может храниться в файле, отображаемом на память, который в среде разработчиков операционной системы Windows называется «секцией». Даже если DIB-секция и не находится в файле, отображаемом на память, ее массив пикселов хранится в виртуальной памяти, которая может выгружаться в системный файл подкачки. Вероятно, DIB- секции правильнее было бы назвать «DIB-растрами с двойным доступом» (dual access DIB). DIB-секция, как и аппаратно-зависимый растр, является объектом GDI. При создании DIB-секции GDI возвращает манипулятор объекта DIB-секции, относящийся к знакомому типу HBITMAP. Но в отличие от DDB, GDI также возвращает адрес массива пикселов DIB-секции, чтобы приложение могло напрямую работать с графическими данными. Завершив работу с DIB-секцией, приложение должно вызвать функцию DeleteObject, чтобы освободить связанные с ней ресурсы. При работе с DIB-секциями используются те же функции API, как и при работе с DDB, поэтому для поддержки DIB-секций на уровне API появились всего три новые функции: HBITMAP CreateDIBSection(HDC hDC, CONST BITMAPINFO *pbmi, UINT iUsage. PVOID * ppvBits, HANDLE hSection, DWORD dwOffset); UINT GetDIBColorTableCHDC hDC, UINT uStartlndex. UINT cEntries. RGBQUAD * pColors): UINT SetDIBColorTableCHDC hDC. UINT uStartlndex, UINT cEntries, CONST RGBQUAD * pColors): typedef struct tabDIBSection { BITMAP dsBm: BITMAPINFOHEADER dsBmih; DWORD dsBitfields[3]; HANDLE dshSection; DWORD dsOffset; } DIBSECTION; CreateDIBSection Функция CreateDIBSection создает объект DIB-секции. Из параметров этой функции самыми важными являются первые три. В первом параметре передается указатель на эталонный контекст устройства. Параметр pbmi указывает на структуру BITMAPINFO, содержащую манипулятор блока описания растра, битовые маски и цветовую таблицу. Параметр i Usage сообщает, содержит ли цветовая таблица значения в формате RGB или индексы палитры. Если значение равно DIB_PAL_ COLORS, используется логическая палитра, в данный момент выбранная в hdc. Итак, первые три параметра полностью определяют размеры, формат пикселов и цветовую таблицу DIB-секции. Четвертый параметр, ppvBits, содержит адрес пере- ш шюй-указателя, в которую GDI заносит адрес массива пикселов DIB-секции.
Использование DDB-растров 595 Два последних параметра обеспечивают выделение памяти и инициализацию массива пикселов при помощи блока из объекта файла, отображаемого на память. Параметр hSection содержит манипулятор объекта файла, отображаемого на память, полученный при вызове CreateFileMapping. Обратите внимание на имя параметра: как говорилось выше, объект файла, отображаемого на память, также называется «объектом секции». Вероятно, это и стало одной из причин появления странного термина «DIB-секция». В параметре dwOffset передается смещение массива пикселов внутри отображаемого файла. Функция CreateDIBSection возвращает два значения — манипулятор объекта DIB-секции (возвращаемое значение функции) и указатель на массив пикселов (параметр ppvBits). Хотя параметры функции CreateDIBSection выглядят довольно сложно, основное внимание в приложениях обычно уделяется второму параметру — указателю на структуру BITMAPINFO. Иначе говоря, для создания DIB-секции вы должны указать ширину, высоту, количество бит/пиксел, тип сжатия, битовые маски и цветовую таблицу. GDI не поддерживает для DIB-секций все допустимые форматы DIB, поскольку DIB-секция должна быть доступна как для чтения, так и для записи (вывода). По этой причине GDI поддерживает для DIB-секций лишь формат DIB без сжатия. Невозможно создать DIB-секцию с типом сжатия BIJU.E4, BI__RLE8, BI__PNG или BIJPEG. Для управления DIB-секцией GDI выделяет блок памяти, в котором хранятся заголовок блока описания растра, битовые маски и цветовая таблица. Эти данные находятся под управлением GDI, и приложение не может работать с ними напрямую. Разумеется, GDI резервирует в таблице объектов GDI элемент, связывающий внутреннюю структуру данных GDI с DIB-секцией. Между манипулятором объекта GDI и записью таблицы объектов GDI существует однозначное соответствие. В этом отношении DIB-секции похожи на DDB-растры, но отличаются от DIB-растров, которые не находятся под управлением GDI. Если DIB-секция создается не в объекте файла, отображаемого на память, GDI выделяет память под массив пикселов из виртуальной памяти приложения и возвращает указатель на нее вызывающей стороне. Обратите внимание на различия в схемах выделения памяти для DDB-растров и DIB-секций. В системах семейства Windows 9x память для массива пикселов DDB выделяется из кучи GDI, а в системах семейства Windows NT — из выгружаемого пула режима ядра. В обоих случаях используются общесистемные ограниченные ресурсы и приложение не имеет прямого доступа к массиву пикселов. С другой стороны, массив пикселов DIB-секции создается в виртуальном пространстве памяти текущего приложения, объем которого ограничивается только объемом виртуальной памяти приложений и свободным местом на диске, причем прикладные программы могут напрямую обращаться к этой памяти. Пикселы в выделенном массиве находятся в неопределенном состоянии, как в неинициализированном DDB- растре. Также следует обратить внимание на то, что память выделяется из виртуального пространства приложения, а не из системной кучи. Хотя системная куча создается в виртуальном адресном пространстве, при работе с ней используется механизм вторичного выделения памяти, повышающий эффективность создания большого количества мелких объектов. Память в виртуальном пространстве выделяется блоками, размер которых кратен размеру страницы; на процессорах
596 Глава 10. Основные сведения о растрах Intel эта величина равна 4 Кбайт. Как показали эксперименты, GDI выделяет память для DIB-секций 64-килобайтными блоками. При передаче действительного манипулятора объекта файла, отображаемого на память, параметр dwOffset должен быть кратен DWORD. По данным структуры BITMAPINFO GDI может вычислить размер массива пикселов. Зная манипулятор объекта отображаемого файла, смещение и длину, GDI может вызвать функцию MapViewOfFIle для отображения блока данных файла на виртуальное пространство приложения. Если данные в файле соответствуют формату массива пикселов, DIB-секция полностью инициализируется без выделения памяти под массив пикселов и копирования данных, связанного с потенциальными затратами. Напрашивается предположение, что DIB-секцию можно создать на основе BMP-файла, отображенного на память. К сожалению, данная возможность не поддерживается, поскольку функции CreateDIBSection должен передаваться указатель на блок памяти, выровненный по границе DWORD. Размер структуры BITMAPFILEHEADER равен 14 байтам, а размер структуры BITMAPINFO всегда кратен DWORD; таким образом, массив пикселов в BMP-файле не всегда выровнен по границе DWORD. Если формат файла, отображенного на память, не соответствует формату массива пикселов, последние два параметра всего лишь обеспечивают альтернативное средство управления памятью. Зачем Microsoft предоставляет такую возможность? Ведь каждый байт памяти все равно хранится на диске — если не в файле, указанном приложением, то в системном файле подкачки? Передавая функции CreateDIBSection объект файла, отображаемого на память, приложение может указать, где должен храниться этот файл и допускается ли его совместное использование несколькими процессами. Допустим, на вашем компьютере системный файл подкачки хранится на жестком диске С:, на котором имеется всего 100 Мбайт свободного места. Графический редактор обрабатывает изображение с 32-разрядным цветом, разрешением 600 dpi и размером в полную страницу; для этого он должен создать 128-мегабайтную DIB-секцию. Если редактор достаточно сообразителен, он увидит, что на жестком диске D: имеется 500 Мбайт свободного места, поэтому отображаемый файл следует создать на диске D: и передать его при вызове CreateDIBSection. Теперь редактор справится с четырьмя большими изображениями. Класс для работы с DIB-секциями Для удобства работы с DIB-секциями их стоит оформить в виде отдельного класса. К счастью, большую часть кода можно позаимствовать из классов KDIB и KDDB (более того, наш класс DIB-секции будет создан как производный от этих классов). Класс для работы с DIB-секциями приведен в листинге 10.9. Листинг 10.9. Класс для работы с DIB-секциями class KDIBSection : public KDIB, public KDDB { public: KDIBSectionO {
Использование DDB-растров 597 } virtual -KDIBSectionO { } BOOL CreateDIBSection(HDC hDC, CONST BITMAPINFO * pBMI. UINT iUsage, HANDLE hSection. DWORD dwOffset); UINT GetColorTable(void); UINT SetColorTable(void); void DecodeDIBSectionFormatCTCHAR desp[]); void KDIBSection::DecodeDIBSectionFormat(TCHAR desp[]) { DIBSECTION dibsec; if ( GetObjectCmJiBitmap. sizeof(DIBSECTION). & dibsec) ) { KDIB::DecodeDIBFormat(desp); _tcscat(desp. _T(" ")); DecodeDDB(GetBitmap(). desp + _tcslen(desp)); } else _tcscpy(desp. _T("Invalid DIB Section")); } BOOL KDIBSection::CreateDIBSection(HDC hDC. CONST BITMAPINFO * pBMI. UINT iUsage. HANDLE hSection. DWORD dwOffset) { PVOID pBits = NULL; HBITMAP hBmp - ::CreateDIBSection(hDC. pBMI. iUsage. & pBits. hSection. dwOffset); if ( hBmp ) { ReleaseDDBO; // Освободить предыдущий объект ReleaseDIBO; mJiBitmap = hBmp; int nColor = GetDIBColorCount(pBMI->bmiHeader); int nSize = sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * nColor; BITMAPINFO * pDIB = (BITMAPINFO *) new BYTE[nS1ze]: if ( pDIB==NULL ) return FALSE; memcpy(pDIB. pBMI. nSize); // Скопировать заголовок // и цветовую таблицу AttachDIB(pDIB. (PBYTE) pBits. DIB_BMI_NEEDFREE); Продолжение^
598 Глава 10. Основные сведения о растрах Листинг 10.9. Продолжение GetColorTableO: return TRUE; } else return FALSE; } Класс KDIBSection не содержит ни одной собственной переменной, поскольку он использует переменные классов KDDB и KDIB. Экземпляр класса KDIBSection обладает возможностями как экземпляра класса KDDB, так и экземпляра KDIB. Таким образом, в инициализированной DIB-секции можно рисовать средствами GDI, используя методы класса KDDB, и напрямую работать с ее массивом пикселов методами класса KDIB. Основной код этого класса сосредоточен в функции CreateDIBSection, создающей DIB-секцию. Эта функция вызывает одноименную функцию GDI. Если вызов был успешным, функция копирует структуру BITMAP- INFO и заполняет новую цветовую таблицу; затем вызывается функция DIB:: AttachDIB, инициализирующая переменные класса KDIB. Обратите внимание — мы ограничиваемся освобождением новой структуры BITMAPINFO; деструктор класса KDDB вызывает DeleteObject с манипулятором DIB-секции, что приводит к освобождению массива пикселов, выделенного GDI. Функции GetObjectType и GetObject для DIB-секции DDB-растры и DIB-секции относятся к общей категории объектов GDI, но между ними, конечно, существуют принципиальные различия. Располагая только манипулятором объекта GDI, трудно сказать, к чему он относится — к DDB- растру или DIB-секции. Для DIB-секций функция GetObjectType возвращает то же значение 0BJBITMAP (7); функция GetObject (hBitmap, О, NULL) всегда возвращает sizeof (BITMAP), а функция GetObject (hBitmap, sizeof (BITMAP), &bmp) всегда завершается успешно и заполняет структуру BITMAP. DIB-секцию можно отличить от DDB двумя способами. Во-первых, структура BITMAP, возвращаемая GetObject, содержит действительный указатель на массив пикселов. Как говорилось выше, для DDB адрес массива пикселов не передается приложению, поэтому поле bmBits всегда равно NULL. Для DIB-секций это поле совпадает со значением, возвращаемым CreateDIBSection в параметре ppvBits. Во-вторых, GetObject может возвращать структуру DIBSection, если параметр cbBuffer равен sizeof(DISBSECTI0N), а размер буфера, на который указывает lpvObjects, достаточен для хранения структуры DIBSection. Структура DIBSection содержит информацию о DIB-секции, которую GDI предоставляет приложениям. В первом поле хранится структура BITMAP, которая описывает DIB-секцию со стороны DDB. Во втором поле хранится структура BITMAPINFOHEADER, описывающая размеры и цветовой формат DIB. Помните, что вместо нее также может использоваться структура BITMAPV4HEADER или BITMAPV5HEADER. Вероятно, на уровне GDI следовало бы определить структуры DIBSECTI0NV4 и DIB- SECTI0NV5. Поле dsBitFields содержит массив из трех битовых масок, используемых в 16- и 32-разрядных режимах (в режимах BIJRGB и BI_BITFIELDS). По ним
Использование DDB-растров 599 можно определить текущий формат пикселов в режиме с кодировкой 16 бит/пиксел. Если вы создаете 16-разрядную DIB-секцию в формате BIRGB, проверьте поле dsBitFields структуры DIBSection, и вы узнаете, какой формат пикселов используется — 5-5-5 или 5-6-5. Два последних поля предназначены для создания DIB- секций на базе объекта файла, отображаемого на память. Их значения совпадают с параметрами, передаваемыми при вызове CreateDIBSection. GetDIBColorTable и SetDIBColorTable DIB-секция не является полноценным DIB-растром, поскольку приложение не имеет прямого доступа к цветовой таблице, как при работе с цветовой таблицей DIB. Цветовая таблица DIB-секции находится под управлением GDI, и приложение работает с ней только через функции GetDIBColorTable/SetDIBColorTablе. Напрашивается вопрос: зачем приложению обращаться к цветовой таблице DIB-секции, если оно уже предоставило ее при создании DIB-секции функцией CreateDIBSection? Существует минимум две веские причины. Во-первых, если при вызове функции CreateDIBSection параметр i Usage был равен DIBPALC0L0RS, приложение работает только с индексами логической палитры, а не с цветовой таблицей RGB. Если приложение захочет сохранить DIB-секцию в ВМР-файле, ему понадобится нормальная цветовая таблица RGB. Во-вторых, многие графические алгоритмы (например, регулировка оттенка, яркости и насыщенности растра или преобразование его к оттенкам серого) реализуются операциями с цветовой таблицей изображений. Для этого приложение выполняет необходимые манипуляции с цветовой таблицей RGB и возвращает ее новое состояние. Функция GetDIBColorTable возвращает цветовую таблицу RGB для DIB-секции. В первом параметре функции передается совместимый контекст устройства, в котором должна быть выбрана DIB-секция. Параметры uStartlndex и cEntries сообщают начальную позицию и количество копируемых элементов. Параметр pColors указывает на буфер для записи цветовой таблицы в виде массива структур RGBQUAD. Возвращаемое значение функции определяет количество скопированных элементов; 0 является признаком ошибки. Функция SetDIBColor заполняет цветовую таблицу DIB-секции данными из таблицы, предоставленной приложением. Она вызывается с теми же параметрами и возвращает количество скопированных элементов. Ниже приведены соответствующие функции класса KDIBSection. Обратите внимание: мы используем тот же совместимый контекст устройства, который использовался при выводе растра, а цветовая таблица DIB-секции хранится в переменной KDIB: :m_pRGBQUAD. // Копирование цветовой таблицы DIB-секции в цветовую таблицу DIB UINT KDIBSection::GetColorTable(void) { int width, height; if ( (GetDepth()>8) || ! Prepare(width, height) ) // Создать совместимый // контекст устройства return 0: return GetDIBColorTable(m_hMemDC, 0, mjiClrUsed. m_pRGBQUAD); }
600 Глава 10. Основные сведения о растрах // Копирование цветовой таблицы DIB в цветовую таблицу DIB-секции UINT KDIBSection::SetColorTable(void) { int width, height; if ( (GetDepth()>8) || ! PrepareCwidth, height) ) // Создать совместимый // контекст устройства return 0; return SetDIBColorTable(m_hMemDC. 0. mjiClrUsed. m_pRGBQUAD); } I Применение DIB-секций: аппаратно- независимый вывод DIB-секции обладают рядом преимуществ по сравнению с DIB и DDB. О Аппаратно-зависимый вывод средствами GDI. GDI не оказывает особой помощи в построении DIB. Для DDB поддерживается всего один цветовой формат, совместимый с текущим режимом экрана. Если графическое приложение хочет реализовать 24-разрядный вывод в экранном режиме с кодировкой 8 бит/пиксел средствами GDI, это можно сделать только с использованием DIB-секции. О Объединение вывода средствами GDI с прямым доступом к массиву пикселов. Только DIB-секции поддерживают одновременный вывод средствами GDI с прямым доступом к массиву пикселов в приложениях. Без DIB-секций вам придется создавать DIBhDDBh передавать пикселы между ними функциями GetDIBits и SetDIBits. О Гибкая схема управления памятью. DDB-растры создаются в системной памяти, а память DIB-секций выделяется в виртуальном адресном пространстве приложения или в файле, отображаемом на память. Размер DIB-секции ограничивается только объемом виртуального адресного пространства и свободным пространством на диске. Например, если позволяет место на диске, вы можете создать DIB-секцию 8192 х 8192 с 32-разрядной кодировкой цвета объемом 256 Мбайт. Создать DDB такого размера невозможно, поскольку в системах семейства NT максимальный размер DDB равен 48 Мбайт, а в системах семейства Windows 95—16 Мбайт. DIB-секции также позволяют создать большее количество растров одновременно. Управление памятью для DIB отличается большей гибкостью. Например, DIB-растры могут находиться в секции ресурсов исполняемого файла, доступной только для чтения. Давайте рассмотрим реализацию аппаратно-независимого вывода на конкретном примере и вернемся к примеру с сохранением экрана. На этот раз мы хотим сохранить содержимое окна в 24-разрядном DIB-растре. Конечно, содержимое окна можно сохранить в DDB-растре, а затем преобразовать его в 24-разрядный DIB-растр, но мы хотим сделать кое-что еще — а именно, нарисовать объемную рамку и снабдить изображение подписью. При работе с DDB в экранном режиме с 8-разрядным цветом сделать это было бы очень сложно — плавные переходы цветов объемной рамки плохо представляются в 8-разрядном DDB-растре.
Использование DDB-растров 601 С другой стороны, если вы решите создать рамку в 24-разрядном DIB-растре, GDI вам в этом не поможет. С другой стороны, можно обойтись одной 24-разрядной DIB-секцией. Весь вывод будет осуществляться средствами GDI, а потом полученное изображение можно будет сохранить в ВМР-файле. Функции SaveWindow (сохранение содержимого окна) и Frame3D (рисование объемной рамки) приведены в листинге 10.10. Листинг 10.10. Сохранение окна и построение рамки в DIB-секции BOOL SaveWindow(HWND hWnd. boo! bClient. int nFrame, COLORREF crFrame) { RECT wnd; if ( bClient ) { if ( ! GetClientRect(hWnd. & wnd) ) return FALSE; } else { if ( ! GetWindowRect(hWnd. & wnd) ) return FALSE; } KBitmapInfo bmi; KDIBSection dibsec; bmi.SetFormaUwnd.right - wnd.left + nFrame * 2. wnd.bottom - wnd.top + nFrame *2. 24, BI_RGB); if ( dibsec.CreateDIBSection(NULL. bmi.GetBMIO. DIB_RGB_C0L0RS. NULL, NULL) ) { int width, height; dibsec.Prepare(width, height); // Создать совместимый // контекст устройства, // выбрать в нем dibsec if ( nFrame ) { Frame(dibsec.mJiMemDC. nFrame, crFrame. 0, 0, width, height); TCHAR Tit!e[128]; GetWindowText(hWnd. Title. sizeof(Title)/sizeof(Title[0])): SetBkMode(dibsec.m_hMemDC. TRANSPARENT); SetTextColor(dibsec.m_hMemDC. RGB(0xFF. OxFF. OxFF)); TextOutCdibsec.mJiMemDC. nFrame, (nFrame-20)/2. Title. _tcslen(Title)); } HDC hDC; if ( bClient ) hDC = GetDC(hWnd);
602 Глава 10. Основные сведения о растрах Листинг 10.10. Продолжение else hDC - GetWindowDC(hWnd); // Скопировать содержимое экрана в DIB-секцию BitBlt(dibsec.m_hMemDC, nFrame, nFrame. width height - nFrame * 2. hDC. 0. 0. SRCCOPY); ReleaseDCChWnd. hDC): nFrame return dibsec.SaveFile(NULL); } return FALSE; void Frame3D(HDC hDC. int nFrame. COLORREF crFrame. int left, int top. int right, int bottom) { int red = GetRValue(crFrame); int green = GetGValue(crFrame); int blue = GetBValue(crFrame); RECT rect = { left. top. right, bottom }; for (int i=0; i<nFrame; i++) HBRUSH hBrush - CreateSolidBrush(RGB(red. green, blue)); FrameRect(hDC. & rect, hBrush); // Один пиксел DeleteObject(hBrush); if ( i<nFrame/2 ) { red - red * 19/20 green = green * 19/20 blue - blue * 19/20 // Первая половина // Темнее else red = red green = green blue = blue 19/18 19/18 19/18 // Вторая половина // Светлее if ( red>255 ) red = 255 if ( green>255 ) green - 255 if ( blue>255) blue - 255 InflateRect (&rect. -1. -1); // Меньше Функция SaveWi ndow получает четыре параметра. Параметр hWnd содержит манипулятор окна, параметр bClient определяет сохраняемую часть (все окно или клиентская область), параметр nFrame содержит толщину добавляемой рамки, а параметр crFrame определяет цвет рамки. Функция готовит структуру BITMAPINFO для 24-разрядной DIB-секции, используя несложный класс KBitmapInfo, предназначенный для инициализации BITMAPINFO. Экземпляр KDIBSection создается в стеке. После создания DIB-секции функция SaveWi ndow создает совместимый контекст и выбирает в нем DIB-секцию. Теперь можно вызвать функцию Frame3D для рисования рамки, вывести надпись с текстом из заголовка окна и, наконец,
Использование DDB-растров 603 скопировать пикселы из экранного контекста устройства в центр DIB-секции. Затем программа сохраняет DIB-секцию в BMP-файле вызовом метода KDIB:: SaveFile. Объемная рамка строится из прямоугольников высотой в один пиксел, цвет которых постепенно темнеет, а начиная с середины рамки — светлеет, что создает иллюзию полукруглой рамки. Пример изображен на рис. 10.7. Рис. 10.7. Сохраненная клиентская область в рамке Приведенный пример показывает, как использовать GDI для вывода в DIB- секции. Прямой доступ к массиву пикселов организуется так же, как это делается в DIB. Дополнительная информация приведена в следующей главе. Применение DIB-секции: вывод в высоком разрешении Выделение памяти для хранения DIB-секций в адресном пространстве пользовательского режима позволяет работать с изображениями значительно больших размеров, чем при использовании DDB. Возможность создания DIB-секций на базе манипулятора файла, отображаемого на память, упрощает контроль над размещением данных на диске и в памяти. Эти две особенности часто используются в графических редакторах и программных процессорах растровых изображений (Raster Image Processor, RIP). Процессор растровых изображений получает документ, написанный на языке описания страниц, и преобразует его в растровое изображение высокого разрешения, который после полутоновой обработки передается на принтер высокого разрешения. Например, программу Ghostscript можно рассматривать как программный процессор RIP — Ghost- script получает документ в формате PostScript и воспроизводит его в растровом виде в разных вариантах разрешения. В этом разделе мы напишем несложный программный процессор RIP, работа которого основана на использовании DIB-секций. Конечно, документы PostScript слишком сложны для подобных примеров, но мы прибегнем к помощи GDI
604 Глава 10. Основные сведения о растрах и воспользуемся другим выразительным, полезным и общедоступным средством — расширенными метафайлами Windows (EMF). Наша задача — создать файл, отображаемый в память, на базе которого будет создана DIB-секция высокого разрешения, и затем воспроизвести EMF-файл в этой DIB-секции. Завершив воспроизведение, мы удаляем DIB-секцию, закрываем файл и получаем растровое представление EMF-файла в высоком разрешении. Основные трудности связаны с тем, что функция CreateDIBSection требует, чтобы смещение массива пикселов было кратно DWORD. BMP-файлы не удовлетворяют этому требованию, поскольку их массивы пикселов никогда не начинаются на границе DWORD. Мы пойдем обходным путем и воспользуемся 24-разрядным графическим форматом Targa, который содержит очень простой заголовок регулируемой длины и поддерживает несжатые массивы пикселов RGB в 24-разрядном формате. В листинге 10.11 приведен класс КТагда24, предназначенный для работы с DIB-секциями в 24-разрядном графическом формате Targa. Листинг 10.11. Работа с DIB-секциями с использованием файлов, отображаемых на память class KTarga24 : public KDIBSection { #pragma pack(push.l) typedef struct { BYTE IDLength; BYTE CoMapType; BYTE ImgType; WORD Index; WORD Length; BYTE CoSize; WORD X_0rg; WORD Y_0rg; WORD Width: WORD Height; BYTE Pixel Size; BYTE AttBits; char ID[14]; } ImageHeader; #pragma pack(pop) HANDLE m_hFile HANDLE mJiFileMapping; public: KTarga24() { mJiFile = INVALID_HANDLE_VALUE; mJiFileMapping - INVALID_HANDLE_VALUE; }: virtual ~KTarga24() { // 00: Длина строки-идентификатора //01 0 = таблица отсутствует //02 2 = TGA_RGB // 03 индекс первого элемента цветовой таблицы // 05 количество элементов в цветовой таблице // 07 размер элемента цветовой таблицы // 08 О // 0А О // ОС ширина // 0Е высота // 10 размер пиксела // 11 0 // 12 заполнитель, обеспечивающий // выравнивание ImageHeader по границе DWORD
Использование DDB-растров 605 ReleaseDDBO; ReleaseDIBO; if ( m_hFileMapping!=INVALID_HANDLE_VALUE ) CI oseHandle(m_hFi1eMappi ng); if ( mJiFile !« INVALID_HANDLE_VALUE ) CloseHandle(m_hFile); }: BOOL Create(int width, int height, const TCHAR * filename); BOOL KTarga24::Create(int width, int height, const TCHAR * pFileName) { if ( width & 3 ) // Обойти проблемы совместимости с TGA return FALSE; ImageHeader tgaheader; memset(& tgaheader. 0. sizeof(tgaheader)); tgaheader.IDLength = si zeof(tgaheader.ID); tgaheader.ImgType = 2: tgaheader.Width = width; tgaheader.Height = height; tgaheader.Pixel Size = 24; strcpy(tgaheader.ID. "BitmapShop"); m_hFile = CreateFile(pFileName. GENERIC_WRITE | GENERIC_READ. FILE_SHARE_READ | FILE_SHARE_WRITE. NULL. CREATE_ALWAYS. FILE_ATTRIBUTE_NORMAL. NULL); if ( m_hFile==INVALID_HANDLE_VALUE ) return FALSE; int imagesize = (width*3+3)/4*4 * height; m_hFileMapping = CreateFileMapping(m_hFile. NULL. PAGE_READWRITE. 0. sizeof(tgaheader) + imagesize, NULL); if ( m_hFileMapping==INVALID_HANDLE_VALUE ) return FALSE; DWORD dwWritten = NULL; WriteFile(m_hFile. & tgaheader. sizeof(tgaheader). &dwWritten. NULL); SetFilePointer(m_hFile. sizeof(tgaheader) + imagesize. 0. FILE_BEGIN); SetEndOfFile(m_hFile); KBitmapInfo bmi: bmi.SetFormat(width, height. 24. BI_RGB); return CreateDIBSection(NULL. bmi.GetBMIO. DIB_RGB_C0L0RS. m_hFi1eMappi ng. si zeof(tgaheader));
606 Глава 10. Основные сведения о растрах Класс КТагда24 определен как производный от класса KDIBSection. Он содержит две новые переменные для хранения манипуляторов файла и файлового отображения. Главным методом класса является метод Create, при вызове которого передается ширина, высота и имя файла. Функция создает объекты файла и файлового отображения, заполняет 32-байтовый заголовок графического формата Targa и создает DIB-секцию с использованием объекта файлового отображения. Поскольку длина заголовка равна 32 байтам, смещение массива пикселов равно 32 — величине, кратной DWORD. Обратите внимание: файл должен быть создан с общим доступом для чтения и записи, и файловое отображение также должно иметь права доступа для чтения и записи; в противном случае попытки создания DIB-секции или вывода в файл завершатся неудачей. Объекты файла и файлового отображения закрываются в деструкторе после удаления объекта DIB-секции (в ReleaseDDB). Расширенные метафайлы (EMF) описаны в главе 16. Пока достаточно запомнить, что EMF-файл представляет собой записанную последовательность команд GDI, которая легко обрабатывается и воспроизводится. Приведенная ниже функция использует класс КТагда24 для воспроизведения EMF-файла. BOOL RenderEMFCHENHHETAFILE hemf. int width, int height, const TCHAR * tgaFileName) { KTarga24 targa; int w = (width+3)/4*4; // Убедиться, что значение кратно 4 if ( targa.Create(w. height, tgaFileName) ) { targa.Prepare(w, height); BitBlt(targa.mJiMemDC. 0. 0, width, height, NULL. 0. 0. WHITENESS); // Очистить DIB-секцию RECT rect = { 0. 0. width, height }; return PlayEnhMetaFile(targa.m_hMemDC. hemf. &rect); } return FALSE; } Функция RenderEMF получает манипулятор EMF, ширину и высоту воспроизводимого изображения и имя графического файла. Она создает экземпляр класса КТагда24 в стеке, инициализирует его, заполняет DIB-секцию белым цветом и вызывает функцию PlayEnhMetaFile для воспроизведения объекта EMF в DIB- секции. Остается написать интерфейсный код для выбора входного EMF-файла, имени выходного файла Targa и масштаба воспроизведения. EMF-файлы воспроизводятся пропорционально с одинаковым масштабом по осям х и у. Для проверки мы воспользовались 600-килобайтным EMF-файлом, содержащим сложный рисунок, в масштабе 900 %. Исходный размер изображения составлял 625 х 777 пикселов; в масштабе 900 % он достиг 5625 х 6993 пикселов. DIB-секция с 24-разрядной кодировкой цвета занимает 112 Мбайт. По размерам изображения это задание печати близко к полностраничному документу с разрешением 600 dpi.
Итоги 607 Итоги В этой главе рассматривались три типа растров, поддерживаемых в GDI, — ап- паратно-независимые растры (DIB), аппаратно-зависимые растры (DDB) и DIB- секции. Основное внимание уделялось вопросам создания, преобразования, отображения и простейшего применения этих типов растров, а также различиям между ними. Растры — настолько серьезная тема, что ее описание разделено на три главы. В главе 11 рассматриваются нетривиальные и интересные аспекты применения растров: растровые операции, прозрачность, прямой доступ к пикселам и альфа- наложение. Глава 12 посвящена обработке изображения посредством прямого доступа к пикселам. Кроме того, в главе 17 рассматривается декодирование и печать изображений в формате JPEG. Примеры программ В этой главе рассматриваются два примера программ (табл. 10.6). Важно то, что работа этих двух программ основана на нескольких полезных классах, которые в усовершенствованном виде будут использоваться в других главах, посвященных растровым изображениям. Таблица 10.6. Программы главы 10 Каталог проекта Описание Samples\Chapt_10\Bitmaps Демонстрация загрузки и сохранения ВМР-файлов, сохранения экрана, различных способов отображения растров, применения растровых меток и команд меню, растровых фонов, DIB-секций, аппаратно-независимо- го вывода с использованием DIB-секций и вывода растров в шсстнадцатеричном формате Samples\Chapt_10\Scrambler Применение функции StretchBlt для случайной перестановки фрагментов экрана
Глава 11 Нетривиальное использование растров Растры играют чрезвычайно важную роль в программировании для Windows, поэтому эту тему невозможно охватить в одной главе. В предыдущей главе описаны три типа растров, поддерживаемых в GDI: аппаратно-независимые растры (DIB), аппаратно-зависимые растры (DDB) и DIB-секции. Мы рассмотрели основные принципы работы с растрами, в том числе различные способы их отображения, применение растровых изображений в пользовательском интерфейсе и даже программную реализацию вывода с высоким разрешением. Однако предыдущая глава далеко не исчерпывает темы растровых изображений. В этой главе мы будем изучать растровые операции, прозрачность и альфа- наложение. Глава 12 посвящена работе с растровыми изображениями на уровне прямого доступа к пикселам, а палитры рассматриваются в главе 13. Тернарные растровые операции При рисовании линий или заливке областей GDI использует бинарные растровые операции, которые определяют способ объединения пиксела пера или кисти с пикселом приемника и получения нового пиксела приемника. В GDI поддерживается шестнадцать бинарных растровых операций, для работы с ними используется пара функций SetR0P2 и GetR0P2. Вполне логично предположить, что при работе с растрами существуют похожие растровые операции, позволяющие создавать всевозможные специальные эффекты. При этом возникает новый фактор — пикселы изображения-источника. Таким образом, при работе с растрами приходится учитывать три фактора: цвет пиксела пера или кисти, цвет пиксела приемника и цвет пиксела источни-
Тернарные растровые операции 609 ка. Растровые операции, объединяющие эти три цвета, обычно называются тернарными растровыми операциями. В GDI поддерживаются только поразрядные логические операции, которые выполняются с каждым битом пиксела независимо от других пикселов и ограничиваются булевыми операциями AND (&), OR (|), NOT (~) и XOR (А). При таких ограничениях существует 256 (2А(2А3), или 28) возможных тернарных растровых операций. Коды растровых операций Для представления 256 разных растровых операций достаточно одного байта. Учитывая, что каждый бит интерпретируется независимо от остальных, механизм кодировки выглядит весьма простым. Предположим, Р — бит пера или кисти, S — бит источника, a D — бит приемника. Если результат растровой операции всегда равен Р, операции присваивается код OxFO. Если результат операции всегда совпадает с S, код равен ОхСС, а если он всегда совпадает с D, то код равен ОхАА. Ниже приведены определения этих кодов растровых операций на языке C/C++: const BYTE rop_P = OxFO; //11110000 const BYTE rop_S = OxCC; //11001100 const BYTE rop_D = OxAA; //10101010 Все остальные растровые операции определяются на основании этих трех констант посредством булевых операций. Например, если в результате растровой операции S и Р объединяются логической операцией AND, достаточно вычислить rop_S&rop_P — получается ОхСО. Если вам нужна растровая операция, которая возвращает Р, если S = 1, и D в противном случае, вычислите (rop_S&rop_P) | (~rop_S&rop_D); получается -хЕ2. Для каждой растровой операции существует минимум одна соответствующая формула булевой алгебры, точно описывающая растровую операцию по величинам Р, S и D. Операции может соответствовать несколько формул, но все они являются логически эквивалентными. По традиции в этих формулах используется постфиксная запись, при которой оператор находится справа от операндов. Постфиксная запись удобна тем, что при ней не нужны круглые скобки, а ее логика легко реализуется в компьютерных программах. Вероятно, разработчик растровых операций был поклонником Forth (расширяемый язык со стековой схемой вычислений без проверки типа), PostScript или инженерных калькуляторов HP, использующих постфиксную запись. В постфиксной записи растровых операций Р, S и D являются операндами, а а, о, п и х — соответственно операторами для операций AND, OR, NOT и XOR. Например, растровая операция 0хЕ2 записывается формулой DSPDxax. Преобразуя ее в инфиксную запись, мы получаем DX(S&(P4)))). В более наглядном виде эта формула выглядела бы так: (S&P) |(~S&D), или SPaSnDao. Почему же первой формуле отдается предпочтение перед второй? По двум причинам. На большинстве процессоров реализована инструкция XOR, не уступающая по скорости операции AND. В первой формуле используются три операции, а во второй — четыре. Для вычисления первой формулы нужен только один дополнительный
610 Глава 11. Нетривиальное использование растров регистр, а для второй — два регистра. Ниже приведена реализация этих формул на псевдокоде (для кадрового буфера с 32-разрядной кодировкой цвета): // Реализация 0хЕ2 DSPDxax по схеме DA(S&(PAD)) mov еах, Р // Р хог еах. D // PAD and еах. S // S&(PAD) хог еах. D // DA(S&(PAD)) mov D. еах // Записать результат // Реализация 0хЕ2 SPaSnDao по схеме (S&P)|(~S&D) mov еах. S // S and еах. Р // S&P mov ebx. S // S not ebx // ~S and ebx. D // -S&D or eax. ebx // (S&P) | (-S&D) mov D. еах // Записать результат Растровые операции в GDI обычно кодируются 32-разрядными двойными словами DWORD вместо простых байтов от 0 до 255. В старшем слове хранится один из 256 однобайтовых кодов растровых операций, о которых говорилось выше; младшее слово содержит кодировку формулы, определяющей растровую операцию. В исходной архитектуре для определения растровой операции используется только младшее слово; старшее слово содержит дополнительную информацию для аппаратных блиттеров. В старых реализациях растровые операции кодировались вручную на оптимизированном ассемблере, поэтому предпочтение отдавалось общим алгоритмам вместо 256 разных случаев для разных растровых операций и большой таблицы переходов. В современных реализациях используется автоматический генератор растровых операций, который в отличие от своих предшественников не жалуется на необходимость создания 256 разных функций. Механизм кодировки младшего слова тернарной растровой операции — настоящее произведение искусства, появившееся в те давние времена, когда программистам приходилось тщательно обдумывать каждую строку машинного кода и экономить каждый бит памяти. В формулах растровых операций используется 7 разных символов, причем длина формулы может достигать 12 символов. Простейшему механизму кодировки для этого понадобилось бы log2(712) или 33,7 бита информации, но разработчикам приходилось ограничиваться одним 16-разрядным словом. Формула растровой операции делится на две части: операторы и операнды (по аналогии со стеками операторов и операндов на некоторых стековых машинах). Операторы кодируются старшими 11 битами, а оставшиеся 5 бит остаются для операндов. Из 11 бит 10 используются для кодировки пяти логических операций, по два бита на операцию: 0 — NOT, 1 — XOR, 2 — OR, 3 — AND. Последний флаговый бит является признаком последней операции NOT. Закодировать строку операндов всего 5 битами очень нелегко, но умные программисты отыскали в строках операндов повторяющиеся цепочки. Всего было выделено 8 таких цепочек, для кодировки которых достаточно трех битов. Последние два бита определяют величину сдвига цепочек. Схема кодировки младшего слова тернарных операций GDI изображена на рис. 11.1.
Тернарные растровые операции 611 Оператор 0:NOT 1:XOR 2: OR 3:AND 0: SPDDDDDD 1:SPDSPDSP 2: SDPSDPSD 3: DDDDDDDD 4: DDDDDDDD r ^y "у Y y^ Op 5 Op 4 Op 3 Op 2 Op 1 ^ A. Л A Л 5: S+SP-DSS 6: S+SP-PDS 7: S+SD-PDS 15 14 13 12 11 10 9 8 7 6 5 4 3 Рис. 11.1. Структура младшего слова растровой операции Конечно, сказанное стоит пояснить на конкретном примере. Возьмем растровую операцию 0хЕ2; полный код растровой операции равен 0х00Е20746, поэтому младшее слово равно 0x0746. Таким образом, Ор5 = NOT, Op4 = NOT, ОрЗ = XOR, Ор2 = AND, Opl = XOR, дополнительная операция NOT не нужна, индекс цепочки равен 1, а смещение равно 2. Цепочка SPDSPDSP сдвигается на два символа и дает DSPDSPSP. У нас имеется пять операторов, но лишь три из них являются бинарными; два последних относятся к унарным. Следовательно, реально используются лишь четыре операнда. Цепочка усекается до DSPD; применение операторов, начиная с последнего символа, дает нам DSPDxaxnn, или после упрощения — DSPDxax; именно эта строка определяет растровую операцию в GDI. Знаки «+» и «-» в цепочках называются специальными операндами. Из 256 растровых операций 16 не могут быть выражены с использованием простого накопителя, в котором хранится только одна вычисляемая величина. Для этих 16 растровых операций промежуточный результат заносится в стек, а затем извлекается при необходимости. Специальные операнды всегда включаются в цепочку парами. В первый раз текущий результат заносится в стек, и загружается следующий операнд; во второй раз текущий результат объединяется с величиной, сохраненной в стеке, бинарной логической операцией. Во внутреннем представлении эти специальные операнды представляются одними и теми же битами (0x00), чтобы цепочка помещалась в 16-разрядном слове. На рис. 11.1 знак «-» соответствует занесению в стек, а знак «+» — извлечению из стека. Не забывайте о том, что цепочки читаются в обратном порядке. Конечно, эта славная архаичная структура экономит память и объем ассемблерного кода, но это достигается за счет быстродействия и наглядности. В новых реализациях GDI этот медленный механизм уже не используется, поэтому в общем случае младшее слово тернарной операции можно смело игнорировать. Однако трудно с уверенностью сказать, не захочет ли конкретный драйвер графического устройства проверить точное совпадение всех битов 32-разрядного кода
612 Глава 11. Нетривиальное использование растров растровой операции, поэтому для надежности рекомендуется проверять полный код растровой операции и использовать его. Тернарные растровые операции используют только 24 бита из 32-разрядного кода ROP. Старшие 8 бит кода обычно заполняются нулями. В Windows 98 и Windows 2000 появились два новых флага, управляющих копированием растров: CAPTUREBLT и N0MIRR0RBITMAP. Флаг CAPTUREBLT (0x40000000) используемся при работе с окнами, имеющими собственную поверхность вывода, которая может объединяться с содержимым других окон посредством альфа-наложения. При использовании флага CAPTUREBLT пикселы всех окон, расположенных поверх текущего окна, включаются в итоговое изображение. По умолчанию изображение состоит только из содержимого текущего окна. Флаг N0MIRR0RBITMAP (0x80000000) предотвращает зеркальное отражение растров по вертикали и горизонтали оси из-за разной направленности осей в исходном и приемном прямоугольниках. Диаграмма тернарных растровых операций Алгебраические формулы растровых операций точны и удобны, но визуальное представление поможет вам лучше разобраться в многочисленных разновидностях этих операций. Создав шаблоны для трех переменных, мы сможем сгенерировать итоговый растр по алгебраическим формулам и наглядно увидеть результаты применения всех операций. На рис. 11.2 приведена простая диаграмма тернарных растровых операций, полученная применением растровых операций к трем растрам, изображенным слева. ^_ йй 01 Q2 03 04 OS ОБ 07 08 09 ОА 0В ОС OD QE OF Pattern 20 ■ 000О0&0О0&0О&®ЯО Рис. 11.2. Диаграмма тернарных растровых операций
Тернарные растровые операции 613 Растр узора (8x8 пикселов) сгенерирован применением шаблона OxFO по направлениям X и Y. Источник сгенерирован по шаблону ОхСС, а приемник — по шаблону ОхАА. В данном примере белому цвету соответствует логическое значение 1, а черному — логический ноль. 256 маленьких растров представляют все возможные результаты растровых операций. Они сгенерированы созданием узорной кисти по узорному растру и последующим объединением источника с приемником при выбранной узорной кисти. Ниже приведен код, использованный при построении диаграммы растровых операций. Обратите внимание: растры 8x8 требуются для того, чтобы узорная кисть работала и в системах семейства Windows 95. Растр генерируется в совместимом контексте устройства, а затем масштабируется в экранном контексте устройства, поскольку узорные кисти не масштабируются. const WORD Bit_Pattern [] = { OxFO, OxFO, OxFO. OxFO. OxOF. OxOF. OxOF, OxOF OxCC. OxCC. 0x33. 0x33. const WORD Bit_Source [] OxCC. OxCC. 0x33. 0x33 const WORD Bit_Destination[] OxAA. 0x55. OxAA. 0x55 OxAA. 0x55. OxAA. 0x55. void Rop3Chart(HDC hDC) HBITMAP Pbmp = CreateBitmap(8, 8 HBITMAP Sbmp = CreateBitmap(8. 8. HBITMAP Dbmp - CreateBitmap(8. 8. HBITMAP Rbmp = CreateBitmap(8. 8. 1.1. Bit_Pattern); 1.1. Bit_Source); 1.1. Bit_Destination); 1. 1. NULL); HBRUSH Pat = CreatePatternBrush(Pbmp); HDC Sr - CreateCompatibleDC(hDC) HDC Dst = CreateCompatibleDC(hDC) HDC Rst = CreateCompatibleDC(hDC) // Узорная кисть // Совм. DC для источника // Совм. DC для приемника // Совм. DC для результата SelectObjectCSrc. Sbmp); SelectObject(Dst. Dbmp); SelectObjectCRst. Pbmp); StretchBlt(hDC. 20. 20. 80. 80. Rst. 0. 0. 8. 8. SRCCOPY) StretchBltChDC. 20. 220. 80. 80. Src. 0. 0. 8. 8. SRCCOPY) StretchBlt(hDC, 20. 420. 80. 80. Dst. 0. 0. 8. 8. SRCCOPY) SetBkMode(hDC. TRANSPARENT); TextOut(hDC. 20. 105. "Pattern". 7); TextOut(hDC. 20. 305. "Source". 6); TextOut(hDC. 20. 505. "Destination". 11); SelectObject(Rst. Rbmp); SelectObject(Rst. Pat); for (int i=0; i<16; i++) char mess[3]; wsprintf(mess. "ОЯХ", i); TextOut(hDC, 140 + i*38. 10. mess. 2);
614 Глава 11. Нетривиальное использование растров wsprintf(mess. "Щ". i); TextOut(hDC, 115. 30+1*38. mess. 2); } for (int rop=0; rop<256; rop++) { BitBltCRst. 0. 0. 8. 8. Dst. 0. 0. SRCCOPY); BitBltCRst. 0. 0. 8. 8. Src. 0. 0. GetRopCode(rop)); StretchBltChDC. 140 + (rop*16)*38. 30 + (rop/16)*38. 32. 32. Rst. 0. 0. 8. 8. SRCCOPY); } DeleteObject(Src); DeleteObject(Dst); DeleteObject(Rst); DeleteObject(Pat): DeleteObject(Pbmp); DeleteObject(Sbmp); DeleteObject(Dbmp): DeleteObject(Rbmp); } Часто используемые растровые операции Набор из 256 растровых операций выглядит впечатляюще, но на практике активно используется лишь десяток с небольшим операций. Разработчики Microsoft удосужились присвоить имена всего 15 из них. Если учесть, что в GDI существует 16 именованных бинарных растровых операций, 15 именованных тернарных операций явно недостаточно, поскольку каждой бинарной операции соответствует тернарная операция, результат которой не зависит от S. В табл. 1.1 перечислены 30 тернарных растровых операций, используемых в практическом программировании. По сравнению с бинарными операциями имена тернарных операций выглядят довольно странно. Все имена бинарных растровых операций начинаются с префикса R2_, поэтому напрашивается предположение, что имена тернарных операций должны начинаться с префикса R3_. Ничего подобного! В именах бинарных операций операция NOT обозначается «NOT», операция XOR обозначается «XOR», операция OR обозначается «MERGE», а операции AND соответствует обозначение «MASK». В именах тернарных операций «INVERT» иногда обозначает NOT, а иногда — XOR; операция OR обозначается «PAINT», a AND NOT обозначается «ERASE». При использовании незнакомых тернарных растровых операций необходимо действовать очень осторожно. Проверьте формулу и убедитесь, что она делает именно то, что вам нужно. Таблица 11.1. Тернарные растровые операции Зависимость Имя ROP3 Код ROP Формула Имя ROP2 Нет BLACKNESS 0x000042 0 R2JLACK WHITENESS 0xFF0062 1 R2 WHITE
Тернарные растровые операции 615 Зависимость Узор Источник Приемник Приемник и источник Узор и приемник Приемник и источник Узор, источник и приемник Имя ROP3 PATC0PY SRCC0PY N0TSRCC0PY MERGECOPY PATINVERT NOTSRCERASE SRCERASE SRCINVERT SRCAND MERGEPAINT SRCPAINT PATPAINT Код ROP 0xF00021 OxOFOOOl 0хСС0020 0x330008 0хАА0029 0x550009 ОхСОООСА 0xF0008A 0х0500А9 0х0А0329 0x5000325 0х5А0049 0x5F00E9 0хА000С9 0хА50065 0xAF0229 0xF50225 0xFA0089 ОхИООАб 0x440328 0x660046 0х8800С6 0хВВ0226 0хЕЕ0086 0xFB0A09 0хВ8074А 0хЕ20746 Формула Р -Р S -S D Ч) Р & S Р | S ~(Р | D) -P&D P&-D Р А D ~(P&D) Р & D ~ (Р А D) -Р | D Р | -D Р | D ~( S | D) S & ~D SAD S & D ~S | D S | D P | ~S | D PA(S&(PAD))) DA(S&(PAD))) Имя ROP2 R2_C0PYPEN R2_N0TC0PYPEN R2_N0P R2_N0TMERGEPEN R2_MASKN0TPEN R2_MASKPENN0T R2JC0RPEN R2_N0TMASKPEN R2_MASKPEN R2_N0TX0RPEN R2_MERGEN0TPEN R2_MERGEPENN0T R2_MERGEPEN Растровые операции в таблице упорядочены по степени зависимости от трех переменных Р, S и D. В этом отношении эта таблица отличается от большинства таблиц растровых операций, содержимое которых обычно упорядочивается по числовым значениям кодов. Понимание зависимостей поможет вам в программировании. Например, если растровая операция зависит от приемника (D), вряд ли ее стоит использовать при печати. Растровые операции предназначены для растровых устройств, у которых каждый пиксел адресуем, доступен для чтения и для записи. Некоторые графические устройства (например, принтеры PostScript) не являются полноценными растровыми устройствами; это означает, что они не
616 Глава 11. Нетривиальное использование растров поддерживают полного набора растровых операций (особенно тех, которые зависят от пикселов приемника). Если растровая операция не зависит от растра- источника, его не обязательно передавать при вызовах функций BitBlt, StretchBlt и StretchDIBits. В GDI предусмотрена специальная функция для выполнения растровых операций, не использующих источника: BOOL PatBltCHDC hDC. int nXLeft. int nYLeft. int nWidth, int nHeight. DWORD dwROP); Функция PatBlt комбинирует текущую кисть с прямоугольным регионом приемника. Обратите внимание на отсутствие параметров, определяющих растр-источник. Набор допустимых растровых операций не ограничивается именами ROP, выбранными Microsoft. Вы можете использовать любые растровые операции, в которых не задействован источник. Узнать, использует ли растровая операция ту или иную переменную, несложно. Для этого достаточно проверить, генерирует ли ROP одинаковые результаты при значениях этой переменной, равных 1 и 0. Проверочные функции для трех переменных приведены ниже. boo! inline RopNeedsNoDestination(int Rop) return ((Rop & OxM) » 1) == (Rop & 0x55); bool inline RopNeedsNoSource(int Rop) return ((Rop & OxCC) » 2) — (Rop & 0x33); bool inline RopNeedsNoPattern(int Rop) return ((Rop & OxFO) » 4) == (Rop & OxOF); BLACKNESS, WHITENESS Эти две растровые операции обычно используются для инициализации поверхностей и их возврата в исходное состояние. Операция BLACKNESS присваивает всем пикселам О, WHITENESS устанавливает все биты пикселов в 1. На устройстве с палитрой результат не всегда соответствует черному и белому цвету, но обычно первым цветом в палитре является черный, а последним — белый. Операции BLACKNESS и WHITENESS не зависят ни от одной из трех переменных. Как нетрудно догадаться, самая эффективная реализация этой операции организует заполнение памяти постоянными величинами. BLACKNESS реализуется вызовом memset(pBits, 0, nlmageSize), a WHITENESS — вызовом memset(pBits, OxFF, nlmageSize). При создании DDB или DIB-секции массив пикселов часто находится в неопределенном состоянии (исключение составляют инициализируемые DDB- растры и DIB-секции, отображаемые на память). Создаваемые поверхности рекомендуется инициализировать и переводить в определенное состояние. Черный и белый цвета отличаются от других тем, что они представляются как 0 и 1. В частности, для цвета С справедливы следующие утверждения: Black AND С = Black Black OR С = С
Тернарные растровые операции 617 Black X0R С - С White AND С = С White OR С = White White X0R С = NOT С При частичном заполнении растров черным или белым цветом с применением масок эти свойства играют важную роль при создании интересных эффектов. Только узор: PATCOPY, R3_NOTCOPYPEN Операция PATCOPY используется для заполнения прямоугольных областей текущей кистью (по аналогии с функцией FillRect). Противоположная операция (OxOFOOOl) не имеет официального названия, поэтому в табл. 11.1 имя для нее выбрано по аналогии с бинарной операцией R2_N0TC0PYPEN. Операция R3N0TC0PYPEN заполняет прямоугольную область цветом, противоположным цвету текущей кисти. Только источник: SRCCOPY, NOTSRCCOPY Мы неоднократно встречались с операцией SRCCOPY, которая просто копирует пикселы источника в приемник. Эта операция обычно требуется для отображения растра в исходном цвете. Операция NOTSRCCOPY копирует в приемник цвет, противоположный цвету источника. В режимах True Color и High Color эта операция может использоваться для создания негативов. В Windows NT 4.0 операция NOTSRCCOPY иногда реализуется неправильно (согласно документации (KB Q174534)). Ошибка должна быть исправлена в Service Pack 4. Только приемник: R3_NOP, DSTINVERT Операция DSTINVERT меняет цвет пиксела приемника на противоположный. Операция R3N0P заменяет цвет пиксела приемника тем же цветом — напрасная трата процессорного времени. Вероятно, у GDI хватает сообразительности, чтобы игнорировать операцию R3_N0P и обойтись без напрасного перемещения пикселов. Без приемника: MERGECOPY Существует десять тернарных растровых операций, зависящих от источника и узора и не зависящих от приемника. Лишь одной из этих операций было присвоено имя — MERGECOPY. Имя операции MERGECOPY (OxCOOOCA) выбрано неудачно. В бинарных растровых операциях строка «MERGE» обозначает логическую операцию OR, но здесь это правило почему-то не соблюдается. Операция MERGECOPY заменяет пиксел приемника результатом конъюнкции пиксела источника с пикселом узора. Если растр-источник является монохромным, MERGECOPY окрашивает белые пикселы в цвет кисти и оставляет черные пикселы без изменений. Если растр-источник не является монохромным, иногда бывает удобнее использовать в качестве маски кисть. Например, чтобы в цветном изображении отображался только красный канал, создайте однородную красную кисть (RGB(0xFF,0,0)) и воспользуйтесь растровой операцией MERGECOPY для вывода изображения. Красный канал копируется без изменений, а остальные две составляющие обнуляются. В результате создается изображение, состоящее из оттенков красного цвета.
618 Глава 11. Нетривиальное использование растров Приведенная ниже функция выводит один канал изображения, определяемый заданной маской. Например, если параметр mask равен RGB(0xFF,0,0), отображается только красный канал. void DisplayChannel(HDC hDC. int x, int y. int width, int height, HDC hDCSource. COLORREF mask) { HBRUSH hRed = CreateSolidBrush(mask); HBRUSH hOld = (HBRUSH) SelectObject(hDC. hRed); BitBlt(hDC, x, y, width, height. hDCSource. 0. 0. MERGECOPY); SelectObject(hDC. hOld); DeleteObject(hRed): } Разделение цветовых составляющих — стандартный прием, поддерживаемый во многих графических редакторах. Говорят, специалисты по компьютерной графике предпочитают просматривать изображение по каналам, устранять все дефекты и потом получать итоговое изображение, объединяя все каналы. Именно так создаются полноценные изображения в оттенках серого цвета. Если в приведенном выше примере приемная поверхность имеет 8-разрядный формат пикселов, а цветовая таблица настроена в соответствии с одноканальной цветовой шкалой, то позднее вам останется лишь изменить цветовую таблицу для получения изображения в оттенках серого. В листинге 11.1 приведена функция Channel Spl it, разделяющая произвольный цветной DIB-растр на три изображения в оттенках серого (по одному для каждого канала RGB). Листинг 11.1. Деление растра на каналы RGB // Создание изображения в оттенках серого (DIB-секции) // по одному каналу RGB в DIB HBITMAP ChannelSplit(const BITMAPINFO * pBMI. const void * pBits. COLORREF Mask. HDC hMemDC) { typedef struct { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColor[256]; } BMI8BPP: int width = pBMI->bmiHeader.biWidth; int height - pBMI->bmiHeader.biHeight; BMI8BPP bmi8bpp; memset(&bmi8bpp. 0, sizeof(bmi8bpp)): bmi8bpp.bmiHeader.biSize - sizeof(BITMAPINFOHEADER); bmi8bpp.bmiHeader.biWidth e width; bmi8bpp.bmiHeader.biHeight - height: bmi8bpp.bmiHeader.biPlanes - 1: bmi8bpp.bmiHeader.biBitCount - 8; bmi8bpp.bmiHeader.biCompression - BI_RGB; for (int i-0; i<256; 1++) // Цветовая таблица одного из каналов RGB {
Тернарные растровые операции 619 bmi 8bpp.bmi Col or[i].rgbRed ' - i & GetRValue(Mask); bmi8bpp.bmiColor[i].rgbGreen = i & GetGValue(Mask); bmi8bpp.bmiColor[i].rgbBlue - i & GetBValue(Mask); } HBITMAP hRslt - CreateDIBSectionCNULL. (BITMAPINFO *) & bmi8bpp. NULL, DIB_RGB_C0L0RS. NULL, NULL); if ( hRslt==NULL ) return NULL; SelectObjectChMemDC. hRslt); HBRUSH hBrush - CreateSolidBrush(Mask); // Однородный красный. // зеленый или синий цвет HGDIOBJ hOld - SelectObjectChMemDC. hBrush); StretchDIBits(hMemDC. 0. 0. width, height. 0. 0. width, height. pBits. pBMI. DIB_RGB_COLORS. MERGECOPY); for (i=0; i<256; i++) // Перейти к настоящей цветовой таблице // оттенков серого цвета { bmi 8bpp.bmi Col or[i].rgbRed - i; bmi8bpp.bmiColor[i].rgbGreen = i; bmi8bpp.bmiColor[i].rgbBlue = i: } SetDIBColorTableChMemDC. 0. 256. bmi8bpp.bmiColor); SelectObjectChMemDC. hOld); DeleteObject(hBrush); return hRslt; } Функция Channel Split создает DIB-секцию с 8-разрядной кодировкой пикселов и цветовой таблицей, содержащей оттенки цвета одного из каналов RGB. Например, если параметр mask равен RGB(255,0,0), цветовая таблица будет содержать элементы RGB(0,0,0), RGB(l.O.O) и т. д. до RGB(255,0,0). DIB-секция выбирается в совместимом контексте устройства вместе с однородной кистью, созданной на базе маски того же канала. Функция StretchDIBits использует растровую операцию MERGECOPY для выделения красного канала и сопоставляет каждому пикселу элемент цветовой таблицы DIB-секции. Если пиксел исходного DIB-раст- ра равен RGB(r,g,b), в результате операции MERGECOPY генерируется цвет RGB(г,0,0). В цветовой таблице DIB-секции ему соответствует индекс г, который и сохраняется в массиве пикселов DIB-секции. Наконец, происходит модификация цветовой таблицы, чтобы DIB-секция выводилась как изображение в оттенках серого цвета. Функция ChannelSplit работает с любыми DIB-растрами — с любой цветовой глубиной, с битовыми масками, сжатыми и несжатыми, почти не требуя дополнительного кодирования с вашей стороны. Впрочем, есть и недостатки — хотя в большинстве случаев сгенерированное изображение в оттенках серого выглядит
620 Глава 11. Нетривиальное использование растров вполне нормально, результат не идеален. Для получения более точного результата GDI пришлось бы просматривать всю цветовую таблицу в поисках идеального совпадения или оптимального приближения, а это относительно медленный процесс. Судя по результату (что, впрочем, проявляется лишь в изображениях с плавными переходами цветов), GDI использует механизм аппроксимации — вероятно, по соображениям быстродействия. Вместо того чтобы просматривать всю цветовую таблицу в поисках каждого пиксела, можно построить сетку RGB из N х N х N точек. При необходимости каждая точка сетки сопоставляется с элементом цветовой таблицы. Каждый пиксел RGB, сгенерированный в результате растровой операции, аппроксимируется ближайшей точкой сетки, индекс которой и считается цветовым индексом пиксела. Реализация полноценного алгоритма деления изображения на цветовые каналы требует операций непосредственно с массивом пикселов. Мы вернемся к этой теме позднее. Без источника: PATINVERT Из 10 тернарных растровых операций, зависящих от узора и приемника, но не от источника, имя присвоено только операции PATINVERT. Указанные растровые операции обладают теми же возможностями, что и бинарные растровые операции, выбираемые функцией SetR0P2. Операции ROP, в которых не задействован источник, могут использоваться с функциями PatBlt, что позволяет обойтись без более сложных вызовов. Одной из областей их применения является модификация текущего изображения в контексте, соответствующего физическому устройству или блоку памяти, связанному с DDB или DIB-секцией. Например, если у вас имеется черно-белое изображение, вы можете воспользоваться операцией R3_MASKPEN(0xA000C9), чтобы раскрасить его цветной кистью или разделить на каналы RGB. При использовании кисти с шахматным узором операция R3MASKPEN позволяет создать эффект частичного затенения, при котором половина пикселов сохраняет прежний цвет, а другая половина закрашивается черным цветом. Тернарные операции без узора Следующая группа растровых операций использует источник и приемник, но не использует узор. Из 10 возможных растровых операций этой категории имена присвоены 6. Вероятно, Microsoft считает эти операции более важными. Наличие имени у тернарной растровой операции обычно означает, что она требуется самой операционной системе. Операции SRCAND и SRC INVERT используются Windows при отображении значков и курсоров мыши. Ресурс значка/курсора обычно содержит группу изображений для разных вариантов размера и цветовой глубины. Каждый значок/курсор обычно состоит из двух растров: черно-белой маски и цветной маски. Черно-белый значок или курсор может состоять из одного растра двойной высоты; в этом случае выводимый растр описывается второй половиной растра. Маска выводится растровой операцией SRCAND и стирает ту область, в которой будет находиться цветной растр. После этого цветной растр выводится операцией SRC INVERT. Следующий фрагмент поможет вам лучше разобраться в применении растровых операций при выводе значка:
Тернарные растровые операции 621 HICON hlcon = (HICON) LoadImage(hMod. MAKEINTRESOURCE(resid). IMAGE_ICON, 48, 48. LR_DEFAULTCOLOR); if ( hlcon) { DrawIcon(hDC. x. y. hlcon); ICONINFO iconinfo; GetIconInfo(hIcon. & iconinfo); Destroylcon(hlcon); BITMAP bmp; GetObject(iconinfo.hbmMask, sizeof(bmp), & bmp); HGDIOBJ hOld = SelectObject(hMemDC. iconinfo.hbmMask); BitBltChDC, x+56. y. bmp.bmWidth, bmp.bmHeight. hMemDC.O.O.SRCCOPY); Sel ectObject(hMemDC. i coni nfо.hbmColor): BitBltChDC. x+112. y. bmp.bmWidth. bmp.bmHeight. hMemDC.O.O.SRCCOPY); SelectObject(hMemDC. iconinfo.hbmMask); BitBltChDC. x+168, y. bmp.bmWidth. bmp.bmHeight. hMemDC.0.0.SRCAND); SelectObject(hMemDC. i coni nfo.hbmColor); BitBltChDC. x+168, y. bmp.bmWidth. bmp.bmHeight. hMemDC.0.0.SRCINVERT); SelectObjectChMemDC. hOld); DeleteObject(i coni nfo.hbmMask); DeleteObject(i coni nfo.hbmColor); } Программа загружает значок размером 48 х 48 из модуля Loadlmage и выводит его стандартной функцией Win32 Drawl con; при этом значок масштабируется по своим стандартным размерам (обычно 32 х 32). Для удовлетворения нашего любопытства вызывается функция Getlconlnfo, возвращающая манипуляторы двух DDB-растров — маски и цветного растра. Затем эти два растра выводятся по отдельности, чтобы мы могли присмотреться к ним поближе. Далее вывод значка имитируется выводом обоих растров в одном и том же месте. При выводе маски используется растровая операция SRCAND, а при выводе цветного растра — операция SRCINVERT. На рис. 11.3 показано строение некоторых значков, используемых в графической среде Windows. Прежде чем продолжить обсуждение, давайте определимся с некоторыми терминами. При выводе значка, определенного в виде прямоугольной области, некоторые пикселы этой области должны изменяться, а некоторые должны оставаться прежними. Изменяемая область называется непрозрачной (opaque); все остальные пикселы образуют прозрачную область. Обычно непрозрачная область определяет форму значка — например, мусорной корзины или папки. Из рисунка видно, что в маске непрозрачная область обозначается черным цветом (0), а прозрачная — белым цветом (1). Таким образом, первый вызов BitBU, использующий растровую операцию SRCAND, закрашивает непрозрачную область черным цветом и оставляет прозрачную область без изменений. В цветном растре непрозрачная область заполнена цветными пикселами, а в прозрачной области находятся черные пикселы (0). Второй вызов BitBlt с использованием операции SRCINVERT выводит цветные пикселы без изменения прозрачной области.
622 Глава 11. Нетривиальное использование растров Рис. 11.3. Применение растровых операций при выводе значков Если бы при создании маски непрозрачная область описывалась белым цветом (1), а для прозрачной области был зарезервирован черный цвет (0), для очистки непрозрачной области вместо SRCAND следовало бы использовать растровую операцию 0x220326 (DSna). Обратите внимание: оператор NOT в DSna фактически инвертирует маску в процессе применения. Маска и цветной растр могут иметь разные непрозрачные области. Если непрозрачная область маски меньше непрозрачной области цветного растра, при использовании второй растровой операции некоторые пикселы непрозрачной области не закрашиваются черным цветом (1); операция SRCINVERT заменяет пиксел приемника значением D^S вместо S. С другой стороны, при совпадении непрозрачных областей того же результата можно добиться растровой операцией SRCPAINT (DSo). А что произойдет, если маска выглядит так, как показано на рис. 11.3, а прозрачные пикселы цветного растра окрашены в белый цвет (1) вместо черного (0)? В результате применения SRCAND и SRCINVERT прозрачные пикселы инвертируются вместо того, чтобы оставаться неизменными. Мы должны заменить первую растровую операцию, применяющую маску, на SRCERASE (SDna). Если в маске поменялись цвета, первая растровая операция должна быть заменена на N0TSRCERASE (SDon). Для вывода инвертированного источника можно воспользоваться растровой операцией MERGEPAINT (~S|D, DSno). Итак, мы нашли применения для всех шести тернарных растровых операций, не использующих узора, которым компания Microsoft присвоила имена. Если вы не полностью разобрались в том, как работают эти операции, в табл. 11.2 приведена краткая сводка их применения для вывода маски и цветного растра в разных условиях. В таблице для обозначения пикселов растра используется запись (X,Y), где X — цвет прозрачных пикселов, a Y — цвет непрозрачных пикселов. Таким образом, первая строка таблицы читается следующим образом: если в маске прозрачная область обозначена белыми пикселами, а непрозрачная область обозначена черными пикселами, после вывода маски операцией SRCAND прозрачная область остается без изменений, а непрозрачная область окрашивается в черный цвет. Затем цветной растр, в котором прозрачная область обозначена черным цветом,
Тернарные растровые операции 623 выводится растровой операцией SRC INVERT; в результате пикселы непрозрачной области заменяются пикселами цветного растра, а пикселы прозрачной области сохраняют прежнее состояние. Таблица 11.2. Прозрачное отображение растров с применением маски Маска (Белый, черный) (Белый, черный) (Белый, черный) (Черный, белый) (Белый, черный) (Черный, белый) ROP маски SRCAND SRCAND SRCAND R3_DSna SRCERASE NOTSRCERASE Результат применения маски (D, черный) (D, черный) (D, черный) (D, черный) (Dn, черный) (Dn, черный) Цветной растр (Черный, С) (Черный, С) (Белый, С) (Черный, С) (Белый, С) (Белый, С) ROP цветного растра SRCINVERT SRCPAINT MERGEPAINT SRCINVERT SRCINVERT SRCINVERT Итоговые результат <D,C) (D,C) (D,C) (D,C) (D,C) (D,C) Другие растровые операции Мы рассмотрели тернарные растровые операции, не зависящие от узора, источника или кисти, а также зависящие от одного или двух факторов. Общее количество растровых операций этих операций равно 2 + 2x3+ 10x3 = 38. Остальные 218 растровых операций зависят от всех трех переменных. Из этих 218 операций в GDI имя было присвоено только операции PATPAINT (P|~S|D). Операция PATPAINT объединяет пиксел кисти, инвертированный пиксел источника и пиксел приемника логическим оператором OR. He зная условий, которым должны подчиняться эти переменные, трудно понять, зачем нужна подобная растровая операция. Пока оставим PATPAINT в покое и займемся другими операциями, для которых можно найти практическое применение. В одном из способов рисования прозрачных растров используются два растра: маска и цветной растр-источник (см. выше пример с выводом значков). Недостаток подобного решения заключается в необходимости создания маски, точно совпадающей с пикселами цветного растра. А если определить маску в виде кисти вместо отдельного растра? Предположим, мы создали шахматный узор, в котором половина пикселов окрашена в черный цвет, а другая половина остается белой. Можно ли вывести на поверхности устройства лишь каждый второй пиксел цветного растра, не изменяя второй половины? Какую растровую операцию следует для этого применить? Нужная операция легко вычисляется при помощи булевой алгебры. Эффект, которого мы хотим добиться, описывается формулой (P&S)| (-P&D): если пиксел
624 Глава 11. Нетривиальное использование растров кисти равен 1 (белый), результат совпадает с пикселом растра-источника; в противном случае используется пиксел приемника. Заменяя Р, S и D кодами OxFO, ОхСС и ОхАА, мы получаем ОхСА. По таблице тернарных растровых операций мы находим полный код операции 0хСА07А9 и официальную формулу D^(P&(S4D)). Чтобы перейти к противоположной интерпретации Р, формула принимает вид (-P&S) | (P&D); ей соответствует код ОхАС. В результате мы получаем 0хАС0744 и официальную формулу S*(P&(S*D)). Функция Fadeln, приведенная в листинге 11.2, при помощи растровой операции 0хСА07А9 создает эффект «постепенного проявления». Исходное изображение выводится за четыре шага с применением разных узорных кистей. На первом шаге проявляется 1/64 пикселов исходного изображения, на втором — 4/64, на третьем — 16/64, на последнем — все пикселы. Листинг 11.2. Постепенное проявление растра с использованием растровых операций // Постепенное отображение DIB на приемной поверхности за 4 шага void FadeIn(HDC hDC. int x, int y, int w. int h. const BITMAPINFO * pBMI. const void * pBits) { const WORD Maskll[8] = { 0x80. 0x00. 0x00. 0x00. 0x00. 0x00. 0x00. 0x00 }; const WORD Mask22[8] = { 0x88. 0x00. 0x00. 0x00. 0x88. 0x00. 0x00. 0x00 }; const WORD Mask44[8] = { OxAA. 0x00. OxAA. 0x00. OxAA. 0x00. OxAA. 0x00 }; const WORD Mask88[8] - { OxFF. OxFF. OxFF. OxFF. OxFF. OxFF. OxFF. OxFF }; const WORD * Mask[4] - { Maskll. Mask22. Mask44. Mask88 }; for (int i=0; i<4; i++) { HBITMAP hMask - CreateBitmap(8. 8. 1. 1. Mask[i]); HBRUSH hBrush= CreatePatternBrush(hMask); DeleteObject(hMask); HGDIOBJ hOld = SelectObject(hDC. hBrush); // D"(P&(S"D)). if P then S else D StretchDIBits(hDC, x. y. w. h. 0. 0. w. h. pBits. pBMI. DIB_RGB_C0L0RS. 0xCA07A9); SelectObject(hDC. hOld): DeleteObject(hBrush); } } Выше рассматривался вывод значков с применением растровых операций SRCAND и SRCINVERT за два вызова функции BitBlt. В системе семейства Windows NT можно было бы создать узорную кисть на базе маски и объединить два вызова в один, используя при этом растровую операцию (D&PKS с кодом 0х6С01Е8. Эта идея реализована в следующем фрагменте.
Тернарные растровые операции 625 void MaskBitmapNTCHDC hDC, int x, int y, int width, int height. HBITMAP hMask. HDC hMemDC) { HBRUSH hBrush = CreatePatternBrush(hMask); HGDIOBJ hOld - SelectObject(hDC, hBrush); POINT org - { x, у }; LPtoDP(hDC, &org, 1); SetBrushOrgEx(hDC. org.x. org.y, NULL); BitBUChDC. x. y, width, height. hMemDC. 0. 0, 0x6C01E8); // S4P&D) SelectObject(hDC. hOld); DeleteObject(hBrush); } В системах семейства Windows 95 не поддерживаются узорные кисти больше 8 х 8 пикселов. Кроме того, из-за перемещения маски в узорную кисть эта функция будет нормально работать только в режиме отображения ММ_ТЕХТ, поскольку узорная кисть не масштабируется вместе с режимами отображения и мировыми преобразованиями. Для монохромного растра-источника можно воспользоваться цветной кистью, чтобы раскрасить растр и вывести его с использованием прозрачности. Если мы хотим, чтобы черные пикселы (0) источника выводились цветом кисти, а белые пикселы (1) оставались прозрачными, следует воспользоваться формулой (-S&P) | (S&D). ROP-код этой операции равен 0хВ8, или 0хВ8074А, а официальная формула имеет вид PA(S&(P4D)). При противоположной интерпретации растра-источника формула принимает вид (S&P) | (-S&D), и в итоге мы получаем код 0хЕ20746 с официальной формулой D^(S&(P^D)). Листинг 11.3 демонстрирует применение растровой операции 0хВ8074А для раскраски непрозрачных пикселов монохромного растра произвольной кистью. Функция ColorBitmap осуществляет вывод с ROP-кодом 0хВ8074А, а функция TestColoring иллюстрирует раскраску монохромного растра пятью разными кистями. Листинг 11.3. Раскраска монохромного растра с применением растровых операций void ColorBitmap(HDC hDC, int x, int y. int w, int h. HDC hMemDC, HBRUSH hBrush) { // PA(S&(PAD)). if (S) D else P HGDIOBJ hOldBrush - SelectObjectChDC, hBrush): BitBltChDC. x. y. w. h. hMemDC. 0. 0. 0xB8074A); SelectObject(hDC. hOldBrush); } void TestColoring(HDC hDC. HINSTANCE hlnstance) { HBITMAP hPttrn; HBITMAP hBitmap - LoadBitmap(hInstance. MAKEINTRESOURCE(IDB_CONFUSE)); BITMAP bmp; GetObject(hBitmap, sizeof(bmp). &bmp); Продолжение^
626 Глава 11. Нетривиальное использование растров } Листинг 11.3. Продолжение SetTextColor(hDC. RGB(0, 0. 0)); SetBkColorChDC. RGBCOxFF. OxFF. OxFF)); HDC hMemDC = CreateCompatibleDC(NULL); HGDIOBJ hOld = SelectObject(hMemDC. hBitmap); for (int i=0; i<5; i++) { HBRUSH hBrush; switch (i) { case 0: hBrush - CreateSolidBrush(RGB(OxFF, 0. 0)): break; case 1: hBrush - CreateSo1idBrush(RGB(0, OxFF, 0)); break; case 2; hPttrn = LoadBitmap(hInstance. MAKEINTRESOURCE(IDB_PATTERN0D); hBrush = CreatePatternBrush(hPttrn); DeleteObject(hPttrn); break; case 3: hBrush = CreateHatchBrush(HS_DIAGCROSS, RGB(0. 0. OxFF)); break; case 4: hPttrn = LoadBitmap(hInstance, MAKEINTRESOURCE(IDB_WOOD01)); hBrush = CreatePatternBrush(hPttrn); DeleteObject(hPttrn); } ColorBitmap(hDC. i*30+10-2. 1*5+10-2. bmp.bmWidth, bmp.bmHeight. hMemDC. (HBRUSH)GetStockObject(WHITE_BRUSH)); ColorBitmap(hDC. i*30+10+2. i*5+10+2. bmp.bmWidth. bmp.bmHeight. hMemDC. (HBRUSH)GetStockObject(DKGRAYJRUSH)); ColorBitmap(hDC. i*30+10. i*5+10, bmp.bmWidth. bmp.bmHeight. hMemDC. hBrush); DeleteObject(hBrush); BitBltChDC. 240. 25. bmp.bmWidth. bmp.bmHeight. hMemDC. 0. 0. SRCCOPY); SelectObject(hMemDC. hOld); DeleteObject(hBitmap); DeleteObject(hMemDC); Функция загружает монохромный растр с изображением одного недоумевающего человечка и рисует группу из пяти человечков. В данном примере использовались белая и черная кисти и небольшое смещение выводимых растров, создающее простейший объемный эффект. Поскольку растровая операция 0хВ8074 рисует растры в прозрачном режиме, выводятся только пикселы непрозрачной области. На рис. 11.4 изображено пять цветных растров вместе с исходным монохромным растром (справа).
Прозрачные растры 627 Рис. 11.4. Прозрачная раскраска монохромного растра Прозрачные растры Даже при таком количестве растровых операций в компании Microsoft полагают, что прозрачный вывод растров — очень сложная задача, поэтому для ее решения были созданы три специальные функции: BOOL PlgBlt(HDC hdcDest. CONST POINT * IpPoint. HDC hDCSrc. int nXSrc, int nYSrc. int nWidth. int nHeight. HBITMAP hbmMask. int xMask. int yMask); BOOL MaskBltCHDC hdcDest. int nXDest. int nYDest, int nWidth, int nHeight. HDC hDCSrc. int nXSrc. int nYSrc. HBITMAP hbmMask. int xMask. int yMask. DWORD dwRop); BOOL TransparentBltCHDC hdcDest. int nXOriginDest. int nYOriginDest. int nWidthDest. int nHeightDest, HDC hdcSrc, int nXOriginSrc. int nYOriginSrc. int nWidthSrc. int nHeightSrc. UINT crTransparent); Эти три функции поддерживаются не на всех платформах Win32. Функции PlgBlt и MaskBIt поддерживаются только в системах семейства Windows NT, а функция TransparentBIt — только в Windows 98, Windows 2000 и последующих системах. Ниже будет показано, как эти функции имитируются на базе других растровых функций и прямого доступа к массиву пикселов. Даже при беглом взгляде на прототипы функций нетрудно заметить сходство между ними. Все функции получают два манипулятора контекстов устройств — для источника и приемника. Следовательно, эти функции работают как с совместимыми контекстами устройств, в которых выбран DDB-растр или DIB-сек- ция, так и с физическими устройствами, поддерживающими растровые операции.
628 Глава И. Нетривиальное использование растров DIB напрямую не поддерживаются; чтобы использовать эти функции, вам придется преобразовать DIB в DDB или в DIB-секцию. Функция PlgBIt Функция PlgBIt решает две задачи: преобразование прямоугольного растра в параллелограмм и управление прозрачностью при помощи маски. Следовательно, результат вызова этой функции определяется тремя факторами: приемником, источником и узором. Исходный прямоугольник представляет собой подмножество точек поверхности-источника, определяемое параметрами nXSrc, nYSrc, nWidth и nHeight. Все параметры задаются в логической системе координат контекста-источника. Как и при использовании других, более простых функций блиттинга, в контексте- источнике не могут действовать преобразования поворота и сдвига, однако смещение, масштабирование и зеркальные отражения допускаются. Это ограничение гарантирует, что исходный прямоугольник в системе координат устройства контекста-источника всегда соответствует прямоугольнику, стороны которого параллельны обеим осям. Параллелограмм-приемник определяется манипулятором контекста устройства и массивом из трех точек. Выше уже говорилось о том, что аффинное преобразование однозначно определяется отображением трех точек одного пространства в три точки другого пространства. Три точки, на которые ссылается параметр lpPoint, однозначно определяют параллелограмм на приемной поверхности, четвертая вершина которого вычисляется по формуле D = В + С - А, где А = lpPoint[0], В = lpPoint[l] и С = lpPoint[2]. Левый верхний угол исходного прямоугольника отображается в А, правый верхний угол отображается в точку В, левый нижний угол отображается в С, а правый нижний — в D. Отображение исходного прямоугольника в приемный параллелограмм представляет собой общее аффинное преобразование, допускающее смещение, масштабирование, отражение, повороты и сдвиги. С геометрической точки зрения функция PlgBIt по сравнению с StretchBlt обеспечивает дополнительные повороты и сдвиги. Растр маски определяется манипулятором растра и двумя целыми числами. Растр должен быть монохромным, в противном случае вызов функции завершится неудачей. Два целых параметра xMask и yMask определяют местонахождение пиксела маски, соответствующего левому верхнему углу растра-источника. При выходе за границы маски она применяется повторно — так же, как узорная кисть используется при заливке замкнутых областей. Если маска не задана, в приемном параллелограмме отображается все содержимое источника. В противном случае пикселы маски со значением 1 (белый) соответствуют участкам, копируемым из источника в приемник, а пикселы маски со значением 0 (черный) оставляют пикселы приемника без изменений. Если преобразовать маску в узорную кисть, логика ее применения выражалась бы растровой операцией с кодом 0хСА07А9, то есть P&S|~P&D. В системах семейства Windows NT функция PlgBIt может быть заменена функцией StretchBlt с настройкой мирового преобразования, преобразованием маски в узорную кисть и использованием растровой операции 0хСА07А9. В других
Прозрачные растры 629 системах StretchBlt может заменить PlgBlt лишь при отсутствии поворотов и сдвигов и при условии, что размеры маски не превышают 8x8 пикселов. В листинге 11.4 приведен пример использования функции PlgBlt для вывода объемного куба. Функция DrawCube рисует три грани куба функцией PlgBlt с применением источника и маски. Функция MaskCube управляет созданием маски в форме прямоугольника с закругленными углами, размер которой совпадает с размерами растра-источника. Листинг 11.4. Рисование трехмерного куба с использованием функции PlgBlt void DrawCubeCHDC hDC, int x. int y, int dh. int dx, int dy. HDC hMemDC. int w. int h. HBITMAP hMask) { SetStretchBltMode(hDC. HALFTONE); // 6 // 0 4 // 1 111 5 // 3 POINT P[3] - { { x - dx, у - dy }. { x, у }. { x - dx, у - dy + dh } }; //012 POINT Q[3] - { { x. у }. { x + dx, у - dy }. { x, у + dh } }; //143 POINT R[3] = { { x - dx, у - dy }, { x, у - dy - dy }. { x, у } }; // 061 PlgBltChDC. P. hMemDC. 0. 0, w. h. hMask. 0, 0) PlgBlt(hDC. Q. hMemDC. 0. 0. w. h, hMask, 0. 0) PlgBltChDC. R. hMemDC, 0. 0. w. h. hMask. 0. 0) void MaskCube(HDC hDC. int size, int x. int y. int w. int h. HBITMAP hBmp. HDC hMemDC. bool mask, bool bSimulate) { HBITMAP hMask - NULL; if ( mask ) hMask = CreateBitmap(w, h, 1. 1. NULL); SelectObject(hMemDC, hMask); PatBltChMemDC. 0, 0, w, h. BLACKNESS); RoundRect(hMemDC. 0. 0, w. h. w/2. h/2); } int dx - size * 94 / 100; // cos(20) int dy - size * 34 / 100; // sin(20) SelectObjectChMemDC. hBmp); DrawCube(hDC. x+dx. y+size, size, dx, dy, hMemDC, w, h, hMask); if ( hMask ) DeleteObject(hMask);
630 Глава 11. Нетривиальное использование растров На рис. 11.5 изображен результат вывода двух кубов. Первый куб рисуется с деревянной текстурой без маски, в результате чего изображение получается однородным. На гранях второго куба выводится растр, сгенерированный программой для построения множества Мандельброта, с маской в виде прямоугольника с закругленными углами. Рис. 11.5. Трехмерный куб, созданный с помощью функции PlgBIt Эффектно, не правда ли? К сожалению, программа работает только в системах семейства NT (даже не в Windows 98!). Чтобы вы лучше усвоили описанные выше возможности GDI, было бы полезно создать реализацию PlgBIt, работающую на всех платформах Win32. Давайте попробуем это сделать. В листинге 11.5 приведена функция G_P1gB1t, имитирующая PlgBIt. Листинг 11.5. Реализация PlgBIt BOOL G_PlgBlt(HDC hdcDest. const POINT * pPoint. HDC hdcSrc. int nXSrc. int nYSrc, int nWidth. int nHeight. HBITMAP hbmMask, int xMask. int yMask) { KReverseAffine map(pPoint); if ( map.SimpleO ) // Отсутствие сдвига и поворота { int x - pPoint[0].x; int у = pPoint[0].y; int w - pPoint[l].x-pPoint[0].x; int h - pPoint[2].y-pPoint[0].y; if ( hbmMask ) // маска: if (M) the S else D, S A (~M & (SAD))
Прозрачные растры 631 { StretchBltChdcDest. х, у. w. h. hdcSrc. nXSrc. nYSrc. nWidth, nHeight, SRCINVERT); StretchTileChdcDest. x. y. w. h. hbmMask. xMask. yMask. nWidth. nHeight. 0x220326); return StretchBltChdcDest. x. y. w. h. hdcSrc. nXSrc. nYSrc. nWidth. nHeight. SRCINVERT); } else return StretchBltChdcDest. x. y. w. h. hdcSrc. nXSrc. nYSrc. nWidth. nHeight. SRCCOPY); } map.Setup(nXSrc. nYSrc. nWidth. nHeight): HDC hdcMask - NULL; int maskwidth - 0; int maskheight= 0; if ( hbmMask ) { BITMAP bmp; GetObjectChbmMask. sizeof(bmp). & bmp); maskwidth = bmp.bmWidth; maskheight = bmp.bmHeight; hdcMask « CreateCompatibleDC(NULL): SelectObjectChdcMask. hbmMask); } for Сint dy=map.miny; dy<=map.maxy; dy++) for (int dx^map.minx; dx<=map.maxx; dx++) { float sx. sy; map.MapCdx. dy. sx. sy); if ( Csx>=nXSrc) && (sx<=(nXSrc+nWidth)) ) if ( (sy>=nYSrc) && (sy<=(nYSrc+nHeight)) ) if ( hbmMask ) { if ( GetPixel(hdcMask. ((int)sx+xMask) % maskwidth. Uint)sy+yMask) % maskheight) ) SetPixeKhdcDest. dx. dy. GetPixeKhdcSrc. (int)sx. (int)sy)); } else SetPixeKhdcDest. dx. dy. GetPixeKhdcSrc. (int)sx, (int)sy)); } if ( hdcMask ) DeleteObject(hdcMask); return TRUE; }
632 Глава 11. Нетривиальное использование растров Сначала рассмотрим случай без поворотов и сдвигов. При отсутствии сдвигов и поворотов PlgBlt реализуется несколькими вызовами StretchBlt с простыми растровыми операциями. Функция G_PlgBlt создает в стеке экземпляр класса KReverseAffine, выполняющего преобразование. Если преобразования сдвига и поворота не выполняются, метод KReverseAffine: :Simple возвращает TRUE. Функция проверяет, был ли передан при вызове действительный манипулятор маски, и если не был — вызывает StretchBlt с операцией SRCC0PY. Если маска передается, мы должны имитировать ее несколькими вызовами функций. Вспомните, что говорилось выше: если пиксел маски окрашен в белый (1) цвет, пиксел приемника заменяется пикселом источника; в противном случае пиксел приемника остается без изменений. В булевой алгебре эта операция выражается формулой M&S|~S&D, или D^(M&(S^D)). При прямой реализации этой формулы нам потребуется промежуточный растр, поскольку D используется дважды. Но если перейти к формуле S^(~M&(S^D)), S будет использоваться дважды, a D — только один раз. Из формулы видно, как реализовать семантику применения маски. Сначала D преобразуется в S^D операцией SRC INVERT, затем новый приемник D объединяется с ~М операцией AND, после чего выполняется еще одна операция SRC INVERT с S. Для второй операции маска играет роль источника с учетом возможного мозаичного повторения. Для выполнения операции -S&D используется безымянная операция с ROP-кодом 0x220326. Обратите внимание: при выводе растра маски используется функция Stretch- Ti I e, обеспечивающая мозаичное повторение маски на приемной поверхности. Если используется преобразование сдвига или поворота, нам придется поработать по-настоящему. Программа вызывает метод KReverseAffine::Setup для настройки обратного аффинного преобразования из параллелограмма приемной поверхности в прямоугольник поверхности-источника. Этот способ очень часто применяется при обработке поворотов и сдвигов растров. При отображении пикселов источника на приемную поверхность при растяжении возникают пробелы, а сжатие приведет к дублированию вычислений. Следуя в обратном направлении, от приемника к источнику, мы гарантируем, что каждый пиксел приемника будет обработан, и притом ровно один раз; растяжение и сжатие при этом обрабатывается автоматически. Функция Setup также вычисляет ограничивающий прямоугольник для приемного параллелограмма. После подготовки совместимого контекста устройства для маски программа начинает в цикле перебирать все точки в ограничивающем прямоугольнике параллелограмма. При этом программа отображает каждую точку прямоугольника в координатное пространство растра-источника и проверяет ее принадлежность исходному прямоугольнику (поскольку ограничивающий прямоугольник больше параллелограмма). При хранении координат отображенной точки приемника и сравнениях с границами источника используются вещественные числа. Слишком ранний переход к целым числам приведет к ошибкам при выводе некоторых граничных пикселов вследствие погрешностей округления. Если точка принадлежит исходному прямоугольнику, значит, она входит и в параллелограмм, поэтому мы переходим к вычислению значения пиксела. При наличии маски программа читает соответствующий пиксел маски. Если этот пиксел окрашен в белый (1) цвет, пиксел источника выводится на приемной поверхности; в противном случае приемник не изменяется. Тем самым мы успеш-
Прозрачные растры 633 но реализовали семантику применения маски. Если маска не задана, пиксел источника просто копируется в приемник. Обратите внимание на прибавление xMask и yMask к координатам растра-источника — тем самым мы учитываем относительный сдвиг маски. Мозаичный эффект достигается вычислением остатка от деления координаты на соответствующий размер маски. Вспомогательный код и класс KReverseAffine приведены в листинге 11.6. Листинг 11.6. Вспомогательный код и класс для имитации PlgBIt // Параметры dx, dy, dw. dh определяют приемный прямоугольник // Параметры sw. sh определяют размеры прямоугольника-источника // Параметры sx. sy определяют начальную точку в растре-источнике, // который дублируется до размеров sw x sh BOOL StretchTile(HDC hDC. int dx. int dy. int dw. int dh. HBITMAP hSrc. int sx. int sy. int sw. int sh. DWORD гор) { BITMAP bmp; if ( ! GetObject(hSrc, sizeof(BITMAP). & bmp) ) return FALSE; HDC hMemDC = CreateCompatibleDC(NULL); HGDIOBJ hOld = SelectObject(hMemDC. hSrc); int syO = sy % bmp.bmHeight; // Смещение текущей плитки // по оси у for (int y=0; y<sh; у+=(bmp.bmHeight - syO)) { int height = min(bmp.bmHeight - syO. sh - y) int sxO = sx % bmp.bmWidth; for (int x=0; x<sw; x+=(bmp.bmWidth - sxO)) { int width = min(bmp.bmWidth - sxO. sw - x): // Текущая // ширина плитки StretchBlt(hDC. dx+x*dw/sw, dy+y*dh/sh, dw*width/sw. dh*height/sh. hMemDC, sxO. syO, width, height, гор); sxO = 0; // После первой плитки в ряду перейти к полной ширине } syO = 0; // После первого ряда перейти к полной высоте плиток } SelectObjectChMemDC. hOld); DeleteObject(hMemDC); Продолжение & // Текущая высота // плитки // Смещение текущей // плитки по оси х
634 Глава 11. Нетривиальное использование растров Листинг 11.6. Продолжение return TRUE; void minmaxdnt xO. int xl. int x2. int x3. int & minx, int & maxx) { if ( xO<xl ) { minx = xO; maxx = xl; } else { minx = xl; maxx = xO; } if ( x2<minx) minx = x2; else if ( x2>maxx) maxx = x2; if ( x3<minx) minx = x3; else if ( x3>maxx) maxx - x3; class KReverseAffine : public KAffine { int xO. yO. xl. yl. x2. y2; public: int minx, maxx, miny. maxy; KReverseAffine(const POINT * pPoint) { xO - pPoint[0].x: // Р0 PI yO - pPoint[0].y; // xl - pPoint[l].x; // yl - pPoint[l].y; // P2 P3 x2 - pPoint[2].x; y2 - pPoint[2].y; } bool Simple(void) const { return (yO--yl) && (x0==x2); } void Setup(int nXSrc, int nYSrc, int nWidth. int nHeight) { MapTri(xO. yO. xl. yl. x2, y2. nXSrc. nYSrc, nXSrc+nWidth, nYSrc. nXSrc. nYSrc+nHeight); minmax(xO. xl. x2, x2 + xl - xO. minx, maxx); minmax(yO, yl, y2. y2 + yl - yO. miny. maxy): Мы только что реализовали свой первый алгоритм с поддержкой поворотов и сдвигов, а также создали замену для мощной функции PlgBlt. Если выполнить эту программу, она построит почти такой же объемный куб, как на рис. 11.5. Правда, работает она примерно в 7 раз медленнее, поскольку в ней используются медленные функции GetPixel/SetPixel. Позднее в этой главе будут описаны приемы прямого доступа к пикселам, заметно повышающие быстродействие программы.
Прозрачные растры 635 Кватернарные растровые операции: MaskBIt Вероятно, какому-то высшему существу из Microsoft показалось, что тернарные растровые операции недостаточно сложны, поэтому к ним нужно добавить кватернарные растровые операции, зависящие от четырех переменных. Это выглядит довольно странно, учитывая, что в GDI имя было присвоено лишь одной тернарной растровой операции, зависящей от узора, источника и приемника — PATPAINT (P|~S|D). Мы даже не знаем, как использовать PATPAINT, хотя в предыдущем разделе было продемонстрировано применение некоторых тернарных операций, зависящих от всех трех переменных. Код тернарной растровой операции можно рассматривать как комбинацию кодов^ двух бинарных растровых операций. Старшая половина кода тернарной растровой операции используется в тех случаях, когда Р = 1; младшая половина используется, когда Р = 0. Для примера рассмотрим растровую операцию тождественной замены с кодом ОхАА; как старшая, так и младшая половина равна ОхА. Следовательно, результат растровой операции вообще не зависит от кисти. Код D равен ОхА, поэтому результат всегда представляет собой D, то есть исходное состояние приемника. Теперь рассмотрим операцию PATINVERT с кодом 0х5А. Старшая половина равна 0x5, а младшая — ОхА. Следовательно, когда Р - 1, используется растровая операция ~D, а когда Р = 0 — операция D, что дает PXD. Четвертым фактором в кватернарных растровых операциях является монохромный растр маски. Код кватернарной растровой операции состоит из двух кодов тернарных операций: основной и фоновой. Основная операция используется, если пиксел маски равен 1, а фоновая операция используется для пикселов маски, равных 0. В GDI определен макрос MAKER0P4, объединяющий два 24-разрядных тернарных кода в один 32-разрядный кватернарный код. #define MAKER0P4(fore, back) (DWORD) ((((back)«8) & OxFFOOOOOO) | (fore) Макрос берет 8-разрядный индекс растровой операции, сдвигает его 8 бит влево и объединяет с 24-разрядным кодом основной операции. В результате образуется 32-разрядный код кватернарной операции. Структура кватернарного ROP- кода изображена на рис. 11.6. Полный код основной операции 24 бита k-Кодировка формулы основной операции 16 бит-Н / ' '" ' ' >| Индекс : фоновой операции Индекс основной операции ' ^ Ор5 Ор4 ОрЗ Ор2 Ор1 Not ( N Parse String Offset k Полный код кватернарной операции 32 бита ► Рис. 11.6. Код кватернарной растровой операции Маска в кватернарных операциях не является равноправным фактором, поскольку она ограничивается всего двумя значениями: 1 (белый) и 0 (черный). Вы не сможете создать цветную маску, цветные пикселы которой будут объединяться с цветными пикселами кисти, источника и приемника. Кватернарные
636 Глава 11. Нетривиальное использование растров операции создавались прежде всего как простое и эффективное средство прозрачного вывода растров, a MaskBU — единственная функция GDI, получающая код кватернарной растровой операции. Понять, как работает функция MaskBU, не так уж сложно. Первые пять параметров определяют прямоугольник на приемной поверхности. Следующие три параметра определяют прямоугольник на поверхности источника, размеры которого совпадают с размерами приемной поверхности. Это те же восемь параметров, которые используются в BitBU. Впрочем, парной функции StretchMaskBlt (по аналогии с парой BitBU/StretchBU) не существует. Если приложение хочет выполнить масштабирование при вызове MaskBU, оно должно соответствующим образом настроить логические системы координат. Следующие три параметра, hbmMask, xMask и yMask, определяют растр маски. Маска дублируется по мозаичному принципу по аналогии с маской PlgBU. Последний параметр MaskBU определяет кватернарную растровую операцию. Если пиксел маски равен 1, новый пиксел приемной поверхности определяется пикселами кисти, источника и приемника, объединенными основной растровой операцией; в противном случае используется фоновая растровая операция. Найти хороший пример, демонстрирующий применение MaskBU, непросто, поэтому мы снова воспользуемся примером с выводом значков: void MaskBltDrawIcon(HDC hDC. int x, int y, HICON hlcon) { ICONINFO iconinfo; GetIconInfo(hIcon, & iconinfo); BITMAP bmp; GetObject(iconinfo.hbmMask. sizeof(bmp), & bmp); HDC hMemDC - CreateCompatibleDC(NULL); HGDIOBJ hOld = SelectObjectChMemDC. iconinfo.hbmColor); MaskBltChDC. x. y. bmp.bmWidth, bmp.bmHeight, hMemDC. 0,0. iconinfo.hbmMask. 0. 0. MAKER0P4(SRCINVERT. SRCCOPY)); SelectObject(hMemDC. hOld); DeleteObject(i coni nfо.hbmMask); DeleteObject(i coni nfо.hbmColor); DeleteObject(hMemDC); } В отличие от предыдущей программы мы обошлись всего одним вызовом функции. По сравнению с функцией MaskBitmapNT, использующей узорную кисть и экзотическую растровую операцию 0х6С01Е8 (SX(PXD)), мы передаем маску непосредственно при вызове MaskBU без применения узорной кисти. В этом примере используется кватернарная растровая операция MAKER0P4 (SRC IN VERT, SRCCOPY), которая выполняет логическую операцию XOR для пикселов маски, равных 1, и простое копирование для нулевых пикселов маски. Эти операции соответствуют правилам вывода значков. На практике единичным основным пикселам соответствуют нулевые пикселы цветного растра, поэтому операция XOR не изменяет пиксела приемника.
Прозрачные растры 637 Имитация MaskBlt Функция MaskBlt обеспечивает простую концептуальную модель выполнения различных растровых операций с основными и фоновыми пикселами. К сожалению, приложения, использующие MaskBlt, работают только в операционных системах семейства Windows NT. В этом разделе мы разработаем модель функции MaskBlt для других систем. Моделирование MaskBlt — очень хорошее упражнение, позволяющее лучше разобраться в применении растровых операций. Сразу договоримся, что мы не будем реализовывать растровые операции на уровне пикселов, поскольку для этого нам потребуется запрограммировать все 256 тернарных растровых операций, от которых зависит функция MaskBlt. Вместо этого мы попробуем имитировать MaskBlt при помощи нескольких тернарных операций. Конечно, это приведет к некоторому снижению быстродействия, но потери оправдываются познавательной ценностью такого упражнения. Функция GMaskBlt (листинг 11.7) полностью реализует все возможности BitBlt. Задача разбивается на несколько подзадач — от простых, использующих не более трех растровых операций, до более общих, требующих временного растра и шести растровых операций. Функция сначала извлекает из кода кватернарной ROP индексы основной и фоновой операции. Как было сказано выше, функция MaskBlt должна использовать основную растровую операцию для единичных пикселов маски (белых) и фоновую операцию для нулевых пикселов (черных). Следовательно, наша реализация должна быть ориентирована на выполнение двух ROP: основной и фоновой. Листинг 11.7. Имитация MaskBlt BOOL TriBitBlt(HDC hdcDest. int nXDest. int nYDest, int nWidth, int nHeight, HDC hdcSrc. int nXSrc, int nYSrc, HBITMAP hbmMask. int xMask, int yMask, DWORD ropl. DWORD rop2. DWORD rop3) { HDC hMemDC = CreateCompatibleDC(hdcDest); SelectObject(hMemDC, hbmMask); if ( (ropl»16)!=0xAA ) // not D BitBlt(hdcDest, nXDest. nYDest. nWidth. nHeight, hdcSrc, nXSrc. nYSrc, ropl); BitBlt(hdcDest. nXDest, nYDest. nWidth, nHeight. hMemDC. xMask, yMask. rop2); Del eteObjectC hMemDC); if ( (rop3»16)!=0xAA ) // not D return BitBltChdcDest. nXDest. nYDest. nWidth. nHeight. hdcSrc, nXSrc, nYSrc. rop3); else return TRUE; } inline bool D_independent(DWORD гор)
638 Глава 11. Нетривиальное использование растров return ((OxAA & гор)»1)== (0x55 & гор); } inline boo! S_independent(DWORD гор) { return ((OxCC & rop)»2)== (0x33 & гор): BOOL G_MaskBlt(HDC hdcDest, int nXDest, int nYDest. int nWidth. int nHeight. HDC hdcSrc. int nXSrc. int nYSrc. HBITMAP hbmMask. int xMask. int yMask, DWORD dwRop ) DWORD back = (dwRop » 24) & OxFF; DWORD fore = (dwRop » 16) & OxFF; if ( back==fore ) // основная операция совпадает с фоновой. // маска hbmMask не нужна return BitBlt(hdcDest. nXDest, nYDest. nWidth. nHeight. hdcSrc. nXSrc. nYSrc, dwRop & OxFFFFFF); // if (M) D=fore(P.S.D) else D=back(P.S.D) if ( D_independent(back) ) // Фоновая операция не зависит от D return TriBitBlt(hdcDest. nXDest. nYDest. nWidth, nHeight, hdcSrc. nXSrc. nYSrc. hbmMask. xMask, yMask. fore^back « 16. // ( fore^back. fore^back ) SRCAND, // ( fore'back, 0 ) (back'OxAA) « 16); // { fore, back } if ( D_independent(fore) ) // Основная операция не зависит от D return TriBitBlt(hdcDest. nXDest. nYDest. nWidth. nHeight. hdcSrc. nXSrc. nYSrc, hbmMask. xMask. yMask. (fore^back) « 16, // ( fore^back, fore^back ) 0x22 «16. // ( 0. fore'back ) (fore'OxAA) « 16); // { fore, back } // И основная, и фоновая операция зависят от D if ( S_independent(back) && S_independent(fore) ) return TriBitBlt(hdcDest. nXDest. nYDest. nWidth. nHeight. NULL, 0, 0, hbmMask, xMask, yMask, OxAA « 16. // ( D. D ) ( (fore & OxCC) || (back & 0x33) ) « 16. OxAA « 16); // И основная, и фоновая операция зависят от D // Либо основная, либо фоновая операция зависит от S HBITMAP hTemp = CreateCompatibleBitmap(hdcDest, nWidth, nHeight); HDC hMemDC = CreateCompatibleDC(hdcDest): SelectObject(hMemDC, hTemp); BitBltChMemDC. 0. 0. nWidth. nHeight. hdcDest. nXDest. nYDest, SRCCOPY); SelectObject(hMemDC. GetCurrentObject(hdcDest. 0BJ_BRUSH)); Продолжение^
Прозрачные растры 639 Листинг 11.7. Продолжение BitBlt(hMemDC. О, 0. nWidth. nHeight. hdcSrc, nXSrc, nYSrc. back « 16); // hMemDC содержит итоговое // фоновое изображение BitBltChdcDest. 0, 0. nWidth. nHeight. hdcSrc. nXSrc. nYSrc. fore « 16); // Основное изображение TriBitBlt(hdcDest. nXDest. nYDest. nWidth. nHeight. hMemDC. 0. 0. hbmMask. xMask. yMask. SRCINVERT. // ( fore'back. fore'back ) SRCAND. // ( fore'back, 0 ) SRCINVERT); // { fore, back } DeleteObject(hMemDC); DeleteObject(hTemp); return TRUE; } Если основная растровая операция совпадает с фоновой, растр маски не используется, а задача решается одним вызовом BitBlt. Если фоновая растровая операция не зависит от растра приемника, MaskBlt реализуется не более чем тремя вызовами BitBlt. При первом вызове используется растр-источник и растровая операция «основа XOR фон». При втором вызове используется маска и растровая операция SRCAND, в результате чего приемник переходит в состояние «if (M) (основаАфон) else 0». При третьем вызове используется растр-источник и операция «фон XOR D». В итоге приемная поверхность переходит в состояние «if (M) основа else фон» — именно этого мы и добивались. Рассмотрим пример. Допустим, основная растровая операция имеет формулу DXS, а фоновая — Р. Следовательно, результат, которого мы хотим добиться, — «if (M) DXS else P». Согласно приведенному выше алгоритму, первая растровая операция описывается формулой DXSXP. После применения маски с операцией SRCAND мы переходим к формуле «if (M) DXSXP else 0». Наконец, растр-источник используется повторно с операцией DXP, и результат равен «if (M) DXS else P». Почему мы требуем, чтобы фоновая растровая операция не зависела от приемника? Потому, что первая растровая операция изменяет состояние приемника. Для всех последующих растровых операций, использующих исходное состояние приемника, необходимо создать его копию. Аналогичным образом, если основная растровая операция не зависит от приемника, достаточно использовать в качестве второй операции операцию NOTSRCAND (0x22), а в качестве третьей — (основав). Еще один простой случай — когда и основная, и фоновая операции не зависят от источника. В этом случае мы можем интерпретировать маску как источник, сконструировать новую растровую операцию и выполнить BitBlt при выборе маски в совместимом контексте устройства. Индекс ROP вычисляется по формуле (основа&0хСС)|(фон&0хЗЗ), где ОхСС обозначает источник, а ОхЗЗ — «NOT источник». Как видите, мы можем разбирать ROP на составляющие и собирать их заново. Предположим, основной операцией является ROP PATCOPY (OxFO), а фоновой — PATINVERT (0х5А); обе операции не зависят от S. Новая рас-
640 Глава 11. Нетривиальное использование растров тровая операция вычисляется по формуле (0xF0&0xCC)|(0x5A&0x33), то есть 0хС0|0х12 = 0xD2, или PX(D&~S). Обратите внимание: в роли S в данном случае выступает растр маски. Данная формула означает, что для S = 1 должна использоваться операция Р, а для S = 0 — P^D. Если ни основная, ни фоновая операция не относятся к этим простым случаям, возникают проблемы. Мы знаем, что обе растровые операции (основная и фоновая) зависят от приемника, но не можем добиться нужного эффекта одним вызовом BitBlt. После первого вызова BitBlt приемник изменяется, поэтому все последующие ссылки на него будут относиться к измененному, а не к исходному состоянию приемника. Существует единственный выход — создать временный растр, скопировать в него приемную поверхность, а затем построить на ней фоновое изображение. После этого на главной приемной поверхности строится основное изображение, которое объединяется с фоновым изображением с использованием маски. Таким образом, функция MaskBlt моделируется несколькими вызовами BitBlt — от одного до шести. Цветовые ключи: TransparentBIt Обе рассмотренные функции, PlgBlt и MaskBlt, используют монохромный растр- маску для управления выводом растра-источника. Главный недостаток решений, основанных на применении масок, заключается в том, что мы должны создать два идеально совпадающих растра: источник и маску. Маска должна точно соответствовать источнику как по размерам, так и по мельчайшим деталям изображения. Построение этих растров требует большого количества монотонной работы. Решение этой проблемы стоит поискать в Голливуде, у специалистов по визуальным эффектам. В кино уже давно используется методика комбинированных съемок с применением так называемого «синего экрана». Сначала съемка производится на фоне равномерно освещенного экрана синего цвета. В процессе монтажа синий фон заменяется другим изображением-«подложкой». Например, актера можно снять в студии подвешенным на нескольких незаметных шнурах, а потом наложить полученное изображение на изображение неба; получится, что человек парит в воздухе. Кстати, синий цвет — не единственный из возможных, хотя при съемках он используется чаще всего. Существует и другой прием, работающий по тому же принципу, — все участки изображения, яркость которых превышает заданный порог (или наоборот, оказывается ниже его), заменяются участками другого изображения. Эти две методики основаны на применении так называемых цветовых ключей. В GDI на платформах Windows 98 и Windows 2000 поддержка цветовых ключей была представлена новой функцией TransparentBIt. При вызове функция TransparentBIt получает 11 параметров. Первые пять параметров определяют прямоугольник приемной поверхности устройства, следующая пятерка — прямоугольник на поверхности источника, а последний параметр — цветовой ключ, заданный в виде RGB-значения. Функция TransparentBIt копирует на приемную поверхность пикселы источника, не совпадающие с цветовым ключом; при необходимости изображение увеличивается или уменьшается. Обратите внима-
Прозрачные растры 641 ние: функция TransparentBlt, в отличие от StretchBIt, не поддерживает зеркального отражения. Если растр был предварительно обработан для применения цветового ключа, использовать функцию TransparentBlt очень легко. Давайте вернемся к выводу значков, но на этот раз — с помощью функции TransparentBlt. Вспомните: значок состоит из монохромной маски и цветного растра. Прозрачные участки цветного растра обычно окрашиваются в черный цвет. Если черный цвет не встречается в изображении, он обычно выбирается для обозначения прозрачности. Согласно общепринятому правилу, цветовой ключ, как правило, определяется цветом первого пиксела растра. Следующая функция определяет цвет первого пиксела растра значка и передает его в качестве цветового ключа при вызове Transpa- rentBI t. Таким образом, значок выводится всего одной функцией блиттинга. void TransparentBltDrawIconCHDC hDC. int x. int y, HICON hlcon) { ICONINFO iconinfo; GetlconlnfoChlcon, & iconinfo); BITMAP bmp; GetObject(iconinfo.hbmMask, sizeof(bmp). & bmp); HDC hMemDC = CreateCompatibleDC(NULL); HGDIOBJ hOld = SelectObject(hMemDC. iconinfo.hbmColor); COLORREF crTrans = GetPixel(hMemDC. 0. 0); TransparentBlt(hDC. x. y. bmp.bmWidth, bmp.bmHeight. hMemDC. 0. 0. bmp.bmWidth. bmp.bmHeight. crTrans); SelectObject(hMemDC. hOld): DeleteObj ect(i coni nfо.hbmMask): DeleteObject(i coni nfо.hbmCol or); DeleteObject(hMemDC); } Функция TransparentBlt весьма эффектна, особенно учитывая ее «голливудское» происхождение. К сожалению, она поддерживается только в Windows 98, Windows 2000 и последующих системах. В Windows NT 4.0 поддержка TransparentBlt отсутствует. Эта функция экспортируется не из GDI32.DLL, а из MSIM32.DLL, поэтому к вашей программе должна быть подключена дополнительная библиотека MSIMG32.DLL По имеющейся информации, реализация TransparentBlt в Windows 98 приводит к утечке ресурсов, поэтому широко использовать эту функцию не рекомендуется. Короче, у нас достаточно причин для создания собственной реализации, не зависящей от платформы. Имитация TransparentBlt Одним из важнейших этапов в реализации TransparenBIt является построение растра маски по цветовому ключу. Монохромные DDB-растры обладают очень удобными средствами для создания масок. Вспомните: когда цветное изображение преобразуется в монохромный растр, все пикселы, цвет которых совпадает с фоновым цветом приемного контекста, преобразуются в 1 (белый), а остальным
642 Глава 11. Нетривиальное использование растров пикселам присваивается 0 (черный). Также следует учитывать, что белый цвет фона назначается контексту устройства по умолчанию. Для растра маски также необходим совместимый контекст устройства. В некоторых приложениях расходы по созданию маски и совместимого контекста устройства для каждого вывода растра могут оказаться неприемлемыми. В листинге 11.8 приведена реализация TransparentBU, использующая вспомогательный класс KDDBMask для управления растром маски и совместимым контекстом устройства. Функция GTransparentBU создает экземпляр класса KDDBMask в стеке, создает маску, а затем использует ее для прозрачного вывода исходного растра. В своих приложениях вы можете вынести экземпляр маски на более высокий уровень, чтобы избежать его многократного создания. Листинг 11.8. Имитация TransparentBIt BOOL G_TransparentBlt(HDC hdcDest. int nDxo. int nDyO, int nDw. int nDh, HDC hdcSrc. int nSxO. int nSyO. int nSw, int nSh. UINT crTransparent) { KDDBMask mask; mask.Create(hdcSrc, nSxO, nSyO. nSw, nSh, crTransparent); return mask.TransBlt(hdcDest, nDxO, nDyO. nDw, nDh. hdcSrc. nSxO, nSyO, nSw, nSh); } class KDDBMask { HDC mJiMemDC; HBITMAP mJiMask; HBITMAP mJiOld; int mjiMaskWidth; int mjiMaskHeight; void Release(void) { if ( mJiMemDC ) { SelectObject(m_hMemDC. mJiOld); DeleteObject(m_hMemDC); mJiMemDC = NULL; m_h01d = NULL; } if ( mJiMask ) { DeleteObject(m_hMask); mJiMask = NULL; } } public: KDDBMask() {
Прозрачные растры 643 mJiMemDC - NULL; mJiMask - NULL; m_h01d = NULL: } -KDDBMask0 { Releasee); } BOOL Create(HDC hDC. int nX. int nY. int nWidth. int nHeight. UINT crTransparent); BOOL ApplyMask(HDC HDC. int nX. int nY. int nWidth. int nHeight. DWORD Rop); BOOL TransBlt(HDC hdcDest. int nDxO. int nDyO. int nDw. int nDh. HDC hdcSrc. int nSxO. int nSyO. int nSw. int nSh); // Создать монохромный растр маски по исходному DC BOOL KDDBMask::Create(HDC hDC. int nX. int nY. int nWidth. int nHeight. UINT crTransparent) { Releasee); RECT rect - { nX. nY. nX + nWidth. nY + nHeight }; LPtoDPChDC. (POINT *) & rect. 2); mjiMaskWidth = abs(rect.right - rect.left); mjiMaskHeight = absCrect.bottom - rect.top); // Получить настоящие // размеры // Создать совместимый контекст и монохромную маску mJiMemDC - CreateCompatibleDC(hDC); mJiMask = CreateBitmap(m_nMaskWidth. mjiMaskHeight. 1. 1, NULL); m_h01d - (HBITMAP) SelectObject(m_hMemDC. mJiMask); COLORREF oldBk = SetBkColor(hDC. crTransparent); // Ассоциировать // crTransparent с 1 // (белый цвет) BOOL rslt - StretchBlt(m_hMemDC. 0. 0. m_nMaskWidth. mjiMaskHeight. hDC. nX. nY. nWidth. nHeight. SRCCOPY); SetBkColor(hDC. oldBk); return rslt; BOOL KDDBMask::ApplyMask(HDC hDC. int nX. int nY. int nWidth. int nHeight. DWORD rop) { COLORREF oldFore = SetTextColor(hDC. RGB(0. 0. 0)); // Черный COLORREF oldBack - SetBkColor(hDC. RGB(255. 255. 255)); // Белый BOOL rslt = StretchBlt(hDC. nX. nY. nWidth. nHeight. mJiMemDC. 0. 0. mjiMaskWidth, mjiMaskHeight. rop); Продолжение &
644 Глава 11. Нетривиальное использование растров Листинг 11.8. Продолжение SetTextColor(hDC, oldFore); SetBkColor(hDC, oldBack); return rslt; } // D=D"S. D=D & Mask. D=D"S --> if (Mask==l) D else S BOOL KDDBMask::TransBlt(HDC hdcDest. int nDxO. int nDyO. int nDw, int nDh. HDC hdcSrc. int nSxO. int nSyO. int nSw, int nSh) { StretchBlt(hdcDest, nDxO, nDyO. nDw, nDh, hdcSrc, nSxO. nSyO. nSw. nSh, SRCINVERT); // D"S ApplyMask(hdcDest. nDxO. nDyO. nDw, nDh, SRCAND); // if trans D"S else 0 return StretchBlt(hdcDest, nDxO. nDyO. nDw. nDh, hdcSrc, nSxO. nSyO. nSw. nSh. SRCINVERT); // if trans D else S } Метод KDDBMask:: Create создает монохромный растр по заданному контексту устройства на основании цветового ключа. Метод вычисляет размеры растра, отображая исходный прямоугольник на систему координат устройства (на случай, если в исходном контексте устройства не используется принятый по умолчанию режим отображения ММТЕХТ). Фактическое преобразование цветного растра в монохромный зависит от фонового цвета исходного контекста устройства. Метод KDDB: :TransB1t использует знакомую последовательность растровых операций SRCINVERT/SRCAND/SRCINVERT для достижения эффекта прозрачности. Прозрачность без маски Практически во всех методиках прозрачного вывода растров используется монохромный растр, играющий роль маски. В ресурсах курсоров и значков имеется встроенная маска; функциям PlgBIt и MaskBlt растр маски передается в числе параметров. Единственным исключением является функция TransparentBlt, работающая с цветовыми ключами. Впрочем, в нашей имитации мы вернулись к работе с масками. Возникает вопрос: как реализовать прозрачность без применения масок? Например, если маску по каким-либо причинам трудно создать или она поглощает много ресурсов? Существуют ли альтернативные решения? В этом разделе рассматриваются некоторые из этих альтернатив. Прозрачный вывод с использованием геометрических фигур Базовый алгоритм прозрачного вывода под управлением маски состоит из трех шагов.
Прозрачность без маски 645 1. Наложение рисунка на приемную поверхность операцией XOR. 2. Объединение маски с приемной поверхностью операцией AND. 3. Повторное наложение рисунка на приемную поверхность операцией XOR. После этих трех этапов область, соответствующая черному (0) цвету маски, заменяется изображением-источником, а остальные пикселы остаются без изменений. Обратите внимание на то, что маска используется всего один раз для закраски непрозрачных областей черным (0) цветом. Если область, образованную черными пикселами маски, можно описать в виде совокупности геометрических фигур, то вместо создания отдельного растра маску можно нарисовать командами заливки областей GDI. Ниже приведен пример рисования эллиптического DIB-растра без растра маски. BOOL OvalStretchDIBits(HDC hDC. int XDest. int YDest. int nDestWidth. int nDestHeight. int XSrc, int YSrc. int nSrcWidth. int nSrcHeight. const void *pBits, const BITMAPINFO *pBMI. UINT iUsage) { StretchDIBits(hDC. XDest. YDest. nDestWidth. nDestHeight. XSrc. YSrc. nSrcWidth. nSrcHeight. pBits. pBMI. iUsage. SRCINVERT); SaveDC(hDC); SelectObject(hDC. GetStockObject(BLACKJRUSH)): SelectObject(hDC. GetStockObject(BLACK_PEN)); Ellipse(hDC. XDest. YDest. XDest + nDestWidth. YDest + nDestHeight); RestoreDCChDC. -1); return StretchDIBits(hDC. XDest. YDest. nDestWidth. nDestHeight. XSrc. YSrc. nSrcWidth. nSrcHeight. pBits. pBMI. iUsage. SRCINVERT); } Эта функция сначала выводит источник при помощи функции StretchDIBits с растровой операцией SRCINVERT, а затем рисует эллипс функцией Ellipse. Повторный вызов StretchDIBits с операцией SRCINVERT гарантирует, что изображение будет выводиться только в областях, находящихся внутри эллипса. При использовании функции Oval StretchDIBits для рисования нетривиального растра возникает неприятное мерцание, поскольку инвертирование пикселов — относительно медленный процесс. Чтобы уменьшить мерцание, можно позаимствовать структуру цветного растра у значков, где прозрачные пикселы обычно окрашиваются в черный цвет. В этом случае, после окраски непрозрачной области приемника в черный цвет, можно воспользоваться раЬтровой операцией SRCPAINT для объединения источника с приемником. Предполагается, что мы можем модифицировать растр-источник таким образом, чтобы его прозрачные пикселы были окрашены в черный цвет; это можно сделать при помощи DDB или DIB-секции, выбранной в совместимом контексте устройства. Функция OvalStretchBlt иллюстрирует эту идею. BOOL OvalStretchBlt(HDC hDC. int XDest. int YDest. int nDestWidth. int nDestHeight. HDC hDCSrc. int XSrc. int YSrc. int nSrcWidth. int nSrcHeight) { // Окрасить источник за пределами эллипса в ЧЕРНЫЙ цвет
646 Глава 11. Нетривиальное использование растров SaveDC(hDCSrc); BeginPath(hDCSrc); RectangleChDCSrc. XSrc, YSrc. XSrc + nSrcWidth+1. YSrc + nSrcHeight+1); EllipseChDCSrc. XSrc. YSrc, XSrc + nSrcWidth. YSrc + nSrcHeight); EndPath(hDCSrc); Sel ectObject (hDCSrc. GetStockObject (BLACKJRUSH)) ; SelectObj ect(hDCSrc. GetStockObj ect(BLACK_PEN)); FillPath(hDCSrc); RestoreDCChDCSrc, -1): // Нарисовать ЧЕРНЫЙ эллипс на приемной поверхности SaveDC(hDC); SelectObject(hDC. GetStockObj ect(BLACK_BRUSH)): SelectObject(hDC. GetStockObject(BLACK_PEN)); Ellipse(hDC. XDest. YDest. XDest + nDestWidth. YDest + nDestHeight): RestoreDCChDC. -1); // Объединить источник с приемником return StretchBltChDC. XDest. YDest. nDestWidth, nDestHeight. hDCSrc. XSrc. YSrc. nSrcWidth. nSrcHeight. SRCPAINT); } Сначала мы при помощи функций для работы с траекториями закрашиваем область за пределами эллипса черной кистью. Пикселы внутри эллипса остаются без изменений. Кстати говоря, если растр выводится несколько раз, эту операцию можно выполнить всего один раз и многократно использовать ее результат. Второй шаг — стирание приемной поверхности — остается прежним. На третьем шаге вместо SRC INVERT используется растровая операция SRCPAINT. В результате мерцание должно уменьшиться, поскольку только пикселы эллипса переходят от исходного цвета к черному, а затем заменяются пикселами источника. Чтобы полностью устранить мерцание, следует выполнить весь вывод на внеэкранном растре, а затем скопировать его на экран. Прозрачный вывод с использованием отсечения Если маска имеет простую геометрическую форму, прозрачный вывод без мерцания легко реализуется с использованием региона отсечения. К сожалению, программисты часто недооценивают возможности регионов отсечения — в основном из-за того, что в 16-разрядном интерфейсе GDI поддержка регионов оставляла желать лучшего. Следующая функция выводит овальный растр, для чего используется одна простая операция блиттинга с применением региона отсечения. BOOL ClipOvalStretchDIBits(HDC hDC. int XDest. 1nt YDest. int nDestWidth. int nDestHeight. int XSrc. int YSrc. int nSrcWidth, int nSrcHeight. const void *pBits, const BITMAPINFO *pBMI, UINT iUsage) { RECT rect = { XDest. YDest. XDest + nDestWidth. YDest + nDestHeight }; LPtoDPChDC. (POINT *) & rect. 2); HRGN hRgn = CreateEl1ipticRgnlndirect(& rect);
Прозрачность без маски 647 SaveDC(hDC); SelectClipRgn(hDC. hRgn); DeleteObject(hRgn): BOOL rslt - StretchDIBits(hDC. XDest, YDest, nDestWidth, nDestHeight. XSrc, YSrc, nSrcWidth, nSrcHeight. pBits, pBMI. iUsage. SRCCOPY); RestoreDCChDC. -1); return rslt; } Вероятно, стоит напомнить некоторые факты, относящиеся к работе с регионами и отсечением. Регионы отсечения определяются в координатах устройства, а не в логических координатах. Следовательно, перед тем как создавать регион вызовом CreateElipticRgnlndirect, функция ClipOvalStretchDIBits сначала должна отображать приемный прямоугольник в систему координат устройства приемного контекста. Предварительная подготовка изображений В некоторых ситуациях прозрачный растр должен отображаться только на поверхностях с однородным цветом фона. Например, растровые метки команд меню обычно отображаются на фоне меню, однородный цвет которого определяется текущей конфигурацией системы. Чтобы обеспечить максимальную эффективность при работе с такими изображениями, следует перед выводом подготовить изображение в итоговом виде. В Win32 API появилась чрезвычайно удобная функция, которая помогает в решении этой задачи: HANDLE LoadlmageCHINSTANCE hinst, LPCTSTR IpszName. UINT uType. int cxDesired. int cyDesired, UINT fuLoad); Функция Load I mage загружает курсоры мыши, значки и растры из ресурсов или внешних файлов. Для курсоров и значков можно задать желательный размер. Для растров Loadlmage может создать DDB или DIB-секцию. Отображая некоторые цвета изображения на другие цвета, можно подготовить изображение к выводу. При загрузке из ресурса первый параметр задает манипулятор экземпляра модуля; в этом случае параметр IpszName определяет имя ресурса. Он также может определять имя внешнего файла, если в параметре fuLoad передается флаг LR_LOADFROMFILE. Параметр uType может быть равен IMAGEJITMAP, IMAGE_CURSOR или IMAGE_ICON (для растров, курсоров мыши и значков соответственно). Пара cxDesired/cyDesired используется только для определения желательных размеров курсора или значка. Последний параметр, fuLoad, управляет процессом преобразования. Например, флаг LR_CREATEDIBSECTION указывает на то, что вместо DDB следует создать DIB-секцию. Флаг LR_L0ADMAP3DC0L0RS отображает пикселы с RGB(128.128.128) на COLORJDSHADOWS, RGBC192,192,192) - на COLORJDFACE, a RGBC233, 233,233) — на C0L0RJ3DLIGHT. При указании флага LR_M0N0CHR0ME растр загружается в черно-белом формате. Флаг LR_TRANSPARENT отображает пикселы, цвет которых совпадает с цветом первого пиксела изображения, на системный цвет фона окна
648 Глава 11. Нетривиальное использование растров C0L0RWIND0W. Флаг LRVGACOLOR требует, чтобы в растрах использовались цвета VGA. За подробностями обращайтесь к документации MSDN. Среди этих флагов наибольший интерес вызывает LRJTRANSPARENT. При установке этого флага Loadlmage заменяет пикселы, цвет которых совпадает с цветом первого пиксела изображения, цветом C0L0RWIND0W. Следовательно, если растр выводится на фоне C0L0RWIND0W, вывод всего растра простейшей операцией SRCCOPY приведет к тому же эффекту, что и вывод растра с применением маски. Однако эта возможность может использоваться только в том случае, если растр задействует палитру и отображается на фоне системного цвета C0L0R_WIND0W. Почему в GDI нет функции, которая позволяла бы назначить произвольный цвет в качестве прозрачного? В следующем фрагменте показано, как при помощи функции Loadlmage загрузить серию изображений и создать простейшую анимацию. Мы используем изображение комара из DirectX SDK. Анимационная последовательность состоит из трех изображений с разными положениями ног и крыльев. При последовательном выводе растров с небольшим смещением возникает иллюзия движения. void TestLoadlmageCHDC hDC, HINSTANCE hlnstance) { HBITMAP hBitmap[3]; const nID [] » { IDB_M0SQUIT1. IDB_M0SQUIT2. IDB_M0SQUIT3 }; for (int i=0; i<3; i++) hBitmap[i] = (HBITMAP) LoadImage(hInstance. MAKEINTRESOURCE(nID[i]). IMAGEJITMAP. 0. 0. LR_LOADTRANSPARENT | LR_CREATEDIBSECTION ); BITMAP bmp; GetObject(hBitmap[0]. sizeof(bmp), & bmp); HDC hMemDC - CreateCompatibleDC(hDC); SelectObjectChDC. GetSysColorBrush(COLOR_WINDOW)); int lastx = -1; int lasty = -1; HRGN hRgn = CreateRectRgn(0. 0. 0. 0); for (i-0: i<600; i++) { SelectObject(hMemDC. hBitmap[iX3]); int newx = i; int newy - abs(200-iX400): if ( lastx! —1 ) { SetRectRgn(hRgn, newx. newy. newx+bmp.bmWidth, newy + bmp.bmHeight); ExtSelectClipRgn(hDC. hRgn. RGNJDIFF); PatBlt(hDC. lastx. lasty. bmp.bmWidth. bmp.bmHeight. PATCOPY); SelectClipRgn(hDC. NULL); }
Альфа-наложение 649 BitBUChDC, newx, newy, bmp.bmWidth, bmp.bmHeight, hMemDC, 0. 0, SRCCOPY); lastx = newx; lasty = newy; } DeleteObject(hRgn); DeleteObject(hMemDC); DeleteObject(hBitmap[0]); DeleteObject(hBitmap[l]); DeleteObject(hBitmap[2]); } При создании окна цвет фона по умолчанию равен C0L0R_WIND0W; функция Loadlmage заменяет им черный цвет (прозрачный). Следовательно, для вывода изображения достаточно одного вызова BitBlt с растровой операцией SRCCOPY. Для создания анимации мы должны вывести одно изображение, стереть его, перейти в новую позицию и повторить вывод и стирание. В нашем примере предыдущее изображение стирается функцией PatBU. Обратите внимание: поскольку мы работаем с чистым фоном окна, стирание сводится к простой закраске цветом C0L0RWIND0W. При более сложном фоне нам пришлось бы сохранить участок фона и восстановить его. Чтобы уменьшить мерцание, мы при помощи региона отсечения исключаем участок, на котором выводится новое изображение, из обновляемой области, что позволяет избавиться от повторного изменения пикселов экрана и обеспечивает плавность анимации. Альфа-наложение В нескольких последних разделах мы подробно рассматривали растровые операции. Если хорошенько подумать, во многих ситуациях поразрядные растровые операции не имеют особого смысла. Собственно, что вы получите при объединении двух пикселов поразрядными операциями AND, OR или XOR? Конечно, мы нашли практическое применение для некоторых простых растровых операций при выводе растров, раскраске монохромных изображений, фильтрации RGB- каналов и постепенного проявления растров. Операция AND обычно используется в сочетании с монохромной маской для удаления ненужных пикселов, а операция XOR — для избирательного объединения растров источника и приемника. Мы никогда не объединяем изображения слепо, не зная точно, что при этом произойдет. К сожалению, поразрядные растровые операции с цветными изображениями не всегда имеют осмысленную интерпретацию в реальном мире (не считая нескольких случаев, описанных выше). Базовая формула прозрачного вывода растров, (M&D) | (-M&S), читается следующим образом: «Если пиксел маски равен 1 (белый цвет), результатом операции является пиксел приемника; в противном случае использовать пиксел источника». В формуле используется семантика поразрядных операций булевой алгебры. При переходе к арифметическим операциям формула принимает вид M*D+(1-M)*S. Именно в ней и заключается вся сущность альфа-наложения. Альфа-наложением (alpha blending) называется методика графического вывода, в которой итоговый пиксел вычисляется в виде взвешенной суммы двух
650 Глава 11. Нетривиальное использование растров пикселов (источника и приемника). Весовой коэффициент источника обычно называется альфа-коэффициентом (а). Весовой коэффициент приемника равен 1 - а, где за единицу принимается максимальное цветовое значение. Альфа-наложение выполняется не поразрядно, а для- каждого цветового канала по отдельности. Нулевой альфа-коэффициент соответствует абсолютно прозрачным пикселам источника, а единичный — полностью непрозрачным пикселам. Для графических поверхностей с 24- или 32-разрядной кодировкой цвета концептуальные формулы альфа-наложения выглядят так: Dst.red = Src.red * alpha + (1-alpha) * Dst.red : Dst.green - Src.green * alpha + (1-alpha) * Dst.green ; Dst.blue = Src.blue * alpha + (1-alpha) * Dst.blue ; Dst.alpha = Src.alpha * alpha + (1-alpha) * Dst.alpha ; Альфа-наложение относится к числу новых возможностей, появившихся в Windows 98 и Windows 2000. Вся поддержка альфа-наложения состоит из одной структуры данных и одной функции. typedef struct _BLENDFUNCTION { BYTE BlendOp; BYTE BlendFlags; BYTE SouyrceConstantAlpha; BYTE AlphaFormat; } BLENDFUNCTION; BOOL AlphaBlend(HDC hdcDest. int nXOriginDest. int nYOriginDest, int nWidthDest. int nHeightDest, HDC hdcSrc. int nXOriginSrc. int nYOriginSrc. int nWidthSrc. int nHeightSrc. BLENDFUNCTION blendFunction); По своему прототипу функция AlphaBlend напоминает StretchBU. Первые пять параметров определяют приемный контекст устройства и прямоугольник приемной поверхности в логических координатах. Следующие пять параметров определяют контекст устройства источника и прямоугольник на поверхности источника в логических координатах. При этом действуют стандартные ограничения для контекста источника, то есть исходный прямоугольник должен находиться в контексте источника, а в последнем не могут действовать преобразования сдвига и поворота, приводящие GDI в замешательство. Обратите внимание: ограничения на контекст источника не позволяют напрямую использовать DIB с функцией AlphaBlend. Последний параметр, blendFunction, содержит структуру BLENDFUNCTION, передаваемую по значению. Эта структура заменяет код растровой операции, используемый при вызове StretchBU. Структура BLENDFUNCTION управляет процессом объединения двух растров, источника и приемника. Поле BlendOp определяет операцию наложения источника, однако единственным допустимым значением этого поля является AC_SRC_0VER, при котором растр-источник накладывается на приемник на основании альфа-коэффициентов источника. Поддержка альфа-наложения в OpenGL предусматривает и другие варианты (например, источник с постоянным цветом). Следующее поле, BlendFlags, должно быть равно нулю; его использование зарезервировано на будущее. Последнее поле, AlphaFormat, прини-
Альфа-наложение 651 мает два значения: 0 означает постоянный альфа-коэффициент, a ACSRCjALPHA — использование альфа-коэффициентов отдельных пикселов. Если поле AlphaFormat равно 0, для всех пикселов растра-источника используется одинаковый альфа-коэффициент, заданный в поле SourceAlphaConstant. Допустимые значения лежат в интервале 0-255, а не 0-1, как можно было бы предположить. В данном случае 0 означает полную прозрачность, а 255 — полную непрозрачность. Альфа-коэффициенты пикселов приемника равны 255- SourceConstantAlpha. В этом случае альфа-наложение выполняется по следующим формулам: Dst.red = Round((Src.red * SourceConstantAlpha + (255-SourceConstantAlpha) * Dst.red ))/255); Dst.green = Round((Src.green * SourceConstantAlpha + (255-SourceConstantAlpha) * Dst.green))/255); Dst.blue - Round((Src.blue * SourceConstantAlpha + (255-SourceConstantAlpha) * Dst.blue ))/255); Dst.alpha - Round((Src.alpha * SourceConstantAlpha + (255-SourceConstantAlpha) * Dst.alpha))/255): Если поле А1 phaFormat равно AC_SRC_ALPHA, данные альфа-канала должны входить в пикселы поверхности источника. Другими словами, это должен быть физический контекст устройства в 32-разрядном режиме или совместимый контекст устройства, в котором выбран 32-разрядный DDB-растр или DIB-секция. В любом случае каждый пиксел источника состоит из четырех 8-разрядных каналов: красного, зеленого, синего и альфа-канала. Альфа-канал каждого пиксела используется в сочетании с полем SourceConstantAlpha для объединения источника с приемником. Вычисления производятся по следующим формулам: Tmp.red - Round((Src.red * SourceConstantAlpha)/255); Tmp.green « Round((Src.green * SourceConstantAlpha)/255); Tmp.blue - Round((Src.blue * SourceConstantAlpha)/255); Tmp.alpha - Round((Src.alpha * SourceConstantAlpha)/255); beta - 255 - Tmp.alpha; Dst.red - Tmp.red + Round((beta * Dst.red )/255): Dst.green = Tmp.green + Round((beta * Dst.green )/255); Dst.blue - Tmp.blue + Round((beta * Dst.blue )/255): Dst.alpha = Tmp.alpha + Round((beta * Dst.alpha )/255): Внимательно рассматривая эти формулы, можно заметить, что альфа-коэффициент уровня пикселов Src.alpha применяется только к пикселам приемника, но не к пикселам источника. GDI предполагает, что альфа-коэффициент уже был внесен в данные растра-источника предварительным умножением. Вероятно, это сделано для удобства игрового программирования, где сцены могут быть предварительно сгенерированы во внешней программе или создаваться в результате работы других компонентов. Изображение с предварительным внесением альфа-данных напоминает прозрачный растр с черным фоном (цветной растр в значке); оно тоже ускоряет вывод за счет гибкости. Если значение SourceCons- tantAl pha равно 255, временную переменную Tmp вычислять не нужно. Если быстродействие критично для вашей программы, возможно, вас обеспокоит необходимость деления на 255 для каждого пиксела. На процессорах Intel полноценное деление занимает десятки тактов и потому считается исключи-
652 Глава 11. Нетривиальное использование растров тельно медленной операцией. Доверьтесь реализации GDI и современным компиляторам — они достаточно умны, чтобы заменить деление на константу умножением со сдвигом. Пример альфа-наложения с постоянным коэффициентом Проще всего реализовать альфа-наложение с постоянным коэффициентом. Для него даже не требуется, чтобы поверхность источника была 32-разрядной, поскольку альфа-коэффициент передается в структуре BLENDFUNCTION. Рассмотрим простой пример с наложением нескольких прямоугольников со сплошной заливкой: void SimpleConstantAlphaBlending(HDC hDC) { const int size = 100; for (int i=0; i<3; i++) { RECT rect = { i*(size+10) + 20. 20+size/3. i*(size+10) + 20 + size. 20+size/3 + size }; const COLORREF Color[] = { RGB(0xFF. 0. 0). RGB(0. OxFF. 0). RGB(0. 0. OxFF) }; HBRUSH hBrush = CreateSolidBrush(Color[i]); FillRect(hDC. & rect. hBrush); // Три исходных прямоугольника DeleteObject(hBrush); BLENDFUNCTION blend = { AC_SRC_OVER. 0. 255/2. 0 }; // альфа=0.5 AlphaBlend(hDC. 360+((3-i)*3)*size/3. 20+i*size/3. size. size. hDC. i*(size+10)+20, 20+size/3. size. size, blend); } } В этом примере источником и приемником является один и тот же контекст устройства. Сначала мы рисуем три однородных прямоугольника красного, зеленого и синего цвета, а затем накладываем их на фон окна функцией Alpha- Blend. При каждом вызове используется постоянный альфа-коэффициент 0,5. Сначала фон окна окрашен в сплошной белый цвет RGB(0xFF,0xFF,0xFF). После наложения красного прямоугольника пикселы окрашиваются в цвет RGB(0xFF,0x80,0x80). После наложения второго, зеленого прямоугольника пикселы на пересечении красного и зеленого прямоугольников принимают цвет RGB(0x80,0xBF,0x40). После наложения третьего, синего прямоугольника пересечение всех трех прямоугольников содержит пикселы с цветом RGB(0x40,0x60, 0x90). Возможно, это не совсем то, чего вы ожидали, но эта величина рассчитывается по формулам альфа-наложения: RGBC0x40.0x60.0x90) - RGB(OxFF.OxFF.OxFF) * 0.125 + RGB(OxFF.O.O) * 0.125 + RGB(O.OxFF.O) * 0.25 + RGB(0.0,0xFF) * 0.5
Альфа-наложение 653 Результат наложения показан на рис. 11.7. Рис. 11.7. Альфа-наложение цветных прямоугольников с постоянным коэффициентом Постепенное проявление и исчезновение растров В разделе «Прозрачные растры» была приведена функция последовательной «проявки» растра с применением растровых операций. Альфа-наложение предоставляет новые средства для постепенного вывода растров. Ниже приведен новый вариант функции, использующий альфа-наложение с постоянным коэффициентом. BOOL AlphaFade(HDC hDCDst. int XDst, int YDst. int nDstW. int nDstH, HDC hDCSrc. int XSrc. int YSrc. int nSrcW. int nSrcH) { for (int i=5; i>=l; i--) { // Альфа 1/5. 1/4, 1/3. 1/2. 1/1 BLENDFUNCTION blend - { AC_SRC_OVER. 0. 255 / i . 0 }; if ( ! AlphaBlendChDCDst. XDst. YDst. nDstW. nDstH. hDCSrc. YSrc. YSrc, nSrcW. nSrcH, blend): } return TRUE; } Функция AlphaFade накладывает растр-источник на приемную поверхность в пять этапов, с альфа-коэффициентами 1/5, 1/4, 1/3, 1/2 и 1/1. После первого вывода часть изображения уже присутствует в приемнике, поэтому накапливаемые коэффициенты будут равны 1/5, 2/5, 3/5, 4/5 и, наконец, 5/5. Прозрачные окна В Windows 98/2000 появился новый расширенный стиль окна. При установке флага WSEXLAYERED весь вывод в окно вместо непосредственного вывода на экран кэшируется в растре, размеры которого совпадают с размерами экрана. Далее содержимое этого растра может быть выведено на экран посредством альфа- наложения. Приложение даже может задать цветовой ключ для такого окна. Все пикселы, цвет которых совпадает с цветом ключа, будут прозрачными, то есть
654 Глава 11. Нетривиальное использование растров среди них будут видны пикселы, находящиеся под окном. Когда на экране появляются ранее закрытые части окна со стилем WS_EX_LAYERED, перерисовка со стороны приложения не нужна — GDI просто заново выводит на экран кэшированное содержимое растра. При правильной реализации этот стиль позволяет создавать новые визуальные эффекты и повышает быстродействие за счет затрат на хранение кэшированных растров. Стиль WS_EX_LAYERED указывается либо при вызове CreateWindowEx, либо позднее при помощи SetWIndowLong. После создания окна можно задать постоянный альфа-коэффициент для окна и необязательный цветовой ключ при помощи функции SetLayeredWi ndowAttri butes: BOOL SetLayeredWindowAttributes(HWND hWnd. COLORREF crKey, BYTE bAlpha. DWORD dwFlags): Параметр hWnd содержит манипулятор окна с флагом стиля WS_EX_LAYERED. Параметр dwFlags содержит один или оба флага LWA_C0L0RKEY и LWA_ALPHA. При использовании флага LWA_C0L0RKEY параметр сгКеу определяет цветовой ключ прозрачности. Для флага LWA_ALPHA параметр ЬАТ pha определяет постоянный альфа- коэффициент источника. Стиль WS_EX_LAYERED может использоваться только для окон верхнего уровня. Следующий фрагмент показывает, как создать окно со стилем WS_EX_LAYERED в функции окна: switch ( uMsg) { case WM_CREATE: mJiWnd = hWnd; SetWi ndowLong(m_hWnd. GWLJXSTYLE. GetWindowLong(m_hWnd. GWLJXSTYLE) | WS_EX_LAYERED); SetLayeredWindowAttributes(mJiWnd. RGB(0. 0, 1). OxCO, LWA_ALPHA | LWA_C0L0RKEY ); return 0; } В этом фрагменте функция GetWindowLong возвращает текущие флаги расширенных стилей, которые после объединения с WSEXLAYERED записываются на прежнее место. При вызове SetLayeredWi ndowAttri butes устанавливается альфа-коэффициент 0,75 (ОхСО/255) и цветовой ключ RGB (0,0,1) — несколько необычный цвет, очень близкий к черному. Выполнение этого фрагмента заметно влияет на внешний вид окна. Практически весь вывод в окне, включая дочерние окна, становится полупрозрачным, хотя и выполняется гораздо медленнее. Впрочем, меню или диалоговые окна остаются непрозрачными. На рис. 11.8 показан пример — окно с DIB-растром, наложенное на исходный текст программы в MSVC IDE. Обратите внимание: рисунок был получен сохранением всего экрана. Если сохранить только содержимое окна, вместо экранного изображения вы получите только содержимое кэшированного растра. Как обычно бывает с новыми технологиями, прозрачные окна выводятся значительно медленнее обычных. Также огорчает и то, что меню выводятся непрозрачными, а окна не перерисовываются так, как положено.
Альфа-наложение 655 у - pBMI->bmiHeader.biHeight - 1 - у; BYTE * D - pBitsDst + GetOffsetCpBMIDst, dx. j + dy); BYTE * S « pBitsSrc + GetOffsetCpBMISrc. sx, j + sy); Рис. 11.8. Прозрачное окно Альфа-канал: класс AirBrush Во всех примерах, приведенных выше, используется постоянный альфа-коэффициент, применяемый к каждому пикселу растра-источника. Возможности постоянных альфа-коэффициентов ограничены. Например, они даже не справляются с задачей прозрачного вывода растров, которая легко решается при помощи маски. Растр маски можно рассматривать как альфа-канал с кодировкой 1 бит/пиксел, отделенный от основного растра. Давайте рассмотрим некоторые типичные применения альфа-каналов. Хотя функция AlphaBlend позволяет выбирать в совместимом контексте устройства как DDB, так и DIB-секции, при использовании альфа-каналов можно работать только с DIB-секциями. Дело в том, что в экранных режимах, не использующих 32-разрядную кодировку цвета, 32-разрядный DDB-растр не будет совместим с экранным контекстом устройства. В 32-разрядной DIB-секции каждый пиксел хранится в 4 байтах. Первый три байта обычно содержат данные синего, зеленого и красного каналов, а в последнем байте хранится альфа-канал. AlphaBlend — единственная функция, которая читает и записывает данные альфа-канала, поэтому GDI не оказывает особой помощи в подготовке этих данных. При использовании альфа-наложения на уровне отдельных пикселов AlphaBlend предполагает, что пикселы источника были предварительно умножены на альфа-коэффициент. Следовательно, чтобы воспользоваться альфа-каналом, мы должны обладать прямым доступам к пикселам DIB-секции.
656 Глава 11. Нетривиальное использование растров В современных графических редакторах обычно поддерживаются разные типы кистей (не путать с кистями GDI!), предназначенных для рисования больших точек и толстых линий. Кисть в графическом редакторе определяется своей формой, цветом, ориентацией, жесткостью и другими хитроумными атрибутами. Например, довольно часто встречается круглая цветная кисть с жесткостью в 50 % — характеристикой, определяющей скорость изменения пикселов кисти от однородного цвета в центре до абсолютно прозрачного цвета на периметре. При рисовании точек или линий такой кистью их границы плавно сливаются с фоном без образования четких контуров, как при стандартном рисовании линий средствами GDI. Описанный эффект можно легко воспроизвести при помощи альфа-канала. В листинге 11.9 приведен класс KAirBrush, реализованный на базе DIB-секции. Листинг 11.9. Класс KAirBrush class KAirBrush { HBITMAP mJiBrush; HDC mJiMemDC: HBITMAP m_h01d; int mjiWidth; int mjiHeight; void Release(void) { SelectObject(m_hMemDC. m_h01d); DeleteObject(m_hMemDC); DeleteObject(mJiBrush); NULL; m hBrush - NULL; m hOld = } public: KAirBrushO { mJiBrush m hMemDC m hOld } -KAirBrushO { Releasee) NULL; m_ - NULL; = NULL; = NULL; JiMemDC void Create(int width, int height. C0L0RREF color); void Apply(HDC hDC. int x, int y); void KAirBrush::Apply(HDC hDC, int x, int y) { BLENDFUNCTION blend = { AC SRC OVER, 0. 255. AC SRC ALPHA
Альфа-наложение 657 AlphaBlend(hDC. x-m_nWidth/2. y-m_nHeight/2, mjiWidth. m_nHeight. mJiMemDC, 0. 0. mjiWidth. mjiHeight, blend); } void KAirBrush::Create(int width, int height. COLORREF color) { ReleaseO; BYTE * pBits; BITMAPINFO Bmi - { { sizeof(BITMAPINFOHEADER). width, height. 1. 32. BI_RGB } }; m_hBrush - CreateDIBSection(NULL. & Bmi. DIB_RGB_COLORS. (void **) & pBits. NULL. NULL); mJiMemDC = CreateCompatibleDC(NULL); m_h01d - (HBITMAP) SelectObject(m_hMemDC. m_hBrush); m_nWidth = width; mjiHeight = height; // Однородный цветной круг на белом фоне { PatBlt(m_hMemDC. 0. 0. width, height. WHITENESS); HBRUSH hBrush = CreateSolidBrush(color); SelectObject(m_hMemDC. hBrush); SelectObject(m_hMemDC. GetStockObject(NULL_PEN)); Ellipse(m_hMemDC. 0. 0. width, height); SelectObject(m_hMemDC. GetStockObject(WHITE_BRUSH)); DeleteObject(hBrush); } BYTE * pPixel = pBits; // Вычислить альфа-канал и умножить значения пикселов for (int y=0; y<height; у++) for (int x=0: x<width; x++. pPixel+=4) { // Расстояние от центра, нормализованное в интервале [0..255] int dis - (int) ( sqrt( (x-width/2) * (x-width/2) + (y-height/2) * (y-height/2) ) * 255 / (max(width. height)/2) ); BYTE alpha = (BYTE) max(min(255-dis. 255). 0); pPixel[0] - pPixel[0] * alpha / 255; pPixeUl] = pPixel[l] * alpha / 255; pPixel[2] - pPixel[2] * alpha / 255; pPixel[3] = alpha; } }
658 Глава 11. Нетривиальное использование растров Класс KAirBrush хранит кисть в DIB-секции, поэтому в переменных класса хранятся манипулятор растра и совместимого контекста, манипулятор исходного растра и размеры кисти. Метод KAirBrush::Create строит DIB-секцию кисти по размерам и заданному цвету. Он создает DIB-секцию с 32-разрядным цветом и совместимый контекст устройства, в котором выбирается DIB-секция, после чего выводится белый фон и однородный цветной круг. В результате мы получаем круглую кисть с жесткостью в 100 % на белом фоне. Следующий фрагмент вычисляет альфа-канал и вносит его в данные RGB посредством предварительного умножения. Для этого программа последовательно перебирает все пикселы DIB-секции, вычисляет их расстояние от центра круга, определяет альфа-коэффициент, умножает на него составляющие RGB и сохраняет коэффициент в альфа-канале. В результате мы получаем 32-разрядную DIB-секцию, в которую были заранее внесены данные альфа-канала. Метод KAirBrush::Apply просто выводит кисть, располагая ее центр в заданной точке (х,у). При этом постоянный альфа-коэффициент устанавливается равным 255, поскольку нас интересуют только данные альфа-канала. Если приложение поддерживает работу с графическим планшетом, фиксирующим силу нажима, постоянный альфа-коэффициент может использоваться для постепенного изменения кисти вдоль линии. Использовать класс KAirBrush несложно. Сначала создайте экземпляр KAirBrush — например, во время инициализации представления (view). На панели инструментов можно создать кнопки для изменения цвета или формы кисти. При обработке некоторых сообщений мыши кисть выводится в текущей позиции курсора. Ниже приведен типичный фрагмент программы. Примерный результат показан на рис. 11.9. switch ( uMsg) { case WM_CREATE: mJ>rush.Create(32. 32, RGB(0, OxFF. 0)); return 0; case WMJ.BUTT0ND0WN: wParam - MKJ.BUTT0N; // Перейти к следующей секции case case WM_M0USEM0VE: if (wParam & MK_LBUTT0N ) { m_brush.Apply(m_hDCBitmap. LOWORD(lParam), HIWORD(lParam)); Refresh(LOWORDdParamO). HIWORD(lParam)); } return 0; } Аналогичная методика применяется при выводе геометрических фигур с размытыми краями или при наложении изображений. Чтобы размыть границы выводимых линий, многоугольников, кругов и т. д., присвойте внутренним пикселам альфа-коэффициент 255, а внешним пикселам — альфа-коэффициент 0. Альфа-коэффициенты пограничных пикселов должны отражать степень их размытия. Например, при рисовании линии под углом 45° некоторые пограничные
Альфа-наложение 659 пикселы будут принадлежать линии лишь наполовину, поэтому их альфа-коэффициенты должны быть равны 127. Иногда размытие требует проведения довольно сложных вычислений. Один простой, хотя и недешевый способ заключается в создании монохромного растра, увеличенного в п раз по сравнению с оригиналом. В этом растре рисуется увеличенный вариант геометрической фигуры. Полученное изображение делится на блоки размером п х и, и сумма пикселов каждого блока преобразуется в данные альфа-канала. • * » ш * W Рис. 11.9. Точки и линии, нарисованные при помощи класса KAirBrush Имитация альфа-наложения Альфа-наложение, как и другие приятные возможности GDI, поддерживается не на всех платформах Win32, что ограничивает возможности его применения. Если вы хотите использовать альфа-наложение в реальной программе, вам придется имитировать его своими силами. Один из вариантов реализации рассматривается ниже. На этот раз мы не пытаемся имитировать функцию AlphaBlend, а ограничимся реализацией альфа-наложения между двумя 32-разрядными DIB-растрами. Функция AlphaBlend3232 приведена в листинге 11.10. Листинг 11.10. Альфа-наложение между двумя 32-разрядными DIB-растрами // Вычисление смещения пиксела DIB inline int GetOffset(BITMAPINFO * pBMI. int x. int y) { if ( pBMI->bmiHeader.biHeight > 0 ) // Для перевернутого растра у = pBMI->bmiHeader.biHeight - 1 - у; return ( pBMI->bmiHeader.biWidth * pBMI-> bmiHeader.biBitCount + 31 ) / 32 * 4 * у + ( pBMI->bmiHeader.biBitCount / 8 ) * x; } // Альфа-наложение между двумя 32-разрядными DIB-растрами BOOL AlphaBlend3232(BITMAPINF0 * pBMIDst, BYTE * pBitsDst, int dx, int dy, int w, int h. Продолжение^
660 Глава 11. Нетривиальное использование растров Листинг 11.10. Продолжение BITMAPINFO * pBMISrc, BYTE * pBitsSrc, int sx, int sy. BLENDFUNCTION blend) { int alpha = blend.SourceConstantAlpha; // Постоянный альфа-коэффициент int beta = 255 - alpha; int format; if ( blend.AlphaFormat==0 ) format = 0; else if ( alpha==255 ) format = 1; else format = 2; for (int j=0; j<h; j++) { BYTE * D = pBitsDst + GetOffset(pBMIDst. dx. j + dy); BYTE * S = pBitsSrc + GetOffset(pBMISrc. sx, j + sy); int i: switch ( format ) { case 0: // Только постоянный альфа-коэффициент for (i=0: i<w; i++) { D[0] = ( S[0] * alpha + beta * D[0] + 127 D[l] - ( S[l] * alpha + beta * D[l] + 127 D[2] • ( S[2] * alpha + beta * D[2] + 127 D[3] - ( S[3] * alpha + beta * D[3] + 127 D +- 4; S += 4; } break; case 1: // Только альфа-канал for (i=0; i<w; i++) { beta - 255 - S[3]; D[0] - S[0] + ( beta * D[0] + 127 ) / 255 D[l] - S[l] + ( beta * D[l] + 127 ) / 255 D[2] - S[2] + ( beta * D[2] + 127 ) / 255 D[3] - S[3] + ( beta * D[3] + 127 ) / 255 D +- 4; S +- 4; } break; case 2: // Постоянный коэффициент вместе с альфа-каналом for (i=0; i<w: i++) { beta - 255 - ( S[3] * alpha + 127 ) / 255; D[0] - ( S[0] * alpha + beta * D[0] + 127 ) / 255; D[l] = ( S[l] * alpha + beta * D[l] + 127 ) / 255: ) / 255 ) / 255 ) / 255 ) / 255
Итоги 661 D[2] = ( S[2] * alpha + beta * D[2] + 127 ) / 255; D[3] - ( S[3] * alpha + beta * D[3J + 127 ) / 255; D +« 4; S += 4; } } } return TRUE; } Приемником и источником для функции Al phaBl end3232 являются одинаковые по размеру прямоугольники в 32-разрядном DIB-растре. Таким образом, мы можем вычислить адрес пиксела как в источнике, так и в приемнике, а масштабирование этой функцией не поддерживается. Альфа-наложение делится на три случая: только постоянный альфа-коэффициент, только альфа-канал и одновременное применение постоянного альфа-коэффициента с альфа-каналом. Функция перебирает все пикселы приемного прямоугольника и объединяет их с пикселами источника. Для таких важных операций, как альфа-наложение, следует создать несколько вариантов функции для разных комбинаций поверхности источника и приемника. Например, функция Al phaBl endl632 будет работать с 16-разрядным приемником и 32-разрядным источником, а функция Al phaBl end824 будет получать 8-разрядный приемник, использующий палитру и требующий поиска в цветовой таблице, и 24-разрядный источник, не поддерживающий альфа-канала. Итоги Основной темой этой главы является формирование новых пикселов по нескольким операндам. Мы подробно рассмотрели тернарные и кватернарные растровые операции, различные варианты прозрачного вывода растров, альфа-наложение и отображение растров на параллелограмм. Также были описаны общие принципы работы растровых операций, процесс разбиения и анализа ROP-кодов и построение растровых операций для решения конкретных практических задач. В этой главе нашлось место и для новых экзотических средств GDI для вывода растров (MaskBlt, PlgBlt, TransparentBlt и Al phaBl end) с примерами использования и имитации этих функций на тех платформах Win32, где они не поддерживаются. После описания растровых форматов GDI (глава 10) и функций GDI (глава 11) нам остается лишь узнать, как организовать прямой доступ к массиву пикселов, как реализовать возможности, предоставляемые GDI, а в некоторых случаях — и улучшить реализацию. В следующей главе рассматривается прямой доступ к пикселам и его применение при обработке графических изображений. Примеры программ К главе 11 прилагается всего одна программа AdvBitmap, демонстрирующая весь изложенный материал (табл. 11.3).
662 Глава 11. Нетривиальное использование растров Таблица 11.3. Программа главы 11 Каталог проекта Samples\Chapt_l l\Adv__Bitmap Описание Вывод диаграммы тернарных растровых операций, демонстрация вывода значков с применением растровых операций, спрайтовая анимация, альфа-наложение, применение масок при выводе растров, постепенное проявление растров, PlgBlt и т. д. Соответствующие команды находятся в меню Test, а также появляются после открытия ВМР-файлов
Глава 12 Графические алгоритмы и растры Windows Аппаратно-независимые растры и DIB-секции удобны тем, что приложение может напрямую работать с их массивами пикселов и цветовыми таблицами. Довольно часто этот прямой доступ оказывается абсолютно необходимым для реализации возможностей, не поддерживаемых GDI, или достижения повышенного быстродействия по сравнению с функциями GDI. Кстати, то и другое уже встречалось нам ранее. Имитируя функцию PlgBlt, мы воспользовались функциями GDI GetPixel и SetPixel. Как выяснилось, эти функции заметно уступают по быстродействию реализации PlgBlt в Windows 2000 GDI. С каждым вызовом GetPixel /SetPixel связаны затраты на проверку параметров, переключение из пользовательского режима в режим ядра, преобразование цветов и т. д. Функция GetPixel для выполнения своей задачи даже создает временный растр и вызывает внутреннюю реализацию BitBlt. He удивительно, что она так медленно работает. При использовании альфа-наложения GDI не обеспечивает нормальной поддержки для настройки альфа-канала в 32-разрядном растре или предварительного умножения каналов RGB на альфа-коэффициент. Следовательно, для решения этих задач вам придется напрямую работать с массивом пикселов. В этой главе вы научитесь напрямую работать с данными DIB и DIB-секций для реализации различных графических алгоритмов. Среди рассматриваемых тем — прямой доступ к массивам пикселов, аффинные преобразования растров на базе прямого доступа, преобразование цветов и пикселов растра, а также обработка изображений с применением пространственных фильтров.
664 Глава 12. Графические алгоритмы и растры Windows Прямой доступ к пикселам Прежде всего нам понадобится несколько общих функций для работы с отдельными пикселами DIB или DIB-секции. При наличии полной структуры BITMAPINFO и указателя на массив пикселов работа с DIB-секцией почти не отличается от работы с DIB. В сущности, нам нужны аналоги функций GetPixel и SetPixel GDI. При работе с аппаратно-независимым растром обращение к отдельным пикселам сжатого изображения — задача не из простых. Если прочитать пиксел из растра, сжатого по алгоритму RLE, еще реально (хотя и очень долго), то записать что-либо в сжатый растр практически невозможно. Ведь если новый пиксел отличается от соседних, возможно, вам придется расширять строку развертки. Поэтому мы предполагаем, что все сжатые растры (как растры со сжатием RLE, так и сжатые изображения в формате JPEG или PNG) заранее распакованы. Также следует учитывать, что GetPixel и SetPixel работают с данными C0L0RREF, которые могут представлять значения RGB или индексы палитры. Наша базовая функция должна использовать тот же формат пикселов, что и растр, с которым она работает (то есть цветовые индексы для растров с палитрой или 16-, 24- или 32-разрядные значения RGB для растров, не использующих палитру). Поверх этих базовых функций строятся функции, работающие с C0L0RREF. В листинге 12.1 приведены два новых метода класса KDIB: GetPixel Index и Set- Pixel Index. Функция GetPixellndex возвращает цветовые данные для пиксела в заданной позиции. Для растра с кодировкой 1 бит/пиксел эти данные будут состоять из 1 бита, для растра с кодировкой 2 бита/пиксел — из 2 битов и т. д. Функция SetPixel Index решает противоположную задачу — она заменяет пиксел в заданной позиции новыми цветовыми данными. Листинг 12.1. Общие функции для обращения к пикселам DIB const BYTE Shiftlbpp[] ={ 7. 6, 5. 4. 3, 2. 1. О }; const BYTE Masklbpp [] - { 0x7F, OxBF, OxDF. OxEF, 0xF7, OxFB, OxFD. OxFE }; const BYTE Shift2bpp[] = { 6. 4, 2. 0 }; const BYTE Mask2bpp [] = { ~0xC0. -0x30. -OxOC. -0x03 }; const BYTE Shift4bpp[] = { 4. 0 }; const BYTE Mask4bpp [] - { ~0xF0. ~0x0F }; DWORD KDIB::GetPixelIndex(int x. int y) const { if ( (x<0) || (x>=m_nWidth) ) return -1; if ( (y<0) || (y>=m_nHeight) ) return -1; BYTE * pPixel e mjDOrigin + у * mjiDeUa; switch ( m nlmageFormat ) { case DIB_1BPP: return ( pPixe1[x/8] » Sh1ftlbpp[x*8] ) & 0x01;
Прямой доступ к пикселам 665 case DIB_2BPP: return ( pPixel[x/4] » Shift2bpp№4] ) & 0x03; case DIB_4BPP: return ( pPixel[x/2] » Shift4bpp[xH] ) & OxOF; case DIB_8BPP: return pPixel[x]; case DIBJL6RGB555: case DIB_16RGB565: return ((WORD *)pPixel)[x]: case DIB_24RGB888: pPixel += x * 3; return (pPixelCO]) | (pPixel[1] « 8) | (pPixel[2] « 16): case DIB_32RGB888: case DIB_32RGBA8888: return ((DWORD *)pPixel)[x]; return -1; BOOL KDIB::SetPixelIndex(int x, int y. DWORD index) { if ( (x<0) || (x>=m_nWidth) ) return FALSE; if ( (y<0) || (y>=m_nHeight) ) return FALSE; BYTE * pPixel = m_pOrigin + у * m_nDelta; switch ( mjiImageFormat ) { case DIB_1BPP: pPixel[x/8] - (BYTE) ( ( pPixel[x/8] & Masklbpp[xS8] ) | ( (index & 1) « Shiftlbpp[x*8] ) ); break; case DIB_2BPP: pPixel[x/4] = (BYTE) ( ( pPixel[x/4] & Mask2bpp[x*4] ) | ( (index & 3) « Shift2bpp[xS4] ) ); break; case DIB_4BPP: pPixel[x/2] = (BYTE) ( ( pPixel[x/2] & Mask4bpp№] ) | ( (index & 15) « Shift4bpp№] ) ); break; case DIB_8BPP; pPixel[x] = (BYTE) index; break; Продолжение^
666 Глава 12. Графические алгоритмы и растры Windows Листинг 12.1. Продолжение case DIB_16RGB555: case DIB_16RGB565: ((WORD *)pPixel)[x] = (WORD) index; break: case DIB_24RGB888: ((RGBTRIPLE *)pPixel)[x] - * ((RGBTRIPLE *) & index); break; case DIB_32RGB888: case DIB_32RGBA8888: ((DWORD *)pPixel)[x] - index; break; default: return FALSE; } return TRUE; } В функциях предусмотрена проверка границ. Поскольку выход за пределы растра обычно приводят к возникновению GPF (общих ошибок защиты), мы сразу пресекаем подобные попытки. Если координаты находятся за границами растра, функция возвращает код ошибки. После проверки параметров функция вычисляет адрес первого пиксела строки развертки по координате г/, используя адрес логического начала растра и разность между начальными адресами двух соседних строк развертки. Эти две характеристики вычисляются заранее с учетом порядка (прямого или обратно) следования строк развертки в DIB. Например, для стандартных DIB-растров с обратным порядком строк развертки логическое начало DIB находится в конце данных растра, а смещение строк развертки является отрицательной величиной. При непосредственном обращении к пикселам учитывается их формат. Для растров с кодировкой 1, 2 и 4 бит/пиксел каждый пиксел занимает лишь часть байта, поэтому программа должна вычислить величину сдвига в битах и построить маску. Проще всего работать с 8-разрядными растрами, в которых каждый пиксел занимает ровно один байт. В 16-разрядном растре пиксел занимает два байта. Вызывающая сторона должна самостоятельно преобразовать 16-разрядные данные пиксела в формат RGB. С 24-разрядными растрами дело обстоит сложнее, поскольку мы не можем обратиться к 24-разрядному пикселу как к DWORD и замаскировать старшие 8 бит. Хотя в литературе по программированию иногда встречаются программы, где реализован такой подход, на самом деле это недопустимо. Например, при создании 24-разрядной DIB-секции 64 х 64 размер массива пикселов составит 64 х 64 х 3 = 12 Кбайт. На процессорах Intel будет выделено ровно три страницы памяти. Смещение последнего пиксела в растре равно 0x2FFD. При попытке прочитать его как DWORD процессор выйдет на 1 байт за пределы 12-килобайтно- го блока, что, скорее всего, приведет к возникновению GPF. Метод SetPixel Index имеет практически такую же структуру, как GetPixel Index. Для 1-, 2- и 4-разрядных растров присваивание пикселу сводится к удалению
Аффинные преобразования растров 667 его первоначальных битов при помощи маски и внесению новых данных. Для 24-разрядных растров указатель преобразуется к типу указателя на RGBTRIPLE и данные копируются как структура RGBTRIPLE, чтобы компилятор сгенерировал код для копирования ровно трех байтов. Выполняете ли вы операции с растрами, требующие произвольного доступа к пикселам, — например, повороты, зеркальные отражения или копирование данных между растрами одинакового формата? Функции GetPixel Index и Set- Pixel Index — это именно то, что вам нужно. Эти функции также очень хорошо работают для растров, не использующих палитры. Если вы захотите окрасить в красный цвет пиксел растра с кодировкой 8 бит/пиксел, вам придется предварительно свериться с цветовой таблицей. Мы вернемся к этой теме позднее. Аффинные преобразования растров Применение методов GetPixel Index и SetPixel Index, созданных в предыдущем разделе, лучше продемонстрировать на конкретном примере. Давайте попробуем реализовать общий алгоритм аффинных преобразований растров. Вообще говоря, основные принципы решения этой задачи уже встречались нам ранее при имитации функции PlgBlt. В листинге 12.2 приведены две функции: KDIB: :PlgBlt и KDIB: :TransformBitmp. Функция KDIB::PlgBlt преобразует прямоугольник, находящийся внутри DIB- растра, в параллелограмм, находящийся внутри другого DIB-растра. Параллелограмм определяется тремя точками приемной поверхности. Функция KDIB::PlgBlt, как и одноименная функция GDI, поддерживает любые двумерные аффинные преобразования, включая смещение, зеркальное отражение, повороты и сдвиги. По своей структуре KDIB::PlgBlt напоминает нашу имитацию функции GDI PlgBlt, но для работы с пикселами вместо медленных функций GDI GetPixel и SetPixel в ней используются функции GetPixel Index и SetPixel Index. Листинг 12.2. Общие аффинные преобразования растров BOOL KDIB::PlgBlt(const POINT * pPoint. KDIB * pSrc. int nXSrc. int nYSrc, int nWidth, int nHeight) { KReverseAffine map(pPoint); map.Setup(nXSrc, nYSrc. nWidth. nHeight): for (int dy-map.miny; dy<«map.maxy; dy++) for (int dx»map.minx; dx<«map.maxx; dx++) { float sx, sy: map.Map(dx. dy, sx, sy); if ( (sx>=nXSrc) && (sx<(nXSrc+nWidth)) ) if ( (sy>»nYSrc) && (sy<(nYSrc+nHeight)) ) SetPixelIndex(dx, dy. pSrc->GetPixelIndex( (int)sx. (int)sy)); } Продолжение &
668 Глава 12. Графические алгоритмы и растры Windows Листинг 12.2. Продолжение return TRUE; } HBITMAP KDIB::TransformBitmap(XFORM * xm. COLORREF crBack) { int xO. yO, xl. yl. x2. y2. x3. y3; Map(xm, 0. 0. xO. yO); // 0 1 Map(xm. m_nWidth. 0. xl. yl); // Map(xm, 0. m_nHeight. x2. y2); 111 3 Map(xm, mjiWidth. mjiHeight. x3, y3); int xmin, xmax; int ymin, ymax; minmax(x0. xl. x2. x3. xmin. xmax); minmax(y0, yl, у2. уЗ. ymin. ymax); int destwidth = xmax - xmin; int destheight = ymax - ymin; KBitmapInfo dest; dest.SetFormat(destwidth. destheight. m_pBMI->bmi Header.bi Bi tCount. m_pBMI->bmi Header.bi Compressi on); BYTE * pBits; HBITMAP hBitmap » CreateDIBSection(NULL. dest.GetBMK). DIB_RGB_COLORS. (void **) & pBits. NULL. NULL); if ( hBitmap==NULL ) return NULL; { HDC hMemDC - CreateCompatibleDC(NULL); HGDIOBJ hOld - SelectObject(hSMemDC. hBitmap): HBRUSH hBrush - CreateSolidBrush(crBack); RECT rect - { 0. 0. destwidth. destheight }: FillRect(hMemDC. & rect. hBrush); DeleteObject(hBrush); SelectObject(hMemDC. hOld): DeleteObjectChMemDC); } KDIB destDIB; destDIB.AttachDIB(dest.GetBMK). pBits, 0); POINT P[3] = { { x0-xmin. yO-ymin }. { xl-xmin. yl-ymin }. { x2-xmin. y2-ymin } }: destDIB.PlgBlt(P. this. 0. 0. mjiWidth. mjiHeight); return hBitmap;
Аффинные преобразования растров 669 Функция KDIB: rPlgBlt предполагает, что заранее был создан приемный растр нужного размера, формат пикселов которого соответствует формату растра-источника. В результате преобразования растра обычно генерируется новый растр другого размера. При поворотах и сдвигах возникают уголки, которые должны заполняться цветом фона, поскольку они лежат за пределами преобразованного изображения. Функция KDIB: :TransformBitmap отвечает за «подготовку сцены» — к вызову KDIB: :PlgBlt. При вызове ей передается матрица преобразования и цвет фона. На основании текущего формата DIB-растра функция вычисляет точный размер преобразованного растра и создает DIB-секцию соответствующего размера с текущим форматом растра. Перед передачей функции KDIB: :PlgBlt для непосредственного преобразования созданная DIB-секция закрашивается цветом фона. На рис. 12.1 изображена картинка с цветами, повернутая на 15° функцией KDIB::PlgBlt. Рис. 12.1. Поворот растров функцией KDIB::PlgBLt На компьютере с относительно слабым процессором Pentium 200 МГц функция KDIB::PlgBlt рассчитывает поворот изображения 1024 х 768, 24 бит/пиксел за 1,062 секунды; получается 0,7 мегапиксела в секунду. Если для сравнения заменить вызовы GetPixellndex/SetPixel Index вызовами функций GDI GetPixel/ SetPixel, время обработки увеличивается до 16,9 секунды (0,044 мегапиксела в секунду). Эксперимент наглядно доказывает, что прямой доступ к пикселам работает гораздо быстрее функций GDI GetPixel/SetPixel. Учитывая, что функция KDIB::PlgBlt использует вещественные вычисления, выигрыш по быстродействию оказывается даже больше, чем в 17 раз.
670 Глава 12. Графические алгоритмы и растры Windows Быстрые специализированные преобразования растров Когда быстродействие выходит на первый план, общие алгоритмы приходится оптимизировать для конкретных ситуаций. Специализация особенно важна для графических алгоритмов — таких, как преобразование изображений. Если вам захочется писать специализированные функции для разных форматов DIB, можно закодировать операции с пикселами конкретного формата DIB «на месте»; это позволит избавиться от издержек на вызов функции во внутреннем цикле, проверку формата растра, двойное вычисление адресов пикселов и т. д. Оптимизация также возможна в области применения вещественных вычислений для отображения координат приемного растра в координаты источника. Стандартная реализация преобразований вещественных чисел в целые работает очень медленно, поскольку в ней задействован вызов функции. В листинге 12.3 приведена функция преобразования растров, не использующая вещественных вычислений и работающая только с 24-разрядными растрами. Функция P1gB1t24 начинается так же, как и PlgBlt — с подготовки обратного преобразования из приемника в источник. Функция KReverseAffine: .-Setup возвращает ограничивающий прямоугольник приемной поверхности, который затем сравнивается с размерами приемного растра, чтобы убедиться в правильности полученных значений. Параметры ограничивающего прямоугольника источника преобразуются к формату с фиксированной точкой умножением на константу FACTOR, равную 65 536. Затем аналогичные операции выполняются с матрицей преобразования. В данном случае используется формат с фиксированной точкой, состоящий из 16-разрядной целой и 16-разрядной дробной частей. Такое представление позволяет работать с большими растрами и обеспечивает достаточную точность. Листинг 12.3. Оптимизированная функция преобразования 24-разрядных DIB-растров BOOL KDIB::PlgBlt24(const POINT * pPoint. KDIB * pSrc. int nXSrc, int nYSrc, int nWidth, int nHeight) { // Множитель для перехода от FLOAT к формату с фиксированной точкой const int FACTOR = 65536; // Сгенерировать обратное преобразование от приемника к источнику KReverseAffine map(pPoint); map.Setup(nXSrc, nYSrc, nWidth. nHeight); // Обеспечить принадлежность границам растра приемника if ( map.minx < 0 ) map.minx = 0; if ( map.maxx > mjiWidth ) map.maxx = mjiWidth; if ( map.miny < 0 ) map.miny = 0; if ( map.maxy > mjiHeight ) map.maxy - mjiHeight; // Прямоугольник источника в формате с фиксированной точкой
Быстрые специализированные преобразования растров 671 int sminx - nXSrc * FACTOR; int sminy = nYSrc * FACTOR; int smaxx = ( nXSrc + nWidth ) * FACTOR; int smaxy - ( nYSrc + nHeight ) * FACTOR; // Матрица преобразования в формате с фиксированной точкой int mil = (int) (map.m_xm.eMll * FACTOR); int ml2 - (int) (map.m_xm.eM12 * FACTOR); int m21 = (int) (map.m_xm.eM21 * FACTOR); int m22 = (int) (map.m_xm.eM22 * FACTOR); int mdx = (int) (map.m_xm.eDx * FACTOR); int mdy = (int) (map.m_xm.eDy * FACTOR); BYTE * SOrigin = pSrc->m_pOrigin; int SDelta = pSrc->m_nDelta; // Перебрать строки развертки приемного растра for (int dy=map.miny; dy<map.maxy; dy++) { // Вычислить адрес первого пиксела в приемнике BYTE * pDPixel = m_pOrigin + dy * mjiDelta + map.minx * 3; // Адрес первого пиксела в источнике int sx = mil * map.minx + m21 * dy + mdx; int sy = ml2 * map.minx + m22 * dy + mdy; // Перебрать все пикселы в строке развертки for (int dx=map.minx; dx<map.maxx; dx++, pDPixel+=3, sx+=mll, sy+=ml2) if ( (sx>=sminx) && (sx<smaxx) ) if ( (sy>=sminy) && (sy<smaxy) ) { // Адрес пиксела источника BYTE * pSPixel - SOrigin + (sy/FACTOR) * SDelta; // Скопировать три байта * ((RGBTRIPLE *)pDPixel) - ((RGBTRIPLE *)pSPixel)[sx/FACTOR]: return TRUE; } Для каждой строки развертки адрес пиксела вычисляется всего один раз и сохраняется в переменной pDPixel, которая позднее увеличивается на три байта для каждого пиксела (для 24-разрядного растра). Таким образом, издержки на каждый пиксел приемника сокращаются до простого сложения. Вычисление пиксела источника, соответствующего текущему пикселу приемника, производится «на месте»; значение преобразуется в формат с фиксированной точкой. Исходные значения sx, sy, вычисленные за пределами внутреннего цикла, увеличиваются на элементы матрицы преобразования еМН и еМ12. Полученные значения сравниваются с границами ограничивающего прямоугольника в формате с фиксированной точкой, чтобы в выборке участвовали только пикселы растра-
672 Глава 12. Графические алгоритмы и растры Windows источника. Для получения адреса пиксела источника числа с фиксированной точкой sx и sy необходимо преобразовать в целые числа; задача решается простым делением на константу FACTOR. Компилятор достаточно умен, чтобы заменить деление операцией сдвига. При копировании данных пиксела снова используется структура RGBTRIPLE. 24-разрядный растр 1024 х 768, использованный при тестировании класса KDIB::PlgBlt, наша улучшенная функция PlgBU24 поворачивает за 172 миллисекунды. Таким образом, в секунду обрабатывается 4,36 мегапиксела — по сравнению с общим решением на базе GetPixellndex/SetPixelIndex достигается выигрыш в 520%. А если сравнить с решением на базе GetPixel/SetPixel, функция PlgBlt24 работает в 100 раз быстрее! Более того, возможности оптимизации PlgBlt24 еще не исчерпаны. Например, вместо проверки каждого пиксела на принадлежность ограничивающему прямоугольнику растра-источника можно заранее вычислять точки пересечения приемной строки развертки с ограничивающим прямоугольником источника, что позволит обойтись без проверок на уровне отдельных пикселов. Преобразования цветов Существует множество графических алгоритмов, в которых каждый пиксел растра должен изменяться по тем или иным правилам. Цветовые преобразования применяются к каждому пикселу независимо от остальных, вне какого-либо глобального контекста. Примерами таких алгоритмов является преобразование цветных растров в оттенки серого, гамма-коррекция, преобразования цветовых пространств, регулировка оттенка, яркости или насыщенности и т. д. Все алгоритмы преобразования цветов построены по одному шаблону. Если у растра имеется цветовая таблица, преобразованиям подвергаются все элементы цветовой таблицы. В противном случае мы перебираем все пикселы растра и применяем преобразование к каждому пикселу в отдельности. В простейшем варианте используется общий алгоритм, которому среди параметров передается указатель на функцию. Каждое преобразование цвета описывается простой статической функций. Чтобы обработать растр с применением заданного преобразования, достаточно вызвать общий алгоритм и передать специализированную функцию преобразования цвета в качестве параметра. В другом, похожем решении определяется абстрактный класс цветового преобразования с виртуальной функций, выполняющей непосредственную работу. В растровых алгоритмах быстродействие обычно является критическим фактором, поэтому вызов простой или виртуальной функции для каждого пиксела большого растра оказывается неприемлемым. Конечно, мы не хотим заново повторять один и тот же код или строить программу на базе макросов. Остается единственная альтернатива — функции-шаблоны. Конечно, лучше было бы определить эти алгоритмы для класса KDIB, однако в ситуации, когда компилятор C++ не позволяет определять функции-шаблоны в качестве членов класса, придется создать статическую функцию-шаблон, которой передается указатель на экземпляр KDIB. Ситуация усложняется тем, что
Преобразования цветов 673 компилятор C++ не поддерживает и дружественных функций-шаблонов, поэтому некоторые закрытые члены класса придется преобразовать в открытые. В листинге 12.4 приведен алгоритм преобразования цветов DIB-растра, построенный на базе шаблона. Листинг 12.4. Шаблон для преобразования цветов растра template <class Dummy> bool ColorTransform(KDIB * dib. Dummy map) { // Цветовая таблица OS/2 DIB: 1-. 4-, 8 бит/пиксел, сжатие RLE if ( dib->m_pRGBTRIPLE ) { for (int i=0; i<dib->m_nClrUsed; i++) map(dib->m_pRGBTRIPLE[i].rgbtRed. di b->m_pRGBTRIPLE[i].rgbtGreen. dib->m_pRGBTRIPLE[i].rgbtBlue); return true; } // Цветовая таблица Windows DIB: 1-. 4-, 8 бит/пиксел, сжатие RLE if ( dib->m_pRGBQUAD ) { for (int i=0; i<dib->m_nClrUsed; i++) map(dib->m_pRGBQUAD[i].rgbRed, di b->m_pRGBQUAD[i].rgbGreen. dib->m_pRGBQUAD[i].rgbBlue); return true: } for (int y=0: y<dib->m_nHeight; y++) { int width = dib->m_nWidth: unsigned char * pBuffer = (unsigned char *) dib->m_pBits + dib->m_nBPS * y; switch ( dib->m_nImageFormat ) { case DIB_16RGB555: // 15-разрядный формат RGB. 5-5-5 for (; width>0: width--) { BYTE red = ( (* (WORD *) pBuffer) & 0x7C00 ) » 7; BYTE green = ( (* (WORD *) pBuffer) & ОхОЗЕО ) » 2; BYTE blue = ( (* (WORD *) pBuffer) & OxOOlF ) « 3: map( red. green, blue ); * ( WORD *) pBuffer - ( ( red » 3 ) « 10 ) | ( ( green » 3 ) « 5 ) | ( blue » 3 ): pBuffer += 2; Продолжение^
674 Глава 12. Графические алгоритмы и растры Windows Листинг 12.4. Продолжение } break; case DIB_16RGB565: // 16-разрядный формат RGB, 5-6-5 for (; width>0; width--) { BYTE red - ( (* (WORD *) pBuffer) & 0xF800 ) » 8 BYTE green « ( (* (WORD *) pBuffer) & 0x07E0 ) » 3 BYTE blue = ( (* (WORD *) pBuffer) & OxOOlF ) « 3 map( red. green, blue ); * ( WORD *) pBuffer - ( ( red » 3 ) « 11 ) | ( ( green » 2 ) « 5 ) | ( blue » 3 ); pBuffer += 2; } break; case DIB_24RGB888: // 24-разрядный формат RGB for (; width>0; width--) { map( pBuffer[2]. pBuffer[l], pBuffer[0] ); pBuffer +- 3; } break; case DIB_32RGBA8888: // 32-разрядный формат RGBA case DIB_32RGB888: // 32-разрядный формат RGB for (; width>0; width--) { map( pBuffer[2]. pBuffer[l], pBuffer[0] ); pBuffer += 4; } break; default: return false; } } return true; } Функция ColorTransform получает два параметра: указатель на экземпляр KDIB и указатель на функцию. Конечно, передача указателя на функцию без предварительного задания прототипа выглядит несколько странно, но очевидно, этот способ поддерживается и используется в STL. Первая часть функции обрабатывает цветовые таблицы ВМР-файлов в формате OS/2: каждая структура RGBTRIPLE обрабатывается вызовом функции преобразования цветов (параметр, тар). Функция преобразования цветов получает по ссылке три параметра (красный, зеленый и синий канал) и возвращает преобразованный цвет в этих же переменных. Фрагмент для работы с цветовой таблицей растров Windows выглядит аналогично, если не считать того, что на этот раз используется структура RGBQUAD.
Преобразования цветов 675 В этой части кода обрабатываются все форматы DIB с палитрой, включая сжатые и несжатые форматы RLE. Оставшийся код обрабатывает 16-разрядные растры High Color, 24- и 32-разрядные растры True Color с альфа-каналами. Логический порядок массива пикселов в данном случае роли не играет, поскольку программа просто перебирает пикселы в порядке их расположения в памяти. Для 16-разрядных растров поддерживаются два распространенных формата. Программа должна извлечь каналы RGB, преобразовать каждый из них в 8-разрядную величину, вызвать функцию преобразования цвета, а затем снова упаковать полученный результат в 16- разрядное слово. С 24-разрядными растрами все совсем просто. В 32-разрядном растре альфа-канал остается без изменений. Все остальные экзотические форматы DIB (например, внедренные изображения JPEG или PNG, а также растры с нестандартными битовыми полями) не поддерживаются текущей реализацией функции ColorTransform. Преобразование растров в оттенки серого Преобразование цветов из пространства RGB в оттенки серого обычно осуществляется по формуле: Серый = 0,299 х Красный + 0,587 х Зеленый + 0,114 х Синий В компьютерной реализации нам хотелось бы обойтись без вычислений с плавающей точкой. Ниже приведен метод (построенный на базе шаблона Col or- Transform) преобразования растра RGB в оттенки серого цвета. // 0.299 * красный + 0.587 * зеленый + 0.114 * синий inline void MaptoGray(BYTE & red, BYTE & green, BYTE & blue) red - ( red * 77 + green * 150 + blue * 29 + 128 ) / 256; green = red; blue - red; class KImage : public KDIB public; bool ToGreyScale(void); bool KImage:;ToGreyScale(void) return ColorTransform(this, MaptoGray); Для инкапсуляции алгоритмов обработки растров, разработанных в этой главе, мы создаем класс KImage, производный от KDIB. Класс KImage не содержит дополнительных переменных. Из всех методов этого класса выше приведен только метод ToGreyScale. Позднее мы добавим в этот класс другие методы. Метод KImage::ToGreyScale преобразует текущий цветной DIB-растр в оттенки серого. Для этого он просто вызывает функцию-шаблон ColorTransform и передает ей функцию преобразования цвета MaptoGray. Функция MaptoGray, исполь-
676 Глава 12. Графические алгоритмы и растры Windows зуя целочисленные операции, вычисляет яркость серого цвета и присваивает ее всем трем каналам RGB. В отладочной версии MaptoGray компилируется как отдельная функция, указатель на которую передается ColorTransform. В окончательной версии для достижения оптимального быстродействия все вызовы MaptoGray заменены подставляемым кодом. Гамма-коррекция Выводимые изображения подвержены фотометрическим искажениям, обусловленным нелинейной реакцией экрана монитора на интенсивность сигнала. Фотометрическая реакция устройства вывода называется гамма-реакцией (gamma response). В разных операционных системах для экрана монитора используются разные гамма-характеристики. Например, изображение, подготовленное на компьютере Macintosh, на PC выглядит слишком темным. С другой стороны, изображение, переданное с сервера PC на Macintosh, может показаться излишне светлым. Для компенсации этих различий приходится корректировать гамма-характеристики устройства. Гамма-коррекция обычно выполняется независимо по всем трем каналам RGB. Три массива по 256 байт вычисляются заранее и передаются программному гамма-преобразователю или видеоадаптеру. Каждый массив относится к одному из каналов. Гамма-коррекция легко реализуется с помощью функции-шаблона Color- Transform. BYTE redGammaRamp[256]: BYTE greenGammaRamp[256]; BYTE blueGammaRamp[256]; inline void MapGamma(BYTE & red. BYTE & green. BYTE & blue) { red = redGammaRamp[red]: green = greenGammaRamp[green]; blue = blueGammaRamp[blue]; } BYTE gamma(double g. int index) { return min(255. (int) ( (255.0 * pow(index/255.0. 1.0/g)) + 0.5 ) ); } bool KImage::GammaCorrect(double redgamma, double greengamma. double bluegamma) { for (int i=0; i<256; i++) { redGammaRamp[i] = gamma( redgamma. i); greenGammaRamp[i] - gamma(greengamma. i); blueGammaRamp[i] = gamma( bluegamma. i); } return ColorTransform(this. MapGamma); }
Преобразования цветов 677 В приведенном фрагменте реализуется функция пользовательского уровня KDIB: :GammaCorrect. Эта функция получает три независимых гамма-коэффициента, значения которых обычно лежат в интервале от 0,2 до 5,0. Функция вычисляет три гамма-таблицы (по одной для каждого RGB-канала) по определению гамма-коррекции, после чего вызывает функцию ColorTransform и передает ей в качестве преобразователя функцию MapGamma. Функция MapGamma просто берет из таблицы элемент с заданным индексом. Гамма-коррекция с коэффициентом, равным 1, представляет собой тождественное преобразование цвета. При гамма-коэффициенте меньше 1 изображение «темнеет», а если коэффициент превышает 1 — «светлеет». Если применить гамма-коррекцию 2,2 к изображению, подготовленному на Macintosh, оно будет выглядеть точно так же, как во время создания. На рис. 12.2 показано изображение тигра до и после гамма-коррекции. Рис. 12.2. Гамма-коррекция Механизм поиска в таблице, реализованный функцией MapGamma, может использоваться и для регулировки цвета по другим критериям. На самом деле имеется лишь одно обязательное условие — каналы RGB должны быть независимыми друг от друга. Например, redGammaRamp можно определить таким образом, чтобы интенсивность красного канала уменьшалась на 10 %, а остальные каналы оставались без изменений. Win32 GDI поддерживает настройку характеристик гамма-коррекции графического устройства, если оборудование и драйвер устройства поддерживают загрузку гамма-таблиц. Задача решается функцией SetDeviceGammaRamp, входящей
678 Глава 12. Графические алгоритмы и растры Windows в ICM 2.0. В DirectDraw операции с гамма-таблицами также выполняются через интерфейс IDirectDrawGammaControl. Все современное оборудование PC должно поддерживать загрузку гамма-таблиц. Преобразование пикселов в растрах Шаблонный алгоритм преобразования цветов, представленный в предыдущем разделе, в действительности перебирает цвета, а не пикселы растра. Впрочем, различия касаются в основном растров с палитрой, для которых алгоритм преобразования цветов просто перебирает все элементы цветовой таблицы (вместо всех пикселов растра). Существует большой класс алгоритмов обработки графических изображений, требующих обслуживания каждого пиксела. Допустим, при построении гистограммы вам придется перебрать все пикселы, чтобы вычислить истинное распределение цветов в растре. При делении цветного растра на несколько каналов желательно, чтобы результаты представляли собой отдельные изображения в оттенках серого, с которыми можно выполнять дальнейшие операции. В алгоритмах цветоделения, используемых графическими редакторами, также организуется перебор всех пикселов. В этом разделе мы построим общий алгоритм преобразования пикселов растра и продемонстрируем его на нескольких практических примерах. На этот раз вместо шаблона будут использоваться указатель на функцию, виртуальная функция и абстрактный базовый класс. Вариант с применением шаблонов из предыдущего раздела обеспечивал очень хорошее быстродействие, за которое приходилось расплачиваться созданием нескольких копий двоичного кода для каждого экземпляра шаблона. Другое ограничение, обусловленное спецификой компилятора, заключается в том, что шаблон воплощается в виде простой функции. Мы не можем использовать класс C++, инкапсулирующий данные вместе с кодом. В частности, для реализации гамма-коррекции требовались глобальные переменные. Родовой класс преобразований пикселов В листинге 12.5 приведен класс KPixel Mapper — абстрактный базовый класс, на основе которого создаются различные алгоритмы преобразования пикселов. Этот класс предназначен для обработки отдельных пикселов или одиночных строк развертки. Листинг 12.5. Абстрактный базовый класс KPixelMapper // Абстрактный класс для преобразования // отдельных пикселов и строк развертки class KPixelMapper { BYTE * m_pColor; // Указатель на цветовую таблицу BGR... int mjiSize; // Размер элемента таблицы (3 или 4) int m nCount; // Количество элементов в таблице
Преобразование пикселов в растрах 679 // Вернуть true, если данные изменились virtual bool MapRGBCBYTE & red. BYTE & green. BYTE & blue) - 0; // Вернуть true, если данные изменились virtual bool MapIndexCBYTE & index) { MapRGB(m_pColor[index*m_nSize+2], m_pColor[index*m_nSize+l]. m_pColor[index*m_nSi ze]); return false; public: KPixelMapper(void) { m_pColor = NULL; mjiSize - 0; m_nCount = 0; } virtual ~ KPixelMapperO void SetColorTableCBYTE * pColor. int nEntrySize. int nCount) { m_pColor - pColor; mjiSize = nEntrySize; mjiCount = nCount; } virtual bool StartLine(int line) { return true; virtual void Maplbpp(BYTE * pBuffer. int width) virtual void Map2bpp(BYTE * pBuffer. int width) virtual void Map4bpp(BYTE * pBuffer. int width) virtual void Map8bpp(BYTE * pBuffer. int width) virtual void Map555(BYTE * pBuffer. int width) virtual void Map565(BYTE * pBuffer. int width) virtual void Map24bpp(BYTE * pBuffer. int width); virtual void Map32bpp(BYTE * pBuffer. int width); void KPixelMapper::Maplbpp(BYTE * pBuffer. int width) { BYTE mask = 0x80; int shift = 7; for (; width>0; width--) Продолжение &
680 Глава 12. Графические алгоритмы и растры Windows Листинг 12.5. Продолжение { BYTE index = ( ( pBuffer[0] & mask ) » shift ) & Oxl; if ( Maplndex(index) ) pBuffer[0] = ( pBuffer[0] & ~ mask ) || (( index & OxOF) « shift); mask »= 1; shift -= 1; if ( mask==0 ) { pBuffer ++; mask = 0x80; shift = 7; } } } void KPixelMapper;:Map24bpp(BYTE * pBuffer. int width) { for (; width>0; width--) { MapRGB( pBuffer[2]. pBuffer[l]. pBuffer[0] ); pBuffer += 3; } } Все основные методы класса являются виртуальными. Метод MapRGB представляет собой чисто виртуальную функцию, обрабатывающую один пиксел в формате RGB. Классом KPi xel Mapper он не реализуется, поскольку предполагается, что производный класс предоставит собственную реализацию для выбранного алгоритма. Метод Maplndex работает с пикселами в формате индекса цветовой таблицы. Наша стандартная реализация преобразует цветовой индекс в значение RGB и вызывает MapRGB. Методы Maplbpp, Map2bpp, ..., Map32bpp обеспечивают обработку строк развертки для всех распространенных форматов DIB-растров. Их стандартная реализация перебирает все пикселы в строке развертки и вызывает для каждого пиксела MapRGB или Maplndex. Все эти методы оформлены в виде виртуальных функций, поэтому производный класс может реализовать их по-своему. Например, производный класс может решить, что 24-разрядные изображения для него особенно важны, переопределить Мар24Ьрр и заменить вызовы MapRGB подставляемым кодом для получения максимального быстродействия. Учтите, что для быстродействия критическую роль играет внутренний цикл. В листинге приведены два обработчика строк развертки для 1-й 24-разрядного формата. Обе функции, MapRGB и Maplndex, возвращают логический признак изменения параметров, переданных по ссылке. На основании полученного значения вызывающая сторона может решить, следует ли изменять исходный пиксел. Чтобы воспользоваться классом KPi xel Mapper для преобразования DIB-растра, мы создаем новую функцию KImage:: Pi xel Transform, которая должна создать экземпляр класса KPixelMapper и передать ему строки развертки. Функция Pixel- Transform приведена ниже — как видите, она устроена очень просто.
Преобразование пикселов в растрах 681 bool KImage::PixelTransform(KPixelMapper & map) { if ( m_pRGBTRIPLE ) map.SetColorTable((BYTE *) m_pRGBTRIPLE, sizeof(RGBTRIPLE), mjiClrUsed); else if ( m_pRGBQUAD ) map.SetColorTable((BYTE *) m_pRGBQUAD, sizeof(RGBQUAD). mjiClrUsed); for (int y=0; y<mjiHeight; y++) { unsigned char * pBuffer = (unsigned char *) m_pBits + m_nBPS * y; if ( ! map.StartLine(y) ) break; switch ( mjiImageFormat ) { case DIB_1BPP: map.Maplbpp(pBuffer. mjiWidth); break; case DIB_2BPP: map.Map2bpp(pBuffer. mjiWidth); break; case DIB_4BPP: map.Map4bpp(pBuffer, mjiWidth); break; case DIB_8BPP: map.Map8bpp(pBuffer. mjiWidth); break; case DIB_16RGB555: // 15-разрядный формат RGB, 5-5-5 map.Map555(pBuffer, mjiWidth); break; case DIB_16RGB565: // 16-разрядный формат RGB, 5-6-5 map.Map565(pBuffer, mjiWidth); break; case DIB_24RGB888: // 24-разрядный формат RGB map.Map24bpp(pBuffer, mjiWidth); break; case DIB_32RGBA8888: // 32-разрядный формат RGBA case DIB_32RGB888: // 32-разрядный формат RGB map.Map32bpp(pBuffer, mjiWidth); break; default: return false; return true;
682 Глава 12. Графические алгоритмы и растры Windows Мы наблюдаем четкое разделение обязанностей: класс, производный от KPixel - Mapper, занимается преобразованием отдельных пикселов, сам класс KPixel Mapper преобразует строки развертки, а метод KImage: :PixelTransform преобразует весь DIB-растр. Если вы захотите поддерживать растровый формат, отличный от формата BMP, вам придется лишь написать свою собственную функцию Pixel- Transform. Если потребуется реализовать новый графический алгоритм из области преобразования пикселов, достаточно написать класс, производный от KPixelMapper. Родовой класс цветоделения Давайте займемся вполне практической задачей — реализацией алгоритма цветоделения, то есть построения в каждом из каналов изображений в оттенках серого по цветному изображению. Общая идея заключается в отображении RGB- пиксела на байт, сохраняемый в 8-разрядном растре с цветовой таблицей в оттенках серого. Как обычно, наша реализация должна быть как можно более универсальной, чтобы она могла поддерживать разные типы цветоделения. На этот раз нам понадобится простая функция, управляющая классом цветоделения (Operator в листинге 12.6). Листинг 12.6. Цветоделение с применением класса KPixelMapper typedef BYTE (* Operator)(BYTE red. BYTE green, BYTE blue); // Родовой класс цветоделения, производный от KPixelMapper // Управляется функций Operator, передаваемой «Channel::Split class KChannel : public KPixelMapper { Operator mJDperator; int mjiBPS: BYTE * m_pBits; BYTE * nrpPixeT: // Вернуть true, если данные изменились virtual bool MapRGB(BYTE & red. BYTE & green. BYTE & blue) { * mjDPixel ++ - m_Operator(red. green, blue): return false; } virtual bool StartLine(int line) { mjpPixel - m_pBits + line * mjiBPS; // Первый пиксел // строки развертки return true; } public: BITMAPINFO * SplitCKImage & dib. Operator oper); }:
Преобразование пикселов в растрах 683 BITMAPINFO * KChannel::SplitCKImage & dib. Operator oper) { mJDperator = oper; mjiBPS = (dib.GetWidthO +3) /4*4; // Размер строки развертки // для 8-разрядного DIB int headsize - sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD); BITMAPINFO * pNewDIB - (BITMAPINFO *) new BYTE [headsize + mjiBPS * abs(dib.GetHeightO)]; memset(pNewDIB. 0. headsize); pNewDIB->bmiHeader.biSize - sizeof(BITMAPINFOHEADER); pNewDIB->bmiHeader.biWidth - dib.GetWidthO; pNewDIB->bmiHeader.biHeight - dib.GetHeightO; pNewDIB->bmiHeader.biPlanes - 1; pNewDIB->bmiHeader.biBitCount = 8; pNewDIB->bmiHeader.biCompression = BI_RGB; for (int c=0; c<256; C++) { pNewDIB->bmiColors[c].rgbRed = c; pNewDIB->bmiColors[c].rgbGreen = c; pNewDIB->bmiColors[c].rgbBlue = c; m_pBits - (BYTE*) & pNewDIB->bmiColors[256]; if ( pNewDIB==NULL ) return NULL; dib.Pixe"ITransform(* this); return pNewDIB; } BITMAPINFO * KImage::SplitChannel(Operator oper) { KChannel channel; return channel.Split(* this, oper); } Класс KChannel является производным от KPixel Mapper. Центральное место в нем занимает метод Split, получающий ссылку на DIB и Operator. Метод Split создает 256-цветный DIB-растр, размеры которого совпадают с размерами исходного растра, заполняет палитру оттенков серого и сохраняет адрес массива пикселов в переменной mjpBits, которая будет использоваться при переборе пикселов. Затем вызывается метод KDIB:: Pixel Transform, перебирающий все пикселы растра, что в конечном счете приводит к вызову KChannel:: MapRGB. Наша реализация MapRGB вызывает Operator для отображения RGB-пиксела в байт и сохраняет полученное значение в качестве значения пиксела создаваемого 256-цветного растра. Метод StartLine вызывается в начале каждой строки развертки, что
684 Глава 12. Графические алгоритмы и растры Windows позволяет программе правильно устанавливать начальную позицию приемной строки. Класс работает с одним каналом. Для обработки нескольких каналов следует либо организовать последовательную обработку, либо воспользоваться новой реализацией, которая создает несколько 8-разрядных DIB-растров и получает новый тип Operator, возвращающий сразу несколько результатов. Пример выделения каналов Работать с классом KChannel несложно; все, что от вас потребуется, — предоставить нужную функцию. Ниже приведено несколько примеров функций для выполнения распространенных операций в моделях RGB, CMYK и HLS. // Выделение красного канала в RGB inline BYTE TakeRedCBYTE red. BYTE green, BYTE blue) { return red; } // Выделение черной составляющей в KCMY inline BYTE TakeK(BYTE red, BYTE green, BYTE blue) { // min ( 255-red, 255-green. 255-blue) if ( red < green ) if ( green < blue ) return 255 - blue: else return 255 - green; else return 255 - red; } // Выделение оттенка в HLS inline BYTE TakeH(BYTE red. BYTE green. BYTE blue) { KColor color(red. green, blue): color.ToHLSO; return (BYTE) (color.hue * 255 / 360); } Ниже показано, как эти функции используются в KDIBView — классе дочерних окон MDI, отображающих содержимое DIB. LRESULT KDIBView::OnCommand(int nld) { switch( nld ) { case IDM_COLOR_SPLITRGB: CreateNewView(m_DIB.SplitChannel(TakeRed), "Red Channel"); CreateNewView(m_DIB.SplitChannel(TakeGreen), "Green Channel"): CreateNewView(m_DIB.SplitChannel(TakeBlue), "Blue Channel"); return 0; case IDM_COLOR_SPLITHLS: CreateNewView(m_DIB.SplitChannel(TakeH), "Hue Channel");
Преобразование пикселов в растрах 685 CreateNewView(m_DIB.SplitChannel(TakeL), CreateNewView(m_DIB.SplitChannel(TakeS). return 0; case IDM_COLOR_SPLITKCMY: CreateNewView(m_DIB.SplitChannel(TakeK), CreateNewView(m_DIB.SplitChannel(TakeC). CreateNewView(m_DIB.SplitChannel(TakeM), CreateNewView(m_DIB.SplitChannel(TakeY), return 0; "Lightness Channel"); "Saturation Channel"); "Black Channel"); "Cyan Channel"); "Magenta Channel"); "Yellow Channel"); Функция SplitChannel возвращает указатель на упакованный DIB-растр. Функция KDIBView: :CreateNew использует его для создания нового дочернего окна MDI, в котором этот DIB-растр выводится. При выборе одной из команд выделения каналов в главном окне MDI создается несколько новых окон; в каждом окне выводится новый DIB-растр в оттенках серого. На рис. 12.3 показан результат деления куба RGB на каналы RGB. Обратите внимание: в оттенках серого светлые цвета обладают более высокой интенсивностью, темные цвета — более низкой интенсивностью. Это объясняет и то, почему один из трех ромбов на каждом изображении окрашен в чистый белый цвет — потому что на этой грани исходного цветного куба соответствующий канал обладал максимальной интенсивностью (255). Ряс. 12.3. Выделение цветовых каналов RGB
686 Глава 12. Графические алгоритмы и растры Windows Гистограмма Чтобы наглядно показать, что класс KPixel Mapper является родовым классом для преобразования пикселов, мы построим совершенно другой производный класс — генератор гистограмм. // Класс для построения гистограмм RGB, производный от KPixelMapper class KHistogram : public KPixelMapper { int m_FreqRed[256]; int m_FreqGreen[256]; int m_FreqBlue[256]; int m_FreqGray[256]; // Вернуть true, если данные изменились virtual bool MapRGB(BYTE & red. BYTE & green, BYTE & blue) { m_FreqRed[red] ++; m_FreqGreen[green] ■ m_FreqBlue[blue] m_FreqGray[(red * 77 + green * 150 + blue * 29 + 128 ) / 256] ++; return false; } public: void SampleCKImage & dib); void KHistogram::SampleCKImage & dib) { memset(m_FreqRed. 0, sizeof(m_FreqRed)): memset(m_FreqGreen. 0, sizeof(m_FreqGreen)); memset(m_FreqB1ue, 0. sizeof(m__FreqBlue)); memset(m_FreqGray, 0, sizeof(m_FreqGray)); dib. Pixel Transforms this): } Класс KHistogram подсчитывает относительные частоты составляющих RGB и уровня серого в четырех целочисленных массивах. Реализация MapRGB просто увеличивает соответствующие счетчики. После вызова KHistogram::Sample накопленные данные гистограмм можно вывести в графическом виде — это поможет пользователю понять, какие изменения следует внести в изображение. Пространственные фильтры В приведенном выше алгоритме значение выходного пиксела определяется одним входным пикселом. Существует другой класс графических алгоритмов, в которых выходной пиксел вычисляется по смежным пикселам. Такие алгоритмы обычно называются пространственными фильтрами (spatial filters). Например,
Пространственные фильтры 687 фильтр сглаживания может генерировать выходной пиксел, вычисляя среднее значение для блока размерами 3x3 пиксела, что позволяет отфильтровать случайный шум. Пространственный фильтр получает исходный растр и строит по нему растр- приемник. Обычно пространственный фильтр обрабатывает блоки, состоящие из N х N пикселов, где N — нечетное числов. В большинстве распространенных пространственных фильтров N = 3. Центр блока соответствует текущему обрабатываемому пикселу, а остальные пикселы — его соседям. При нечетном N блок симметричен относительно центрального пиксела. При обработке всего изображения пространственный фильтр не может применяться к пикселам, расположенным на расстоянии менее (N - 1)/2 пикселов от края, поскольку в этом случае некоторые пикселы блока N х N выходят за пределы изображения. Проблема решается либо прямым копированием пиксела источника в приемник, либо заполнением пикселов, расположенных близко от края, однородным цветом. Классы и функции, приведенные выше, не подходят для работы с пространственными фильтрами. Необходимо новое решение, которое позволяло бы использовать в качестве входных данных для каждого пиксела блок из N х N пикселов. В листинге 12.7 приведен абстрактный класс KFilter. Листинг 12.7. Класс KFilter для работы с пространственными фильтрами // Абстрактный класс для применения пространственных фильтров // на уровне отдельных пикселов и строк развертки class KFilter { int mjiHalf; virtual BYTE Kernel(BYTE * pPixel. int dx, int dy) - 0; public: int GetHalf(void) const { return mjnHalf; } KFilter(void) { mjnHalf - 1; } virtual ~ KFilterO { } virtual void Filter8bpp(BYTE * pDst, BYTE * pSrc. int nWidth, int dy); virtual void Filter24bpp(BYTE * pDst. BYTE * pSrc, int nWidth. int dy); virtual void Filter32bpp(BYTE * pDst, BYTE * pSrc, int nWidth, int dy); virtual void DescribeFilter(HDC hDC. int x. int y) }: void KFilter::Filter8bpp(BYTE * pDst. BYTE * pSrc. int nWidth, int dy) { memcpy(pDst, pSrc, mjnHalf); pDst +« mjnHalf; pSrc += mjnHalf; for (int i=nWidth - 2 * mjiHalf; i>0: i--) * pDst ++ - Kernel(pSrc++, 1. dy); Продолжение^
688 Глава 12. Графические алгоритмы и растры Windows Листинг 12.7. Продолжение memcpy(pDst, pSrc, mjiHalf); } void KFilter::Filter24bpp(BYTE * pDst, BYTE * pSrc, int nWidth, int dy) { memcpy(pDst. pSrc. mjiHalf * 3); pDst += m_nHalf * 3; pSrc += mjiHalf * 3; for (int i=nWidth - 2 * mjiHalf; i>0; i--) { * pDst ++ = Kernel(pSrc++, 3, dy); * pDst ++ = Kernel(pSrc++, 3. dy); * pDst ++ = Kernel(pSrc++. 3, dy); } memcpy(pDst, pSrc. mjiHalf * 3); } void KFilter::Filter32bpp(BYTE * pDst, BYTE * pSrc, int nWidth. int dy) { memcpy(pDst, pSrc, mjiHalf * 4); pDst +- mjiHalf * 4; pSrc += mjiHalf * 4; for (int i=nWidth - 2 * mjiHalf: i>0; i--) { * pDst ++ = Kernel(pSrc++. 4, dy); * pDst ++ - Kernel(pSrc++, 4, dy); * pDst ++ = Kernel(pSrc++, 4. dy); * pDst ++ - * pSrc++: // Копировать альфа-канал } memcpytpDst, pSrc, mjiHalf * 4); } Класс KFilter выглядит значительно проще класса KPixelTransform — в основном из-за того, что он работает только с 8-, 24- и 32-разрядными растрами в оттенках серого. Пространственные фильтры выполняют с пикселами математические операции, не имеющие нормальной интерпретации для изображений с палитрой. В принципе можно было организовать поддержку для 15- и 16-разрядных изображений, однако это существенно увеличит объем работы. Класс KFilter работает с одноканальным изображением в оттенках серого. 24- и 32-разрядные изображения рассматриваются как совокупность нескольких каналов, обрабатываемых независимо друг от друга. Чисто виртуальная функция KFilter::Kernel определяет принцип работы пространственного фильтра. Для Kfilter:: Kernel пиксел представляет собой один байт в интервале 0...255, определяющий интенсивность данного канала. Функция получает указатель на текущий пиксел и смещения следующих пикселов в той же строке и том же столбце. Зная эти три величины, реализация Kernel может обратиться к любому из соседних пикселов при помощи несложных операций сложения и вычитания. Функция возвращает байт, который записывается в выходное изображение вызывающей стороной. Как видите, 15- и 16-разрядные строки развертки плохо вписываются
Пространственные фильтры 689 в эту модель. Переменная mjiHalf содержит значение (N-l)/2, поэтому для фильтров 3x3 она обычно равна 1. Методы Fi1ter8bpp, Fi1ter24bpp и Fi1ter32bpp обрабатывают три типа строк развертки, которые мы поддерживаем: 8-, 24-и 32-разрядные. Они получают указатель на строки развертки приемника и источника, ширина строки развертки в пикселах и смещение следующей строки. В каждой строке развертки первые и последние mjiHalf пикселов просто копируются. Остальные пикселы передаются методу Kernel поканально, а полученные результаты записываются в приемную строку развертки. Функции объявлены виртуальными, чтобы их можно было переопределить в производных классах. В класс KImage добавлен новый метод KImage:: Spatial Filter, предназначенный для передачи DIB классу KFilter. Метод создает новый приемный массив пикселов, копирует в него несколько первых и последних необрабатываемых строк развертки и вызывает один из методов фильтрации KFilter для обработки остальных строк. В завершение старый массив пикселов заменяется новым. Приведенную реализацию можно изменить таким образом, чтобы она генерировала новый растр или сохраняла результат в обработанном массиве пикселов источника, чтобы дополнительные затраты памяти не превышали размера нескольких строк развертки. boo! KImage::SpatialFi 1 ter(KFi 1 ter & pFilter) { BYTE * pDestBits = new BYTE[m_nImageSize]; if ( pDestBits«NULL ) return false; for (int y=0; y<m_nHeight; y++) { BYTE * pBuffer = (BYTE *) m_pBits + m_nBPS * y; BYTE * pDest = (BYTE *) pDestBits + m_nBPS * y; if ( (y>=filter.GetHalf()) && (y<(m_nHeight- filter.GetHalfO)) ) switch ( m_nImageFormat ) { case DIBJBPP: filter.Filter8bpp(pDest, pBuffer, mjiWidth. mjiBPS): break; case DIB_24RGB888: // 24-разрядный RGB pFilter->Filter24bpp(pDest. pBuffer. mjiWidth, mjiBPS); break; case DIB_32RGBA8888: // 32-разрядный формат RGBA case DIB_32RGB888: // 32-разрядный формат RGB pFilter->Filter32bpp(pDest, pBuffer. mjiWidth. mjiBPS): break; default: delete [] pDestBits; return false;
690 Глава 12. Графические алгоритмы и растры Windows } else memcpy(pDest, pBuffer, mjiBPS); } memcpy(m_pBits. pDestBits. m_nImageSize); array delete [] pDestBits; return true; } Пространственный фильтр 3x3 обычно описывается матрицей 3 х 3 и весом. Числа матрицы 3x3 умножаются на цветовые значения соответствующих пикселов блока, а сумма делится на общий вес. Результат может выйти за границы интервала 0...255, используемого для хранения интенсивности цветового канала, поэтому результат иногда приходится усекать. Некоторые фильтры перед усечением прибавляют к результату константу. Ниже приведет шаблон для класса, поддерживающего пространственные фильтры 3 х 3 с дополнительным весом и прибавлением константы: template <int kOO. int kOl. int k02, int klO, int kll. int kl2. int k20, int k21, int k22, int weight, int add, bool checkbound, TCHAR * name> class K33Filter : public KFilter { virtual BYTE Kernel(BYTE * P. int dx, int dy) { int r - ( P[-dy-dx] * kOO + P[-dy] * kOl + P[-dy+dx] * k02 + PC -dx] * klO + P[0] * kll + P[ +dx] * kl2 + P[ dy-dx] * k20 + P[dy] * k21 + P[ dy+dx] * k22 ) / weight + add; if ( checkbound ) if ( г < 0 ) return 0; else if ( r > 255 ) return 255; return r; } }: Класс K33Fi1ter имеет 12 параметров. Первые девять параметров определяют матрицу коэффициентов 3 х 3, за которой следует вес, прибавляемая константа и логическое значение, управляющее проверкой границ. Вообще говоря, реализацию можно было построить на вещественных вычислениях — код остается прежним, изменится только тип данных. Однако в этом случае нам придется выполнять девять умножений с плавающей точкой и преобразовывать вещественное число в целое. Шаблон K33Filter существенно улучшает быстродействие пространственного фильтра за счет применения только целых параметров. Мы работаем лишь с целыми числами, и каждый фильтр получает собственный набор параметров шаблона. С точки зрения компилятора девять умножений и одно деление представляют собой легко оптимизируемые операции с константами.
Пространственные фильтры 691 Если флаг проверки границ не установлен, компилятору не нужно генерировать соответствующий код. При этом увеличение объема кода оказывается минимальным, поскольку для каждого фильтра переопределяется всего одна функция. Давайте воспользуемся нашими классами для определения нескольких пространственных фильтров и посмотрим, на какие чудеса они способны. Фильтры сглаживания и резкости На рис. 12.4 после первого исходного рисунка показаны результаты применения трех пространственных фильтров: сглаживания, сглаживания по Гауссу и резкости (для наглядности масштаб равен 3:1). Гауссово сглаживание | 0 1 0| * I 1 k 1| | 0 1 0| / 8 Сглаживание | 1 1 1| * | 1 1 1| | 1 1 1| / 9 Заострение | 0 -1 8| |-1 9 -1| | 0 -1 0| / 5 Рис. 12.4. Фильтры сглаживания и резкости Три показанных на рисунке фильтра определяются следующим образом: TCHAR szSmooth[] = _T("Smooth"); TCHAR szGuasianSmooth[] - _T("Guasian Smooth"); TCHAR szSharpening[] = _T("Sharpening"); K33Filter< 1, 1. 1, 1, 1, 1. 1. 1. 1. 9, 0. false. szSmooth > filter33_smooth; K33Filter< 0, 1, 0, 1. 4. 1. 0. 1. 0, 8. 0, false, szGuasianSmooth > filter33_guasiansmooth; K33Filter< 0. -1. 0, -1. 9. -1. 0. -1. 0, 5. 0, true, szSharpening > filter33_sharpening: Вверху слева изображена исходная картинка. Справа от нее показан результат применения сглаживающего фильтра. Его матрица 3x3 состоит из одних единиц, а вес равен 9. Следовательно, этот фильтр присваивает пикселу среднее
692 Глава 12. Графические алгоритмы и растры Windows значение пикселов в блоке 3x3. Сглаживающий фильтр называется низкочастотным фильтром, поскольку он сохраняет низкочастотные участки и отфильтровывает высокочастотные искажения. В частности, он может использоваться для сглаживания линий, фигур и растров, выводимых средствами GDI. На рисунке видно, как сглаживающий фильтр маскирует зазубренные края исходной картинки. После применения сглаживающего фильтра на границах глифа появляются серые пикселы. Фильтр сглаживания по Гауссу также относится к категории низкочастотных фильтров. Вместо равномерного распределения этот фильтр назначает больший весовой коэффициент центральному пикселу. Фильтры этого типа могут определяться и для большего радиуса; на рисунке показан фильтр 3x3. Фильтр резкости вычитает соседние пикселы из текущего, чтобы подчеркнуть переходы в изображении. Он относится к категории высокочастотных фильтров, которые выделяют высокочастотные компоненты изображения и оставляют низкочастотные участки без изменений. Регулируя весовой коэффициент центрального пиксела, можно менять степень резкости. Для монохромного изображения, показанного на рисунке, результат применения фильтра резкости практически незаметен. Выделение границ и рельеф На рис. 12.5 показаны результаты применения фильтра Лапласа и двух рельефных фильтров. Эти фильтры определяются следующим образом: TCHAR szLaplasian[] = JTCLaplasian"); TCHAR szEmbossl35[] - _T("Emboss 135°"); TCHAR szEmboss90[] - _T("Emboss 90° 50Г); K33F1lter<-l, -1. -1. -1. 8, -1. -1. -1. -1. 1, 128, true, szLaplasian > filter33_lap1asian; K33Filter< 1, 0, 0, 0. 0. 0, 0. 0. -1. 1, 128. true, szEmbossl35 > filter33_embossl35; K33Filter< 0. 1. 0, 0. 0. 0, 0. -1. 0. 2, 128, true, szEmboss90 > filter33_emboss90; По виду матрицы фильтр Лапласа похож на высокочастотный фильтр, но он генерирует абсолютно другое изображение. Фильтр Лапласа относится к категории фильтров выделения границ с нулевой суммой коэффициентов матрицы. Фильтр выделения границ заменяет равномерно окрашенные области черным цветом, а области с изменениями — цветом, отличным от черного. В приведенном примере фильтр прибавляет к каждому каналу 128, чтобы отрицательный результат не заменялся нулем. В результате прибавления 128 равномерно окрашенные области становятся серыми. Следующие два фильтра, называемые рельефными фильтрами, преобразуют цветное изображение в оттенки серого со своеобразными объемными эффектами. В одном углу матрицы рельефного фильтра стоит 1, а элемент в противоположном углу равен -1. Применение рельефного фильтра можно рассматривать как вычитание изображения, смещенного на определенную величину от оригинала. Результат увеличивается на 128, чтобы нулевая точка переместилась в середину шкалы оттенков серого. Относительные позиции пикселов со значения-
Пространственные фильтры 693 ми 1 и -1 определяют направление рельефного выделения. В нашем примере продемонстрированы два направления. Во втором примере результат умножения делится на 2, поэтому степень рельефности изображения уменьшается. Рис. 12.5. Выделение границ и рельефные фильтры Морфологические фильтры На рис. 12.6 показаны три новых пространственных фильтра: фильтры сжатия и расширения, а также контурный фильтр. Чтобы результат был более наглядным, изображения выводятся в масштабе 2:1. Это так называемые морфологические фильтры. Они отличаются от предыдущих фильтров, основанных на линейной комбинации пикселов. Морфологический фильтр использует матрицу N х N для проверки соседних пикселов. Результат проверки определяет цвет пиксела, находящегося в центре. Фильтр сжатия генерирует черный цвет лишь в том случае, если все пикселы блока окрашены в черный цвет. В противном случае генерируется белый цвет. Таким образом, в результате применения фильтра сжатия белые участки изображения расширяются. Фильтр расширения генерирует белый цвет лишь в том случае, если все пикселы блока окрашены в белый цвет. В противном случае генерируется черный цвет. Таким образом, в результате применения фильтра расширения белые участки изображения сужаются.
694 Глава 12. Графические алгоритмы и растры Windows m m ^н^ннщ^нщщ^нщ Контур m ■ Рис. 12.6. Морфологические фильтры Контурный фильтр сначала выполняет сжатие, а затем вычитает из полученного изображения оригинал. Для равномерно окрашенных областей контурный фильтр генерирует черный цвет (0), поскольку сжатое изображение совпадает с оригиналом. Новые белые пикселы, возникшие в результате сжатия, остаются белыми. В результате возникает белый контур исходного изображения на черном фоне. На рисунке показано, к каким результатам приводит применение всех трех фильтров к монохромному изображению текстового символа. Черный цвет является основным, а белый — фоновым, поэтому при сжатии белые фоновые участки увеличиваются, а основные черные — уменьшаются. Расширение приводит к обратным последствиям. В нашем примере линии буквы «ш» при сжатии становятся тоньше, а при расширении — толще. Контурный фильтр оставляет белый контур буквы. Эти морфологические фильтры создавались для работы с монохромными изображениями. При работе с цветными изображениями, разделенными на несколько каналов в оттенках серого, расширение имитируется через вычисление минимума, а сжатие — через вычисление максимума. Ниже приведена наша реализация фильтра расширения. Функция KErosion:: Kernel находит минимальное значение по девяти пикселам блока 3 х 3 и возвращает его вызывающей стороне. Для цветных изображений также можно было вычислить минимальное значение по восьми пикселам, окружающим центральный пиксел, и вернуть в качестве результата среднее арифметическое центрального пиксела и минимума. В этом варианте эффект расширения несколько снижается. Чтобы создать фильтр сжатия, достаточно вместо минимума вычислить максимум. // Минимум - расширение темных областей class KErosion : public KFilter
Итоги 695 { inline void smaller(BYTE &x. BYTE y) { if ( у < x ) x = у; } BYTE Kernel(BYTE * pPixel. int dx, int dy) { BYTE m = pPixel[-dy-dx]; smaller(m, pPixel[-dy]); smaller(m, pPixel[-dy+dx]); smaller(m, pPixel[ -dx]); smaller(m, pPixel[ +dx]); smaller(m, pPixel[ dy-dx]); smaller(m, pPixel[dy]); smaller(m. pPixel[ dy+dx]); return min(pPixel[0], m): // /2; } }: Обработка изображений — весьма интересная тема. Впрочем, книга все же посвящена графическому программированию, поэтому нас в первую очередь интересует прямой доступ к массивам пикселов DIB и DIB-секций и то, как с его помощью реализовать все эти замечательные эффекты. Для этого мы создали несколько родовых классов и шаблонов, к которым приложения могут добавить собственные компоненты для решения специализированных задач. Итоги Эта глава была посвящена прямому доступу к массивам пикселов DIB и DIB- секций. На основе прямого доступа к пикселам растра строится множество интересных алгоритмов и эффектов. В этой главе было показано, как при помощи прямого доступа к пикселам реализовать общий алгоритм аффинного преобразования растров без использования средств поворота растров, доступных только в системах семейства NT. Как вы убедились, специализированный, высоко оптимизированный алгоритм аффинного преобразования, работающий только с целыми числами, способен обрабатывать миллионы пикселов в секунду. На базе прямого доступа к пикселам реализуются эффектные графические алгоритмы, не поддерживаемые напрямую средствами GDI. В этой главе был построен набор родовых классов и шаблонов для реализации алгоритмов преобразования цветов и пикселов, а также пространственных фильтров. Используя абстрактные классы и шаблоны, разработанные в этой главе, можно создать множество других графических алгоритмов. Приемы, рассмотренные в этой главе, могут использоваться для создания эффекта сглаживания или имитации рельефа. Кроме того, их можно использо-
696 Глава 12. Графические алгоритмы и растры Windows вать на поверхностях DirectDraw, которые фактически представляют собой DIB- секции с аппаратным ускорением. Глава 13 посвящена палитрам, квантованию цветов и полутоновым операциям. В главе 17 рассматривается декодирование и печать графики в формате JPEG. В главе 18 прямой доступ к пикселам используется применительно к поверхностям DirectDraw. Примеры программ К главе 12 прилагается всего одна программа Imaging, иллюстрирующая весь изложенный материал (табл. 12.1). Таблица 12.1. Программа главы 12 Каталог проекта Описание Samples\Chapt_12\Imaging Демонстрация прямого доступа к пикселам, преобразования цветных изображений в оттенки серого, гамма- коррекции, аффинных преобразований растров, преобразований цветов и пикселов и различных пространственных фильтров. Откройте BMP-файл и поэкспериментируйте с командами меню Color и View
Глава 13 Палитры До настоящего момента мы использовали в своих программах множество цветов; мы говорили о цветных перьях и кистях, 16, 24- и 32-разрядных растрах, градиентных заливках, альфа-наложении и обработке изображений. Но стоит запустить эти программы на экране с 256 цветами, и все богатство красок мгновенно пропадает. Многоцветные изображения тускнеют и заменяются уродливыми имитациями. Проблема связана с палитрой — инструментом, который Windows GDI и разработчики видеоадаптеров позаимствовали у художников. Палитра предназначена для отображения в цвета RGB цветовых индексов в кадровых буферах с палитрой. В этой главе вы узнаете, что произойдет, если полностью игнорировать существование палитры; какие минимальные меры нужны для того, чтобы ваша программа с приемлемым качеством работала в режиме с палитрой, и как извлечь максимум пользы из работы с палитрой. В этой главе также рассматривается квантование цветов — алгоритм преобразования изображений High Color и True Color в индексированные цветные изображения с оптимальной цветовой таблицей. Системная палитра Попробуйте переключить Windows в 256-цветный видеорежим, но для начала выведите на экран какое-нибудь красочное изображение. Например, на рабочем столе имеется несколько многоцветных значков; меню Start (Пуск) тоже выглядит довольно ярко, а в диалоговом окне для выбора цвета должно отображаться множество цветов. Теперь попробуйте угадать, сколько цветов вы в действительности видите на экране в 256-цветном режиме. Чтобы получить правильный ответ, сохраните копию экрана и при помощи графического редактора подсчитайте точное количество цветов в сохраненном растре. Ответ — не более 20 цветов.
698 Глава 13. Палитры В 256-цветном режиме весь пользовательский интерфейс операционной системы Windows строится с использованием всего 20 цветов. Если приложение не работает с палитрой, в его распоряжении обычно оказываются те же 20 цветов. Значки и панели инструментов тоже выводятся в 20 цветах. Функция LoadBitmap преобразует любой цветной растр в 256-цветный DDB-растр, но реально используются только 20 цветов. DIB и DIB-секции тоже выводятся в 20 цветах. Все остальные цвета получаются посредством смешения (dithering), образующего комбинации из этих 20 цветов. Но самое грустное заключается в том, что даже 256-цветные растры, загруженные функцией LoadBitmap, на экране выводятся только в 20 цветах. Чтобы лучше понять сущность проблемы и пути ее решения, необходимо разобраться в том, что такое системная палитра, логическая палитра и что происходит при реализации логической палитры. Параметры экрана Из-за падения цен на память 256-цветный видеорежим встречается очень редко. Впрочем, старые программы еще иногда требуют, чтобы вы переключились в 256-цветный режим. Для тестирования программ этой главы необходимо переключиться в 256-цветный режим. Обычно это делается при помощи приложения Display (Экран) панели управления. Чтобы проверить, поддерживает ли устройство аппаратную палитру, программа должна запросить у устройства флаг RASTERCAPS и проверить в нем бит RCJPALETTE. Если этот бит установлен, графическое устройство работает в режиме с поддержкой палитры. Подробную информацию о текущих параметрах видеоадаптера можно получить при помощи функции EnumDisplaySettings. Если приложению потребуется изменить параметры экрана, вызовите функцию Change- DisplaySettings. Ниже приведена функция Switch8bpp из программы Palette этой главы; если текущий видеорежим не поддерживает аппаратную палитру, программа предлагает пользователю переключиться в 256-цветный режим. B00L Switch8bpp(void) { HDC hDC - GetDC(NULL); int hasPalette = (GetDeviceCaps(hDC, RASTERCAPS) & RC_PALETTE); ReleaseDC(NULL. hDC); if ( hasPalette ) // Палитра поддерживается return TRUE; int rslt = MessageBox(NULL, _T("Switch to 256 color mode?"). _T("Palette"), MBJESNOCANCEL); if ( rslt—IDCANCEL ) return FALSE; if ( rslt==IDYES ) // Выбрано переключение в 256-цветный режим { DEVM0DE dm; dm.dmSize = sizeof(dm); // Важно, предотвращает GPF
Системная палитра 699 dm.dmDriverExtra = 0; EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, & dm); // Текущие параметры dm.dmBitsPerPel = 8; // Перейти к кодировке 8 бит/пиксел ChangeDisplaySettings(&dm. 0); // ПЕРЕКЛЮЧИТЬ } return TRUE; } Функция Switch8bpp при помощи GetDeviceCaps проверяет, поддерживает ли текущий первичный экран палитру, и если не поддерживает — выводит запрос на изменение видеорежима. Если пользователь соглашается на изменение параметра, функция EnumDisplaySettings возвращает структуру DEVMODE с текущими параметрами устройства. Присвоив полю dmBitsPerPel структуры DEVMODE значение 8, функция вызывает ChangeDi spl aySetti ngs и передает измененную структуру DEVMODE для переключения в 256-цветный режим. При этом всем окнам верхнего уровня посылается сообщение WMDISPLAYCHANGE. Получение системной палитры В 256-цветном режиме каждый пиксел представлен в кадровом буфере видеоадаптера одним байтом. Один байт позволяет закодировать до 256 разных цветов, одновременно отображаемых на экране. Точный состав цветов определяется палитрой видеоадаптера, которая представляется пользовательским приложениям в виде системной палитры. Системная палитра в 256-цветном режиме представляет собой таблицу из 256 структур PALETTEENTRY. В GDI предусмотрено несколько функций для получения информации и управления системной палитрой. typedef struct { BYTE peRed; BYTE peGreen; BYTE peBlue; BYTE peFlags; } PALETTEENTRY; UINT GetSystemPaletteEntries(HDC hDC. UINT iStartlndex, UINT nEntries. LPPALETTEENTRY lppe); UINT GetSystemPaletteUse(HDC hDC); UINT SetSystemPaletteUse(HDC hDC. UINT uUsage); Структура PALETTEENTRY определяет цвет по его компонентам RGB. Поле peFlags используется при создании логических палитр (см. следующий раздел). Функция GetSystemPaletteEntries возвращает блок элементов текущей системной палитры графического устройства. Первый параметр определяет манипулятор контекста устройства. Следующие два параметра определяют первый и последний копируемый элемент, а последний параметр содержит указатель, по которому записывается массив. Если точное количество элементов в системной палитре неизвестно, его можно получить вызовом GetSystemPaletteEntries (hDC, 0, 0, NULL). Системная палитра является ресурсом уровня графического устройства, который совместно используется всеми созданными для него контекстами. Для графического видеоадаптера системная палитра всегда одна и та же. Приложе-
700 Глава 13. Палитры ния могут модифицировать системную палитру по определенным правилам, поэтому ее содержимое, вообще говоря, не является чем-то постоянным и жестко заданным. После изменения системной палитры операционная система отправляет сообщение WM_PALETTECHANGED всем окнам верхнего уровня, чтобы дать им возможность отреагировать на изменения. При необходимости окна верхнего уровня должны сами отправить сообщения своим дочерним окнам. Чтобы лучше понять динамическую природу системной палитры, мы создадим маленькое временное окно для вывода системной палитры и отслеживания всех изменений. В листинге 13.1 приведен класс KPaletteWnd. Метод Create- PaletteWindow этого класса создает временное окно для вывода всех цветов системной палитры. При выводе используется инициализированный 256-цветный аппаратно-зависимый растр (DDB). Предполагается, что видеоадаптер использует для представления DDB-растра одну цветовую плоскость с кодировкой 8 бит/пиксел. Данные инициализации DDB состоят из однородных цветных блоков 16 х 16 с цветами в интервале от 0 до 255. Поскольку предполагается, что данные соответствуют внутреннему формату DDB, создание и вывод DDB не требуют преобразований цветов. Следовательно, байт DDB со значением 0 будет соответствовать первому элементу системной палитры. Обработчик сообщения WM_PALETTECHANGED просто обновляет изображение в окне. Листинг 13.1. Класс для наглядного представления изменений в системной палитре class KPaletteWnd : public KWindow { HDC m_hDC; TCHAR m_name[MAX_PATH]; PALETTEENTRY m_Entry[256]; int m_nEntry; int mjnGeneration; virtual LRESULT WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch ( uMsg ) { case WM_PAINT: { PAINTSTRUCT ps; HDC hDC = BeginPaint(hWnd, & ps); HDC hMemDC = CreateCompatibleDC(hDC); BYTE data[80][80]; // Данные инициализации // для 8-разрядного DDB for (int i=0; i<80; i++) for (int j=0; j<80; j++) { data[i][j] = (i/5) * 16 + (j/5); .if ( ((i%5)—0) || ((jX5)--0) ) data[i][j] = 255; } HBITMAP hBitmap - CreateBitmap(80, 80. 1. 8, data);
Системная палитра 701 HGDIOBJ hOld = SelectObjectChMemDC. hBitmap); StretchBlt(hDC.10.10.256,256.hMemDC.0,0.80,80.SRCCOPY); SelectObjectChMemDC, hOld); DeleteObject(hBitmap); DeleteObject(hMemDC); EndPaint(hWnd, & ps); } return 0; case WM_PALETTECHANGED; { InvalidateRect(hWnd, NULL, TRUE); return 0; case WMJCDESTROY: ReleaseDC(m_hWnd. m_hDC); return 0; } return DefWindowProc(hWnd, uMsg, wParam. lParam); } public: void CreatePaletteWindow(HINSTANCE hlnst) { if ( ! Switch8bpp() ) // Отмена return; CreateEx(0, _T("SysPalette"). _T("System Palette"), WSJMRLAPPEDWINDOW | WS_CLIPCHILDREN. CWJJSEDEFAULT, CWJJSEDEFAULT. 290. 340, NULL, NULL, hlnst); ShowWindow(nShow); UpdateWindowO; } }: Код на компакт-диске несколько сложнее того, что приведен в листинге 13.1. При обработке сообщения WM_PALETTECHANGED используется вызов функции Get- SystemPaletteEntries, возвращающий все содержимое системной палитры, чтобы при получении сообщения об изменении палитры можно было проанализировать новые цвета палитры и сравнить их с предыдущими цветами палитры. На рис. 13.1 изображены два окна с содержимым системной палитры. Если запустить программу с открытым окном системной палитры, вы убедитесь, что сначала системная палитра состоит из цветов, более или менее равномерно распределенных в цветовом пространстве RGB. Цветовое пространство RGB состоит из трех каналов. Для равномерного распределения цветов каждый канал должен содержать приблизительно 2561/3=6,34 уровня; ближайшее целое значение равно 6. Значения каждого канала RGB лежат в интервале от 0 до 255; таким образом, интервал аппроксимируется 6 уровнями: 0, 51, 102, 153, 204 и 255. Если каждый канал RGB будет состоять из этих 6 уровней, в нашем распоряжении окажется 216 цветов. Эти цвета называются «web-цветами», поскольку они поддерживаются браузерами как Microsoft, так и Netscape. Изображения, состоящие из этих цветов, отображаются в обоих типах браузеров без смешения.
702 Глава 13. Палитры Кроме web-цветов исходная палитра также содержит дополнительные оттенки серого (то есть цвета с одинаковыми значениями красной, зеленой и синей составляющих). . System Palette [0] liil - System Palette [1] Original 217 web colors, 7 grayscale colors ■IIHIi ■iiilM№i:il 208 entries changed by windowfl 80212) Cj 15 web colors, 19 grayscale colors lllllllii1 ■■■■■■■»■■■■■■■ ■iiiiiiiiii^ mi H£ Ш& Ш& ШШ Ш ШШ 888 Ш& <Ш ъ& ШЬ ШЬ &Ё& "'% m§r- j ■■■■ шшштшшштшшштш mm ■iiiiiiiiiiiiin ■ ШШШ1Ш1Ш ■■■■■■ mmmf iiiiiiiiiiiiiiiii шштжшшшшштжтшжшж ШШШШШШШтШШтШШШШШ штшшшштттшшшшшшт tuiiiiiiiiiiiii lIMMIIMIIiili ЯЯЯЯЯ ЯЯЯЯК ЗбНБ ЭТЯ» iffl» Зййййй ¥№fi Щ WW ЯЯЯЯЖ ЙНЙЙ ЯЯЙР* ЯВЙ» $888s «wS* S^jP* шштшы^шшт^шшшт^т шшшшшш шшшш mm № Рис. 13.1. Анализ изменений в системной палитре На рисунке окно с системной палитрой показано в двух состояниях. В первом состоянии выводится системная палитра с 217 web-цветами (один цвет дублируется) и 7 дополнительными оттенками серого. После запуска приложения с красочной заставкой палитра драматически изменяется: 208 цветов системной палитры изменились так, чтобы палитра позволяла как можно лучше отобразить заставку. Палитра часто изменяется и при запуске и закрытии других приложений, даже при переключении между дочерними окнами в приложениях MDI. Статические цвета Похоже, цвета в начале и в конце палитры никогда не изменяются. В этих двух частях палитры хранятся системные статические цвета, зарезервированные операционной системой для пользовательского интерфейса. Операционная система Windows обычно резервирует 20 статических цветов, хотя их количество можно уменьшить. Функция GetSystemPalettellse возвращает флаг, который обозначает количество статических цветов, используемых системой. Если возвращается значение SYSPAL_N0STATIC, система использует два статических цвета — черный и белый; если возвращаемое значение равно SYSPALSTATIC, используются 20 статических цветов. В Windows 2000 появился новый флаг SYSPALN0STATIC256, означающий полное отсутствие зарезервированных статических цветов. Функция SetSystemPalettellse изменяет текущий режим статических цветов при помощи описанных выше флагов. Статические цвета используются такими
Системная палитра 703 функциями API, как GetSysColor и SetSysColor. Следовательно, если приложение хочет уменьшить количество статических цветов до SYSPAL_NOTSTATIC, оно должно сохранить всех текущие системные цвета, изменить количество статических цветов, заменить системные цвета своими, а потом восстановить исходные системные цвета. Количество статических цветов следует изменять только в крайних случаях. Например, если «медицинское» приложение захочет отобразить 256 оттенков серого цвета рентгеновского снимка в 256-цветном режиме, ему придется использовать режим SYSPALNOSTATIC или SYSPAL_N0STATIC256. Расположение 20 статических цветов выглядит довольно любопытно. Шестнадцать цветов взяты из 16-цветной палитры VGA; еще четыре определяются текущей цветовой схемой. В табл. 13.1 перечислены статические цвета для двух цветовых схем: традиционной и схемы Spruce («Ель» в русской версии Windows). Таблица 13.1. Статические цвета Индекс 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0xF6 Значение RGB 0x00, 0x00, 0x00 0x80, 0x00, 0x00 0x00, 0x80, 0x00 0x80, 0x80, 0x00 0x00, 0x00, 0x80 0x80, 0x80, 0x80 0x00, 0x80, 0x80 0хС0, ОхСО, ОхСО OxCO, OxDC, ОхСО 0x59, 0x97, 0x64 ОхАб, OxCA, 0xF0 0хА2, 0хС8, 0хА9 OxFF, OxFb, 0xF0 0xD0, ОхЕЗ, 0xD3 Название Черный Темно-красный Темно-зеленый Темно-желтый Темно-синий Темно-малиновый Темно-голубой Светло-серый Денежный зеленый Небесный Кремовый Применение по умолчанию C0L0R_WIND0WFRAME, C0L0R_MENUTEXT, C0L0R_WIND0WTEXT, COLORJDDKSHADOW, C0L0RJNF0TEXT C0L0R_ACTIVECAPTI0N, COLORJIGHLIGHT, C0L0R_BTNSHAD0W, C0L0R_GRAYTEXT COLORJENU, C0L0R_ACTIVEB0RDER, C0L0RJNACTIVEB0RDER, C0L0R_BTNFACE, COLORJDLIGHT C0L0R_SCR0LLBAR, C0L0R_APPW0RKSPACE, C0L0RJNACTVECAPTI0NTEXT, C0L0R_BTNHIGHLIGHT Продолжение &
704 Глава 13. Палитры Таблица 13.1. Продолжение Индекс Значение RGB Название Применение по умолчанию 0xF7 ОхЗА, ОхбЕ, 0хА5 0x21, 0x3F, 0x21 0xF8 0x80, 0x80, 0x80 0xF9 OxFF, 0x00, 0x00 OxFA 0x00, OxFF, 0x00 OxFB OxFF, OxFF, 0x00 OxFC 0x00, 0x00, OxFF OxFD OxFF, 0x00, OxFF OxFE 0x00, OxFF, OxFF OxFF OxFF, OxFF, OxFF Темно-серый Красный Зеленый Желтый Синий Малиновый Голубой Белый COLOR BACKGROUND C0L0R_WIND0W, C0L0R_CAPTI0NTEXT, COLORJIGHLIGHTTEXT, COLOR INFOBK Из 20 статических цветов 8 темных цветов размещаются в первых 8 позициях системной палитры, а 8 светлых цветов — в последних 8 позициях. Эти позиции используются для «чистых» цветов: красного, зеленого, синего, малинового, желтого, их темных вариантов и четырех оттенков серого. При использовании 20 статических цветов эти 16 всегда находятся на одних и тех же местах. Они размещаются в разных концах палитры для того, чтобы придать смысл базовым растровым операциям между ними. Очень важно, чтобы черный цвет занимал позицию 0, а белый — позицию 255, поскольку от этого зависит работа растровых операций с применением маски. Позицию 1 занимает темно-красный цвет (RGB(0x80, OxFF, 0x00)); если инвертировать индекс, он переходит в OxFE, что соответствует голубому цвету (RGBCOxOO, OxFF, OxFF)). Он не совсем совпадает с дополняющим цветом темно-красного в цветовом пространстве RGB (RGB(0x7F, OxFF, OxFF)), но достаточно близок к нему. При объединении красного и зеленого цвета получается чистый желтый цвет, поскольку 0xF9 | OxFA = OxFB. Четыре цвета в средней части палитры могут изменяться в соответствии с выбранной цветовой схемой. В табл. 13.1 приведены их RGB-цвета для двух цветовых схем. Эти цвета широко используются в пользовательском интерфейсе Windows. В последнем столбце таблицы показано, каким системным цветам они соответствуют по умолчанию. В 256-цветном режиме операционная система Windows всегда пытается использовать статические цвета в качестве системных. Логическая палитра Хотя системная палитра состоит из 256 цветов, если не предпринять особых мер, ваше приложение может работать лишь с 20 статическими цветами. Сие-
Логическая палитра 705 темная палитра является ресурсом уровня системы, а не контекста устройства. В контекстах устройств системной палитре соответствуют логические палитры. Логическая палитра управляет преобразованием цветов, используемых в графических командах GDI, в цветовые индексы кадрового буфера графической поверхности. Логическая палитра является одним из атрибутов контекста устройства. Логические палитры, как и логические кисти, логические перья, логические шрифты и т. д., образуют отдельный класс объектов GDI. Ниже приведены описания структур данных и функций, предназначенных для работы с логическими палитрами. UINT GetPaletteEntries(HPALETE hpal, UINT iStartlndex. UINT nEntries. LPPALETTEENTRY Ippe); HPALETTE CreateHalftonePalette(HDC hDC); HPALETTE SelectPalette(HDC hDC. HPALETTE hpal. BOOL bForceBackground); UINT RealizePalette(HDC hDC); BOOL ResizePaletteCHPALETTE hpal. UINT nEntries); BOOL UnrealizeObject(HGDIOBJ hgdiObj); BOOL ResizePaletteCHPALETTE hpal. UINT nEntries); typedef struct tagLOGPALETTE { WORD pal Version; WORD palNumEntries; PALETTEENTRY palPalEntry[l]; } LOGPALETTE; HPALETTE CreatePaletteCCONST LOGPALETTE * Iplgpl); Палитра по умолчанию Для получения логической палитры, связанной с контекстом устройства, следует воспользоваться функцией GetCurrentObjectChDC, OBJPAL). Новому контексту устройства по умолчанию назначается стандартная логическая палитра, возвращаемая функцией GetStockObject(DEFAULT_PALETTE). Палитра по умолчанию содержит ровно 20 статических цветов, приведенных в табл. 13.1; это ограничивает количество цветов, доступных приложению. Например, если использовать макрос PALETTE INDEX или PALETTERGB для определения цвета в контексте устройства с палитрой по умолчанию, из всех однородных цветов останутся доступными только 20 статических. Приведенная ниже функция WebColors выводит 216 web-цветов. На рис. 13.2 показан результат применения этой функции для палитры по умолчанию. На верхнем рисунке, в котором цвета задаются макросами RGB, большинство элементов получено смешением (кроме черного, красного, зеленого, синего, желтого, голубого, малинового и белого цветов, присутствующих в системной палитре). На нижнем рисунке, в котором использовались макросы PALETTERGB, для каждого цвета из 20 цветов палитры выбирается наиболее подходящий. В обоих случаях результат далек от ожидаемого.
706 Глава 13. Палитры наш! шшшшж тшшшт ПППППП ПППГПГ "' тшшшл ■мни* шшшш? шштш^ ■■■■№ ._ ■■■■«! вниз ■■■■■! ни» ми» мни» ШИШН1$8ё$Ш£$Ш Ш&Ш&Шк ИНИН ' II ' i| I'liMil ■ ниц ши« цма| х««й*й>ив Я! ИЯНШ ЭТИ ;% ^ MM*' ■«■£'»' ■ш К»! III Ш% \Я иь ■ffiffim MMffiffi ■шиш шттш ■■яка ■■яи мш ■ян 1111 Рис. 13.2. Вывод web-цветов с применением палитры по умолчанию void WebColors(HDC hDC. int x. int у. int crtyp) for (int r=0 for (int g*0 for (int b=0 r<6; g<6; b<6; r++) g++) b++) COLORREF cr; switch ( crtyp ) case 0 case 1 case 2 cr = R6B(r*51. g*51. b*51); break cr = PALETTERGB(r*51. g*51. b*51): break cr = PALETTEINDEX(r*36+g*6+b); break HBRUSH hBrush - CreateSolidBrush(cr); RECT rect = { r * 110 + g*16+ x, b*16+ y. r * 110 + g*16+15+x. b*16+15+y}; FillRectChDC. & rect, hBrush): DeleteObject(hBrush); Полутоновая палитра Чтобы увеличить количество цветов, можно воспользоваться полутоновой палитрой. Логическая полутоновая палитра создается функцией CreateHalftonePalette. Странно, что полутоновые палитры не входят в число стандартных объектов GDI — в этом случае они могли бы совместно использоваться всеми процессами в системе. Созданная полутоновая палитра подчиняется тем же правилам, что и другие объекты GDI; после завершения работы ее необходимо удалить. Логическая палитра выбирается в контексте устройства функцией Select- Palette. Обратите внимание: родовая функция SelectObject не подходит, поскольку при выборе палитры передается дополнительный параметр — признак фоновой палитры. Если последний параметр SelectPalette равен TRUE, палитра
Логическая палитра 707 считается фоновой (background); в противном случае, при выполнении ряда других условий, палитра считается основной (foreground). Перед использованием палитру необходимо «реализовать». Реализацией логической палитры называется процесс заполнения системной палитры в соответствии с требованиями приложения и построения таблицы соответствия между индексами логической и системной палитр. При реализации основной палитры нестатические цвета удаляются из системной палитры; цвета, отсутствующие среди статических, включаются в системную палитру вплоть до заполнения всех 256 элементов. Затем строится таблица соответствия цветов логической палитры индексам системной палитры, по которой цвета пикселов будут преобразовываться в индексы цветов кадрового буфера. Фоновой палитре уделяется меньше внимания; из системной палитры ничего не удаляется, а запрашиваемые цвета включаются лишь в неиспользованные позиции системной палитры. Основная палитра предназначена для текущего активного окна, обладающего фокусом ввода, а фоновая палитра обеспечивает сколько-нибудь приемлемый вид остальных окон, находящихся на экране. Код следующего фрагмента создает полутоновую палитру, выбирает ее, реализует и снова выводит диаграмму web-цветов. void TestHalftonePaletteCHDC hDC, HINSTANCE hlnstance) { HPALETTE hPal = CreateHalftonePalette(hDC); break; HPALETTE hOld = SelectPalette(hDC. hPal. FALSE); RealizePalette(hDC); WebColors (hDC. 10, 10. 0): WebColors (hDC. 10. 130. 1); SelectPalette(hDC. hOld. TRUE); DeleteObject(hPal); } Результат показан на рис. 13.3. На верхнем рисунке, использующем макросы RGB, цвета смешиваются из небольшого количества однородных цветов. GDI по- прежнему ограничивается 20 статическими цветами. На нижнем рисунке, использующем макрос PALETTERGB, все 216 цветов выводятся однородными. 1111: НИ ЕВР ИЯК111 тШ яя98 15Ш ЗШ? # 1BS1 1ШИЯ1 «Si ■КЛЯП! шшшшт тшшш ■■■! "МНЯ 1ШВ1 iffl ■Mi wmmi ■ШЯ1 Mia;; ■■■! ШШШшш ИМИ! та шшшь штт ESS ■■■1 ■■■I ■■111 ills ■■■■I ■■■■I Рис. 13.3. Вывод web-цветов с применением полутоновой палитры
708 Глава 13. Палитры Если флаг bForceBackground равен TRUE, а цвета полутоновой палитры отсутствуют в текущей системной палитре, системная палитра не изменяется. GDI всего лишь пытается аппроксимировать запросы ближайшими цветами, найденными в системной палитре. Как и в случае с системной палитрой, GDI позволяет приложениям получить информацию о содержимом существующей логической палитры. Для этого используется функция GetPaletteEntries, которая, как и GetSystemPaletteEntries, возвращает массив структур PALETTEENTRY. Полутоновая палитра состоит из 256 цветов. 216 из них входят в семейство web-цветов (цвета с составляющими RGB, кратными 51, включая 6 оттенков серого). Полутоновая палитра содержит еще 25 оттенков серого, поэтому с ее помощью можно представить 31 уровень серого. Оставшиеся 13 цветов относятся к статическим цветам, используемым цветовыми схемами. Создание специализированной палитры Возможности приложения не ограничиваются использованием палитры по умолчанию и полутоновой палитры. Приложение может создать собственный вариант палитры функцией CreatePalette. Функция CreatePalette возвращает манипулятор логической палитры, которая затем выбирается в контексте устройства и реализуется по аналогии с логической палитрой. Функция CreatePalette получает указатель на структуру LOGPALETTE, содержащую номер версии, количество элементов и массив структур PALETTEENTRY переменного размера. Номер версии палитры не изменился со времен его появления в Windows 3.0 и по-прежнему равен 0x0300. Количество элементов в структуре LOGPALETTE может изменяться в очень широких пределах. Если вы создаете палитру для монохромного DIB-растра, достаточно всего двух цветов, а для DIB с 8-разрядным цветом требуется 256 цветов. В системах семейства Windows NT количество элементов ограничивается 1024. Каждый цвет палитры описывается структурой PALETTEENTRY. Первые три поля структуры обычно описывают интенсивность компонентов RGB, а поле peFlags указывает, как данный элемент должен интерпретироваться при реализации палитры. Четыре допустимых значения поля peFlags перечислены в табл. 13.2. Таблица 13.2. Поле peFlags структуры PALETTEENTRY Значение Описание 0 Стандартная процедура. Искать цвет RGB в системной палитре. Если цвет отсутствует, включить его в палитру PCRESERVED Зарезервировать в системной палитре одну позицию, которая может использоваться для анимации. Не сопоставлять другие цвета с зарезервированной позицией PXEXPLICIT Не изменять системную палитру. Первые два байта структуры PALETTEENTRY образуют индекс в системной палитре PCN0C0LLAPSE Искать соответствие в системной палитре лишь при отсутствии свободных элементов; в противном случае использовать новый элемент
Логическая палитра 709 Как говорилось выше, системная палитра содержит 20 статических цветов, которые не могут заменяться приложением. Следовательно, если приложение захочет реализовать логическую палитру из 256 элементов, вполне возможно, что некоторые цвета не будут включены в палитру. GDI обрабатывает запрос в порядке следования элементов в структуре LOGPALETTE. Важные цвета следует размещать в первых позициях структуры LOGPALETTE. В следующем фрагменте создается 256-цветная палитра оттенков серого цвета без каких-либо специальных требований. Если выбрать и реализовать такую палитру, когда система исцользует 20 статических цветов, 16 цветов в конце таблицы не удастся реализовать однородными цветами. Если, например, «медицинское» приложение захочет вывести рентгеновский снимок в 256 оттенках серого, оно должно уменьшить количество статических цветов до двух (черный и белый) вызовом SetSystemPalettellseChDC, SYSPALNOSTATIC). После этого весь пользовательский интерфейс Windows будет выводиться в оттенках серого. Чтобы содержимое экрана нормально воспринималось, приложение должно позаботиться о правильной настройке системных цветов. HPALETTE CreateGraysea 1еРа1ette(voi d) { LOGPALETTE * pLogPal = (LOGPALETTE *) new BYTE[sizeof(LOGPALETTE) + 255 * sizeof(PALETTEENTRY)]; pLogPal->palVersion = 0x0300; pLogPal->palNumEntries = 256; for (int i=0; i<256; i++) { PALETTEENTRY entry - { i. i. i. 0 }: pLogPal->palPalEntry[i] = entry; HPALETTE hPal = CreatePalette(pLogPal); delete [] (BYTE *) pLogPal; return hPal; } Логическая палитра с флагом PCEXPLICIT — случай довольно интересный. Она предназначена не для изменения системной палитры, а для того, чтобы цвета системной палитры могли использоваться в качестве индексов логической палитры. При выборе и реализации логической палитры с флагом PCEXPLICIT цвета, определяемые макросом PALETTE INDEX, ассоциируются с индексами системной палитры, заданными в структуре LOGPALETTE; даже макрос PALETTERGB работает аналогично PALETTEINDEX. После создания палитры можно увеличить или уменьшить количество цветов в ней при помощи функции ResizePalette. При уменьшении размера палитры удаляемые элементы использоваться не могут, но остальные элементы остаются без изменений. При увеличении размера палитры новые элементы заполняются черным цветом. Для инициализации новых элементов применяется функция SetPaletteEntries.
710 Глава 13. Палитры Сообщения палитры Когда окно реализует основную логическую палитру, из системной палитры удаляются нестатические цвета, а на их место записываются новые цвета из логической палитры. Если на экране остается окно приложения, использовавшего нестатические цвета старой системной палитры, изображение в нем сильно искажается. Например, красный цвет может превратиться в зеленый, а зеленый становится желтым. Чтобы системная палитра могла нормально использоваться сразу несколькими окнами, Windows рассылает окнам верхнего уровня сообщения, информирующие о важных изменениях в палитре. WM_QUERYNEWPALETTE Пока окно находится в неактивном состоянии, другие окна могут изменить содержимое системной палитры, что приводит к искажению изображения. Если окно готово к получению фокуса клавиатуры, Windows отправляет ему сообщение WMQUERYNEWPALETTE, чтобы окно могло восстановить свой нормальный вид. Если окно использует нестандартную палитру, оно должно реализовать ее как основную и перерисовать все окно, чтобы восстановить его в оптимальном виде. Палитра, задействованная приложением, должна быть создана заранее и храниться в переменной класса окна или в глобальной переменной. Следующая функция показывает, как обрабатывается сообщение WM_QUERYNEWPALETTE. LRESULT KWindow::OnQueryNewPalette(void) { if ( mJiPa1ette-»NULL ) return FALSE; HDC hDC = GetDC(mJiWnd); HPALETTE h01d= SelectPalette(hDC, mJiPalette. FALSE); BOOL changed - RealizePalette(hDC) !- 0; SelectPalette(hDC, hOld, FALSE): ReleaseDC(m_hWnd. hDC); if ( changed ) { InvalidateRect(m_hWnd. NULL. TRUE); // Перерисовать } return changed; } В наш класс окна верхнего уровня добавляется новая переменная mJiPalette, равная NULL, если только производное окно не захочет использовать палитру. При работе в режимах High Color и True Color, а также в том случае, если вы ограничиваетесь статическими цветами, переменная m_hPa1 ette остается равной NULL. Получив сообщение WMQUERYNEWPALETTE, функция окна вызывает Kwindow: :0nQuery- NewPalette или переопределенную функцию. Метод OnQueryNewPalette создает новый манипулятор контекста устройства, выбирает палитру в качестве основной и реализует ее. Если реализация палитры прошла успешно (это означает,
Сообщения палитры 711 что устройство поддерживает палитру), клиентская область окна объявляется недействительной, что обеспечивает ее перерисовку правильными цветами. Функция возвращает TRUE, если палитра была реализована, и FALSE в противном случае. WM_PALETTEISCHANGING Непосредственно перед тем, как приложение реализует свою логическую палитру, Windows рассылает окнам верхнего уровня сообщение WMPALETTE ISCHANGING, сообщая тем самым о предстоящих изменениях в системной палитре. Впрочем, это вовсе не означает, что реализация палитры откладывается в ожидании подтверждения. Когда активное окно реализует свою палитру, из-за изменений в системной палитре окна на заднем плане могут сильно исказиться. Предполагается, что сообщение WMPALETTE ISCHANGING позволяет окнам заднего плана подготовиться к изменениям в системной палитре. Например, приложение может просто стереть свое окно одним из статических цветов, чтобы изображение не менялось при модификации палитры, а затем перерисовать его снова с применением фоновой палитры. В одной из статей MSDN сказано, что сообщение WM_P ALETEI SCHANG I NG является пережитком устаревшей архитектуры, и его следует просто игнорировать. Эксперименты показали, что в Windows 2000 это сообщение не рассылается. Даже в профессиональных пакетах переключение палитры сопровождается кратковременным искажением цветов. WM_PALETTECHANGED Изменение системной палитры может сопровождаться полным искажением цветов во всех окнах, кроме активного, поэтому всем перекрывающимся (overlapped) и всплывающим (popup) окнам в системе рассылается сообщение WM_PALETTECHANGED. Окна должны отреагировать на это сообщение и попытаться по мере возможности восстановить свое изображение. Параметр wParam сообщения WMPALETTECHANGED содержит манипулятор окна, изменившего системную палитру. Окно, обрабатывающее это сообщение, должно проверить этот манипулятор и убедиться в том, что палитра была изменена не им самим, а каким-то другим окном, поскольку в противном случае ничего делать не нужно. Существует два способа восстановить содержимое окна. Первый, более быстрый способ — реализовать свою логическую палитру как фоновую и вызвать функцию UpdateColors GDI, чтобы улучшить изображение на уровне пикселов. BOOL UpdateColors(hDC); Функция UpdateColors перебирает все пикселы поверхности устройства и отображает их цветовые индексы исходной системной палитры на наиболее подходящие индексы новой системной палитры. Вероятно, во внутренней реализации UpdateColors строит таблицу отображения старой системной палитры на новую, а затем перебирает пикселы и осуществляет замену по таблице.
712 Глава 13. Палитры Поскольку UpdateColors работает с кадровым буфером устройства, содержащим приближенное представление рисунка, многократное применение UpdateColors приведет к постепенному ухудшению изображения. Например, если исходный рисунок отображался в цвете, то после того, как приложение переключается на палитру оттенков серого, UpdateColors отображает все пикселы в оттенках серого. Но когда другое окно реализует полутоновую палитру, функция UpdateColors не может нормально восстановить цветное изображение по оттенкам серого. Второй способ обработки сообщения WMPALETTECHANGED заключается в перерисовке окна с реализацией фоновой палитры. Как было сказано выше, фоновая палитра не удаляет из системной палитры ни одного элемента, а лишь пытается использовать свободные элементы и подогнать свои логические цвета под существующий набор. Если новая системная палитра хорошо сбалансирована, можно добиться вполне приличного качества. Ниже приведен пример обработчика сообщения WM_PALETTECHANGED. Мы проверяем, не были ли изменения в палитре внесены текущим окном, для чего сравниваем манипулятор окна с wParam. Если манипуляторы не совпадают и окно использует палитру, эта палитра выбирается и реализуется. Программа подсчитывает, сколько раз была вызвана функция UpdateColors. При небольшом значении счетчика вызывается функция UpdateColors, обеспечивающая ускоренное обновление; в противн&м случае окно перерисовывается заново, чтобы улучшить качество изображения. LRESULT KWindow::OnPaletteChanged(HWND hWnd. WPARAM wParam) { if ( ( hWnd != (HWND) wParam ) && mJiPalette ) { HDC hDC = GetDC(hWnd); HPALETTE hOld = SelectPaletteChDC. mJiPalette, FALSE); if ( RealizePalette(hDC) ) if ( m_nUpdateCount >=2 ) { InvalidateRect(hWnd. NULL. TRUE); m_nUpdateCount = 0; } else { UpdateColors(hDC); m_nUpdateCount ++; } SelectPalette(hDC, hOld, FALSE); ReleaseDCChWnd, hDC); } return 0; } Тестовая программа Давайте объединим все сказанное в небольшом классе окна, предназначенного для вывода DIB с помощью полутоновой палитры. Класс KDIBWindow показывает,
Сообщения палитры 713 как создать логическую палитру, реализовать ее и использовать для отображения растра и как организовать обработку сообщений палитры с помощью описанных выше функций. В листинге 13.2 приведен полный код класса окна DIB, производного от KWindow. Метод CreateDIBWindow, получающий среди прочих параметров неупакованный DIB-растр, создает временное окно. Параметр option позволяет сравнить работу программы с палитрой и без нее, при обработке сообщений палитры и при блиттинге с масштабированием. Обработчик сообщения WMCREATE создает полутоновую палитру, если на это указывает значение параметра option. Обработчик WMPAINT использует палитру для вывода растра. Обработчик WM_PALETTECHANGED восстанавливает поврежденное изображение, также руководствуясь значением параметра option. Обработчик WM_QUERYNEWPALETTE реализует полутоновую палитру. Созданная палитра уничтожается в обработчике сообщения WM_NCDESTROY. Листинг 13.2. Вывод растров с учетом палитры typedef enum { pal_no = 0x00, // Без палитры paljialftone = 0x01. // Использовать полутоновую палитру pal_bitmap = 0x02, // Использовать палитру DIB/DIB-секции pal_react = 0x04, // Реагировать на сообщение WM_PALETTECHANGED pal_stretchHT= 0x08 // Использовать режим STRETCH_HALFTONE HPALETTE CreateDIBSectionPalette(HDC hDC. HBITMAP hDIBSec); class KDIBWindow : public KWindow { const BITMAPINFO * m_pBMI; const BYTE * m_pBits; int mjnOption; virtual LRESULT WndProcCHWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam) { switch ( uMsg ) { case WM_CREATE: m_hWnd = hWnd; { HDC hDC = GetDC(m_hWnd); if ( (mjiOption & 3)==pal_bitmap ) mJiPalette - CreateDIBPalette(m_pBMI); else if ( (mjnOption & 3)==pal_halftone ) mJiPalette = CreateHalftonePalette(hDC); else mJiPalette = NULL; ReleaseDC(m_hWnd. hDC); } return 0; Продолжение^
714 Глава 13. Палитры Листинг 13.2. Продолжение case WM_PAINT: { PAINTSTRUCT ps; HDC hDC = BeginPaintChWnd. & ps); HPALETTE hOld - SelectPalette(hDC, mJiPalette. FALSE); RealizePalette(hDC); if ( mjiOption & pal_stretchHT ) { SetStretchBltMode(hDC. STRETCH_HALFTONE); } else SetStretchBltModeChDC, STRETCH_DELETESCANS); StretchDIBits(hDC. 10. 10. m_pBMI->bmi Header.biWi dth. m_pBMI->bmiHeader.bi Hei ght. 0. 0. m_pBMI->bmiHeader.biWidth. m_pBMI->bmi Header.bi Hei ght, mj)B1ts. m_pBMI. DIB_RGB_COLORS. SRCCOPY); EndPaintChWnd. & ps); } return 0; case WM_PALETTECHANGED: if ( mjiOption & pal__react ) return OnPaletteChanged(hWnd. wParam); break; case WM_QUERYNEWPALETTE: return OnQueryNewPalette(); case WMJCDESTROY: DeleteObject(m_hPalette); mJiPalette - NULL; return 0; } return DefWindowProc(hWnd. uMsg. wParam. IParam); } public: void CreateDIBWindow(HINSTANCE hinst. const BITMAPINFO * pBMI. const BYTE * pBits. int option) { if ( pBMI==NULL ) return; mjiOption - option; m_pBMI - pBMI; m_pBits = pBits:
Сообщения палитры 715 TCHAR title[32]: wsprintf(title. _T("DIB Window Ud)"). mjiOption): CreateEx(0. _T("DIBWindow"), title, WSJ3VERLAPPEDWIND0W | WS_CLIPCHILDREN. CW_USEDEFAULT. CWJJSEDEFAULT. m_pBMI->bmiHeader.biWidth + 28, m_pBMI->bmiHeader.biHeight + 48. NULL. NULL, hlnst); ShowWindow(SW_NORMAL); UpdateWindowO; } }: На рис. 13.4 показаны два варианта изображения. В левом окне изображение получено без применения полутоновой палитры (option - paljw). Цветные пикселы изображения заменяются 20 статическими цветами, поэтому изображение получается серым и скучным. В правом окне была использована полутоновая палитра (option = pal _half tone); рисунок стал очень красочным, с плавными переходами цветов. Хотя на страницах книги цвета не различаются, о качестве изображения можно судить даже по оттенкам серого. Рис. 13.4. Вывод DIB с полутоновой палитрой и без нее Рисунок 13.5 иллюстрирует последствия обработки сообщений палитры. Левое окно (option = pal_halftone) игнорирует сообщение WM_PALETTECHANGED, упуская шанс восстановить изображение при модификации системной палитры. Правое окно (option = palhalftone| palreact) обновляет цвета или перерисовывает изображение с фоновой палитрой. Вероятно, комментарии излишни. На экране очевидны некоторые различия, обусловленные различиями фоновой и основной палитр, хотя на бумаге рисунки снова выглядят почти одинаково. Если у окна верхнего уровня имеются дочерние окна (особенно в приложениях MDI), вы должны правильно организовать пересылку сообщений палитры, поскольку без этого сообщения не дойдут до дочерних окон.
716 Глава 13. Палитры Рис. 13.5. Вывод DIB без обработки WM_PALETTECHANGED Сообщение WMQUERYNEWPALETTE посылается окну верхнего уровня лишь при получении им фокуса. Главное окно MDI должно пересылать это сообщение активному дочернему окну MDI. Если дочерние окна MDI используют разные палитры, любое дочернее окно при получении фокуса должно иметь возможность реализовать свою палитру в качестве основной. Сообщение WM_PALETTECHANGED тоже рассылается только окнам верхнего уровня. Главное окно MDI должно переслать его всем своим дочерним окнам, чтобы все они имели возможность отреагировать на изменения системной палитры. Палитра и растры По сравнению с векторной графикой, использующей перья и кисти, растровая графика порождает больше проблем в видеорежимах с палитрой. Например, обычная загрузка растра функцией LoadBitmap уже не подходит, поскольку изображение, которое может содержать тысячи цветов, будет аппроксимироваться несколькими статическими цветами. Если растр содержит цветовую таблицу, для получения оптимального результата ее следует преобразовать в логическую палитру Windows и правильно использовать. При выводе растров High Color и True Color в 256-цветном режиме приемлемый результат достигается только построением оптимальной палитры и полутоновой обработкой изображения в соответствии с содержимым палитры. В этом разделе рассматриваются стандартные проблемы, возникающие при выводе растров в видеорежимах с палитрой.
Палитра и растры 717 Аппаратно-зависимые растры и палитры Самый простой способ преобразования растра формата BMP в DDB-растр основан на применении функции LoadBitmap или Loadlmage. Функция LoadBitmap преобразует BMP-файл, подключенный к EXE/DLL в виде ресурса, в DDB. Функция Loadlmage преобразует в DDB либо растровый ресурс, либо внешний ВМР-файл, хотя Loadlmage также позволяет загрузить изображение в DIB-секцию. Среди параметров этих функций не передается ни контекст устройства, ни логическая палитра. При построении DDB функции LoadBitmap и Loadlmage используют только 20 статических цветов. Все цветные пикселы растра заменяются ближайшим подходящим цветом из этого маленького набора. Пример показан на рис. 13.4 слева. Для построения многоцветного DDB-растра необходима логическая палитра, управляющая преобразованием цветов из DIB в DDB. Палитра может быть полутоновой, специализированной или сгенерированной на базе системной палитры. В листинге 13.3 приведена новая функция загрузки растра с поддержкой палитры. Листинг 13.3. Загрузка DDB-растра с поддержкой палитры static BYTE * GetDIBPixelArrayCBITMAPINFO * pDIB) { return (BYTE *) & pDIB->bm1Colors[GetDIBColorCount(pDIB->bmiHeader)]: } // Создание логической палитры, содержащей все цвета // текущей системной палитры HPALETTE CreateSystemPalette(void) { L0GPALETTE * pLogPal = (LOGPALETTE *) new char[sizeof(LOGPALETTE) + sizeof(PALETTEENTRY) * 255]; pLogPal->palVersion - 0x300; pl_ogPal->palNumEntries «• 256; HDC hDC - GetDC(NULL); GetSystemPaletteEntries(hDC, 0. 256. pLogPal->pa1Pal Entry); ReleaseDCCNULL, hDC); HPALETTE hPal - CreatePalette(pLogPal); delete [] (char *) pLogPal; return hPal; } // Загрузка DIB из ресурса или из файла BITMAPINFO * LoadDIB(HINSTANCE hlnst. LPCTSTR pBitmapName. bool & bNeedFree) { HRSRC hRes - FindResource(hInst, pBitmapName. RT_BITMAP); BITMAPINFO * pDIB; Продолжение #
718 Глава 13. Палитры Листинг 13.3. Продолжение if ( hRes ) { HGLOBAL hGlobal = LoadResource(hInst, hRes); pDIB - (BITMAPINFO *) LockResource(hGlobal); bNeedFree - false; } else { HANDLE handle - CreateFile(pBitmapName. GENERIC_READ. FILE_SHARE_READ. NULL. OPENJXISTING. FILE_ATTRIBUTE_NORMAL. NULL); if ( handle — INVALIDJANDLEJALUE ) return NULL: BITMAPFILEHEADER bmFH; DWORD dwRead * 0; ReadFileChandle. & bmFH. sizeof(bmFH). & dwRead. NULL); if ( (bmFH.bfType — 0x4D42) && (bmFH.bfSize<= GetFileSize(handle. NULL)) ) { pDIB = (BITMAPINFO *) new BYTE[bmFH.bfSize]; if ( pDIB ) { bNeedFree = true; ReadFileChandle. pDIB. bmFH.bfSize. & dwRead. NULL); } } CloseHandle(handle); } return pDIB; } // Загрузка ресурса или файла под управлением палитры HBITMAP PaletteLoadBitmap(HINSTANCE hlnst. LPCTSTR pBitmapName. HPALETTE hPalette) { bool bDIBNeedFree; BITMAPINFO * pDIB - LoadDIB(hInst. pBitmapName. bDIBNeedFree); int width - pDIB->bmiHeader.biWidth; int height - pDIB->bmiHeader.biHeight; HDC hMemDC - CreateCompatibleDC(NULL): HBITMAP hBmp - CreateBitmap(width. height. GetDeviceCaps(hMemDC. PLANES). GetDeviceCaps(hMemDC. BITSPIXEL). NULL); HGDIOBJ hOldBmp - SelectObject(hMemDC. hBmp);
Палитра и растры 719 HPALETTE hOld = SelectPaletteChMemDC, hPalette. FALSE); RealizePalette(hMemDC); SetStretchBltModeChMemDC. HALFTONE); StretchDIBitsChMemDC. 0. 0, width, height, 0. 0. width, height. GetDIBPixelArray(pDIB), pDIB. DIB_RGB_C0L0RS. SRCCOPY); SelectPaletteChMemDC. hOld, FALSE): SelectObject(hMemDC. hOldBmp); DeleteObject(hMemDC); if ( bDIBNeedFree ) delete [] (BYTE *) pDIB; return hBmp; } По сравнению с LoadBitmap функция PaletteLoadBitmap получает дополнительный параметр — манипулятор логической палитры. Логическая палитра выбирается в совместимом контексте устройства перед преобразованием загруженного DIB-растра в DDB, поэтому сгенерированный DDB-растр может использовать все цвета логической палитры. Функция LoadDIB загружает растр из ресурса или внешнего файла в виде упакованного DIB-растра. Вспомогательная функция CreateSystemPalette создает логическую палитру, содержащую все цвета текущей системной палитры. Манипулятор, переданный PaletteLoadBitmap, должен соответствовать логической палитре, используемой при выводе растра. Например, если приложение является игровой программой, работающей с полутоновой палитрой, то растры в игре должны загружаться с полутоновой палитрой. Главное окно программы должно обрабатывать сообщения палитры, чтобы обеспечить выбор полутоновой палитры при выводе растров. DDB-растры широко применяются при выводе графики на панелях инструментов, кнопках, элементах управления, в меню и т. д. Обычно вывод происходит под управлением операционной системы, хотя также возможен вариант с прорисовкой владельцем. Операционная система применяет при выводе DDB палитру по умолчанию, поэтому если приложение хочет использовать более 20 статических цветов, цвета растра должны соответствовать содержимому текущей системной палитры. Другими словами, при каждом изменении системной палитры эти растры приходится восстанавливать заново. Ниже приведена функция, позволяющая вывести панель инструментов более чем с 20 цветами. Она реализуется в классе KToolbarB, производном от класса KToolbar. Функция KToolbar: :SetBitmap должна вызываться при каждом изменении системной палитры. Она загружает растр с применением текущей системной палитры и использует сообщение TB_REPLACEBITMAP для замены текущего растра панели инструментов. Теперь вы сможете задействовать больше цветов на панелях инструментов в 256-цветном режиме. B00L KToolbarB::SetBitmap(HINSTANCE hlnstance. int resourcelD) { HPALETTE hPal - CreateSystemPaletteO:
720 Глава 13. Палитры HBITMAP hBmp - PaletteLoadBitmapChlnstance. MAKEINTRESOURCE(resourcelD). hPal); DeleteObject(hPal): if ( hBmp ) { TBREPLACEBITMAP rp; rp.hlnstOld = m_ResInstance; rp.nlDOld = m_ResId: rp.hlnstNew - NULL; rp.nlDNew - (UINT) hBmp; rp.nButtons = 40; SendMessage(m_hWnd, TB_REPLACEBITMAP, 0, (LPARAM) & rp); if ( m_ResInstance==NULL ) DeleteObject( (HBITMAP) m_ResId): m_ResInstance = NULL; m_ResId - (UINT) hBmp; return TRUE; } else return FALSE; } Аппаратно-независимые растры и палитры В отличие от аппаратно-зависимых растров, каждый аппаратно-независимый растр (DIB) содержит полную цветовую информацию, что позволяет вывести его на любом устройства. В режимах High Color и True Color каждый пиксел содержит полные данные цвета; в других режимах индексы отображаются на значения RGB по цветовой таблице. Главная проблема при выводе DIB в системах с палитрой заключается в выборе палитры, используемой при выводе растра. Вывод DIB с палитрой по умолчанию позволяет использовать только 20 статических цветов. Полутоновая палитра хорошо подходит для вывода деловой графики с насыщенными и равномерно распределенными цветами. Для растров с неравномерным распределением цветов в пространстве RGB специализированная палитра подходит лучше, чем палитры общего назначения (такие, как полутоновая палитра). Если количество цветов в растре не превышает 256, цветовая таблица растра легко преобразуется в логическую палитру. Для растров High Color или True Color Windows позволяет задать цветовую таблицу для вывода на устройствах с палитрой (хотя вряд ли удастся вспомнить хоть одно приложение, которое бы пользовалось этой возможностью). В листинге 13.4 приведена функция для построения логической палитры на базе цветовой таблицы DIB.
Палитра и растры 721 Листинг 13.4. Преобразование цветов DIB в логическую палитру HPALETTE CreateDIBPalette(const BITMAPINFO * pDIB) { BYTE * pRGB; int nSize; int nColor; if ( pDIB->bmiHeader.biSize==sizeof(BITMAPCOREHEADER) ) // OS/2 { pRGB = (const BYTE *) pDIB + sizeof(BITMAPCOREHEADER); nSize = sizeof(RGBTRIPLE); nColor - 1 « ((BITMAPCOREHEADER *) pDIB)->bcBitCount; } else { nColor = 0; if ( pDIB->bmiHeader.biBitCount<=8 ) nColor = 1 « pDIB->bmiHeader.biBitCount; if ( pDIB->bmiHeader.biClrUsed ) nColor - pDIB->bmiHeader.biCIrUsed; if ( pDIB->bmiHeader.biClrImportant ) nColor - pDIB->bmiHeader.biCIrImportant; pRGB - (BYTE *) & pDIB->bmiColors; nSize - sizeof(RGBQUAD); if ( pDIB->bmiHeader.biCompression-=BI_BITFIELDS ) pRGB +- 3 * sizeof(RGBQUAD); } if ( nColor>256 ) nColor - 256; if ( nColor—0 ) return NULL; LOGPALETTE * pLogPal - (LOGPALETTE *) new BYTE[sizeof(LOGPALETTE) + sizeof(PALETTEENTRY) * (nColor-1)]: HPALETTE hPal; if ( pLogPal ) { pLogPal->palVersion - 0x0300; pLogPal->palNumEntries - nColor; for (int i-0: i<nColor; i++) { pLogPal->palPalEntry[i].peBlue - pRGB[0]: pLogPal->palPalEntry[i].peGreen - pRGB[l]; pLogPal->palPa!Entry[i].peRed - pRGB[2]; pLogPal ->pal Pal Entry [1 ]. peFl ags - 0; Продолжение^
722 Глава 13. Палитры Листинг 13.3. Продолжение pRGB +- nSize; } hPal = OeatePalette(pLogPal); } delete [] (BYTE *) pLogPal; return hPal; Рис. 13.6. Вывод DIB с полутоновой палитрой, с полутоновой палитрой в режиме HALFTONE и со специализированной палитрой
Палитра и растры 723 Функция ищет в DIB цветовую таблицу и определяет количество цветов, необходимых для вывода растра. Учитывая, что в нормальных условиях можно реализовать только 236 цветов, отличных от статических, в цветовой таблице DIB не рекомендуется использовать более 236 нестатических цветов. Поле bid rImportant предусмотрено специально для сокращения количества необходимых цветов. Цвета в таблице желательно отсортировать по частоте использования. Если некоторые из них не войдут в палитру, исключение должно начинаться с наименее используемых цветов. Функция CreateDIBPalette использует цветовую таблицу DIB только для построения логической палитры. Вопрос построения оптимальной палитры для изображений High Color и True Color рассматривается в следующем разделе, посвященном более общей теме — сокращению количества цветов в растре. А пока в том случае, если DIB не содержит цветовой таблицы, наша программа будет использовать полутоновую палитру. Эффект от заполнения палитры данными из цветовой таблицы DIB может быть очень заметным. Взгляните на рис. 13.6; первое изображение выведено с полутоновой палитрой без режима полутонового масштабирования (см. главу 10). Второе изображение выводилось с полутоновой палитрой и полутоновым масштабированием; качество рисунка заметно улучшилось. Последний рисунок был получен с применением специализированной палитры, построенной на основе цветовой таблицы, без полутонового масштабирования. Возможно, вас удивит то, что при использовании палитры, построенной на базе цветовой таблицы, режим полутонового масштабирования совершенно не улучшает качества изображения. Результат получается практически таким же, как при использовании полутоновой палитры с включением полутонового масштабирования. Индекс палитры в цветовой таблице DIB При выводе DIB таким функциям, как StretchDIBits, обычно передается флаг DIB_RGB_C0L0RS. Этот флаг сообщает GDI, что цветовая таблица DIB действительно содержит значения RGB. GDI ассоциирует значения RGB из цветовой таблицы с цветами логической палитры, а затем преобразует индексы логической палитры в индексы системной палитры, записываемые в кадровый буфер. Поиск подходящих цветов в палитре проходит довольно медленно. В GDI предусмотрены две функции, позволяющие приложениям самостоятельно подбирать цвета: UINT GetNearestPalettelndexCHPALETTE hPal. C0L0RREF crColor); C0L0RREF GetNearestColor(HDC hDC, C0L0RREF crColor); Функция GetNearestPalettelndex просматривает все цвета логической палитры в поисках ближайшего совпадения для заданного эталона. Степень близости определяется расстоянием между двумя цветами в цветовом пространстве RGB. Для двух цветов RGB(rl,gl,bl) и RGB(r2,g2,b2) расстояние вычисляется по формуле
724 Глава 13. Палитры С целью нахождения ближайшего совпадения GDI может просто использовать квадрат расстояния, чтобы обойтись без медленного вычисления квадратного корня. Функция GetNearestColor находит для заданного эталона ближайший цвет из системной палитры и возвращает его. Конечно, GDI не подбирает цвета для каждого пиксела. При выводе DIB с флагом DIBRGBCOLORS GDI подбирает замену для всех цветов цветовой таблицы и использует результат для вывода всех пикселов растра. Если текущая логическая палитра построена на базе цветовой таблицы растра, GDI позволяет исключить первый этап поиска. Чтобы воспользоваться этой оптимизацией, приложение должно заменить значения RGB в цветовой таблице DIB индексами логической палитры, а затем при использовании DIB передать флаг DIBPALC0L0RS вместо DIBRGBCOLORS. С флагом DIB_PAL_C0L0RS цветовая таблица DIB интерпретируется как массив индексов логической палитры. Следующая функция создает структуру BITMAPINFO с цветовой таблицей, содержащей индексы палитры. BITMAPINFO * IndexColorTableCBITMAPINFO * pDIB. HPALETTE hPal) { int nSize; int nColor; const BYTE * pRGB - GetColorTable(pDIB, nSize, nColor); if ( pDIB->bmiHeader.biBitCount>8 )// Без изменений return pDIB; // Создать новую структуру BITMAPINFO для модификации BITMAPINFO * pNew - (BITMAPINFO *) new BYTE[sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD)*nColor]; pNew->bmiHeader = pDIB->bmiHeader; WORD * plndex - (WORD *) pNew->bmiColors; for (int i=0; i<nColor; i++. pRGB+=nSize) if ( hPal ) plndex[i] - GetNearestPalettelndexChPal. RGB(pRGB[2]. pRGB[l], pRGB[0])): else plndex[i] - i; return pNew; } Функция получает указатель на BITMAPINFO и логическую палитру. Она создает новую структуру BITMAPINFO, копирует данные формата и размеров, после чего строит цветовую таблицу с индексами палитры. Если манипулятор логической палитры не задан, предполагается, что растр будет выводиться с логической палитрой, созданной на базе цветовой таблицы, поэтому мы просто отображаем элементы цветовой таблицы растра в соответствующие позиции новой таблицы. Если логическая палитра задана, в ней ищутся элементы, ближайшие к значени-
Палитра и растры 725 ям RGB исходной цветовой таблицы. Функция оставляет исходную цветовую таблицу без изменений, создавая в памяти новую структуру BITMAPINFO; она может использоваться для обработки DIB-растров, загруженных из ресурсных файлов и доступных только для чтения. В этом случае вызывающая сторона должна проверить, успешно ли завершилось создание новой структуры BITMAPINFO, и освободить структуру после завершения работы с ней. DIB-секции и палитра При создании DIB-секции функциями CreateDIBSection или Loadlmage возвращается манипулятор объекта DIB-секции. Если для DIB нам всегда известен указатель на структуру BITMAPINFO, по которому можно найти цветовую таблицу, процесс поиска цветовой таблицы DIB-секции по ее манипулятору не столь очевиден. Получить доступ к цветовой таблице можно лишь одним способом — выбрать DIB-секцию в совместимом контексте устройства и воспользоваться следующими двумя функциями: UINT GetDIBColorTable(HDC hDC. UINT uStartlndex. UINT cEntries. RGBQUAD * pColors); UINT SetDIBColorTable(HDC hDC, UINT uStartlndex. UINT cEntries. RGBQUAD * pColors); Функция GetDIBColorTable копирует цветовую таблицу DIB-секции в заданный массив RGBQUAD. Функция SetDIBColorTable решает противоположную задачу — она загружает цветовую таблицу из пользовательского массива RGBQUAD. Трудно понять, почему вместо манипуляторов контекстов устройств этим двум функциям не передаются манипуляторы DIB-секций. Следующий фрагмент показывает, как построить логическую палитру после получения цветовой таблицы. HPALETTE CreateDIBSectionPaletteCHDC hDC. HBITMAP hDIBSec) { HDC hMemDC - CreateCompatibleDC(hDC); HGDIOBJ hOld = SelectObject(hMemDC. hDIBSec); RGBQUAD Col or[256]: int nEntries - GetDIBColorTable(hMemDC. 0. 256. Color); HPALETTE hPal - LUTCreatePaletteUBYTE *) Color, sizeof(RGBQUAD). nEntries); SelectObjectChMemDC. hOld); DeleteObjectChMemDC); return hPal; } Если для создания DIB использовалась функция CreateDIBSection, приложение не располагает действительной структурой BITMAPINFO, которая могла бы быть задействована для построения логической палитры.
726 Глава 13. Палитры Квантование цветов Информационные заголовки растров в режимах High Color и True Color обычно не содержат цветовых таблиц. До настоящего момента мы использовали для их вывода полутоновую палитру, которая редко обеспечивает оптимальное качество изображения. Процесс построения оптимальной палитры по цветному изображению называется квантованием цветов (color quantization). Квантование представляет собой процесс построения ограниченного набора цветов, с которыми результат вывода оказывается наиболее близким к исходному изображению. Если количество цветов в наборе не превышает 2N, каждый пиксел исходного изображения представляется N битами информации. Таким образом, квантование цветов также представляет собой методику сжатия изображений, приводящую к уменьшению их размеров (часто — с потерей данных). Например, файловый формат GIF поддерживает не более 256 цветов. Изображения High Color и True Color приходится конвертировать в 8-разрядный формат с использованием оптимальной палитры. В настоящее время в области квантования цветов ведутся активные исследования, поэтому существует множество разных алгоритмов, но нет единого оптимального решения. М. Герваутц (М. Gervautz) и В. Пургатхофер (W. Purgathofer) из Австрии в 1988 году опубликовали доклад о квантовании цветов с применением октантных деревьев. Этот простой, обеспечивающий отменное качество способ построения палитры получил широкое распространение. Алгоритм квантования с применением октантных деревьев состоит из трех этапов. На первом этапе строится дерево для сбора информации о распределении цветов в изображении. На втором этапе дерево оптимизируется объединением мелких узлов в более крупные, пока количество узлов не станет ниже отведенного предела. На последнем этапе цветовая таблица строится перебором узлов дерева. Корень дерева представляет все цветовое пространство RGB; для наших целей это означает совокупность точек RGB(r,g,b), где г, g и b лежат в интервале [0...255]. Корневой узел имеет 8 потомков, каждый из которых представляет 1/8 цветового пространства RGB. Деление осуществляется разбиением плоскостей R, G и В на две равные половины. На рис. 13.7 продемонстрировано деление корневого узла на 8 подузлов. Решение принимается на основании первого бита компонентов RGB, Все пикселы, у которых старшие биты составляющих равны 0, относятся к первому подузлу и обозначаются пометкой «OR, OG, OB», где R, G и В ограничиваются 7 битами. Все пикселы, у которых старшие биты RGB равны 1, относятся к последнему подузлу «1R, 1G, 1В». Деление узлов дерева продолжается до тех пор, пока не будет достигнут девятый уровень. Узлы второго уровня, находящиеся непосредственно под корнем, делятся по второму биту составляющих RGB; узлы третьего уровня делятся по третьему биту и т. д. Представление 24-разрядного пространства RGB октантным деревом теоретически связано с огромными затратами памяти. Дерево содержит 1 корень, 8 узлов второго уровня, 64 узла третьего уровня и 16,7 миллиона узлов девятого уровня. Полное октантное дерево состоит из 19 173 961 узла. Если каждый узел представляется 50 байтами, для хранения дерева потребуется 914 Мбайт памяти
Квантование цветов 727 (точнее — места на жестком диске). Фокус заключается в том, чтобы увеличивать дерево только в случае необходимости, и сокращать его при нехватке памяти. Собственно, именно по этой причине мы и используем дерево; работать с громадным массивом было бы гораздо проще. Синий со 0R,0G,0B 1R,0G,0B 0R,1G,0B xi: 1R,1G,0B 0R,0G,1B 1R,0G,1B 1R,1G,1B ч: Рис. 13.7. Представление цветового пространства RGB октантным деревом Помимо ссылок, образующих структуру дерева, каждый узел содержит информацию о представляемых им пикселах. Новый листовой узел, включаемый в дерево, представляет один пиксел. Со временем в него могут добавляться другие пикселы с такими же составляющими RGB. При нехватке памяти или сокращении дерева для построения палитры узлы могут укрупняться, поэтому один узел может представлять несколько пикселов с разными составляющими RGB. Класс KNode приведен в листинге 13.5. Листинг 13.5. Класс KNode для представления узлов октантного дерева class KNode { public: bool KNode * IsLeaf; Child[8]; unsigned Pixels; unsigned SigmaRed; unsigned SigmaGreen; unsigned SigmaBlue; KNode(bool leaf) { IsLeaf = leaf; Pixels =0; SigmaRed = 0; SigmaGreen = 0; Продолжение &
728 Глава 13. Палитры Листинг 13.5. Продолжение SigmaBlue = 0; memsetCChild. 0. sizeof(ChiId)): } RemoveAll(void); int PickLeaves(RGBQUAD * pEntry. int * pFreq, int size); }: KNode::RemoveAll(void) { for (int i»0; i<8; i++) if ( Child[i] ) { Child[i]->RemoveA110: Child[i] - NULL; } delete this; } int KNode::PickLeaves(RGBQUAD * pEntry, int * pFreq, int size) { if ( size==0 ) return 0; if ( IsLeaf ) { * pFreq pEntry->rgbRed pEntry->rgbGreen pEntry->rgbBlue pEntry->rgbReserved return 1: } else { int sum = 0; for (int i=0; i<8; i++) if ( ChildCi] ) sum += Child[i]->PickLeaves(pEntry+sum, pFreq+sum, size-sum); return sum; } } Переменная IsLeaf указывает, является ли узел листовым. Листовой узел определяется как узел, не имеющий потомков. В исходном состоянии дерева все листовые узлы находятся на девятом уровне. В процессе слияния узлы более высокого уровня тоже могут стать листовыми. Массив Child содержит 8 указателей на 8 потомков узла, не являющегося листовым. В остальных переменных = Pixels; = ( SigmaRed + Pixels/2 ) / Pixels = ( SigmaGreen + Pixels/2 ) / Pixels = ( SigmaBlue + Pixels/2 ) / Pixels - 0;
Квантование цветов 729 хранится количество пикселов и суммы их компонентов RGB для всех пикселов поддерева, корнем которого является текущий узел. Например, переменная Pixels корневого узла содержит общее количество пикселов во всем дереве. Следует учитывать, что сумма хранится в 32-разрядном целом без знака, поэтому октант- ное дерево позволяет хранить не более 224 пикселов. Конструктор класса KNode устроен очень просто — он ограничивается инициализацией переменных класса. Метод RemoveAl 1 удаляет все узлы текущего поддерева, используя обычную рекурсию. Метод PickLeaves собирает итоговую информацию, накопленную в дереве. Он заполняет массив структур PALETTEENTRY значениями RGB и заносит в целочисленный массив сведения о распределении цветов. Для этого мы просто перебираем узлы дерева и преобразуем каждый листовой узел в структуру PALETTEENTRY, значение RGB которой вычисляется усреднением значений RGB всех пикселов. Количество пикселов, представляемых каждым узлом, также сохраняется в массиве частот. Эта дополнительная величина может использоваться для сортировки массива PALETTEENTRY по частоте цветов. Класс октантного дерева KOctree приведен в листинге 13.6. Листинг 13.6. Класс октантного дерева, используемого для квантования цветов class KOctree { typedef enum { MAXMODE = 65536 }; KNode * pRoot; int Total Node; int TotalLeaf; void ReduceCKNode * pTree. unsigned threshold); public: KOctreeО { pRoot = new KNode(false): Total Node = 1; TotalLeaf = 0; } -KOctreeО { if ( pRoot ) { pRoot->RemoveA110; pRoot = NULL; } } void AddColor (BYTE r. BYTE g. BYTE b); void ReduceLeaves(int limit); int GenPalette(RGBQUAD *entry, int * Freq, int size); Продолжение^
730 Глава 13. Палитры Листинг 13.6. Продолжение void Merge(KNode * pNode, KNode & target); }: void KOctree::AddColor (BYTE r. BYTE g, BYTE b) { KNode * pNode = pRoot; for (BYTE mask=0x80; mask!=0; mask»=l) // Следовать до листового узла { // Добавить пиксел pNode->Pixels ++; pNode->SigmaRed += r; pNode->SigmaGreen += g; pNode->SigmaBlue +- b; if ( pNode->IsLeaf ) break; // Взять по одному биту от каждой составляющей // для формирования индекса int index = ( (г & mask) ? 4 : 0 ) + ( (g & mask) ? 2 : 0 ) + ( (b & mask) ? 1 : 0 ): // Создать новый узел, если это новая ветвь if ( pNode->Child[index]==NULL ) { pNode->Child[index] = new KNode(mask==2); Total Node ++; if ( mask==2 ) Total Leaf ++; } // Следовать дальше pNode - pNode->Child[index]; for (int threshold^; TotalNode>MAXMODE; threshold** ) Reduce(pRoot, threshold); // Объединить узел с листовыми узлами-потомками // и количеством пикселов, не превышающим threshold // Объединить листовой узел с количеством пикселов, // не превышающим threshold, с ближайшим соседом void KOctree::Reduce(KNode * pTree. unsigned threshold) { if ( pTree==NULL ) return; bool childallleaf = true;
Квантование цветов 731 // Рекурсивно вызвать для всех не-листовых потомков for (int i=0; i<8; i++) if ( pTree->Child[i] && ! pTree->Child[i]->IsLeaf ) { Reduce(pTree->Child[i], threshold); if ( ! pTree->Child[i]->IsLeaf ) childallleaf = false; } // Если все потомки являются листовыми узлами, // а количество пикселов не превышает порогового - объединить if ( childallleaf & (pTree->Pixels<=threshold) ) { for (int i=0; i<8; i++) if ( pTree->Child[i] ) { delete pTree->Child[i]; pTree->Child[i] = NULL; Total Node --; Total Leaf --; } pTree->IsLeaf = true; Total Leaf ++; return; } // Объединить листовых потомков // с небольшим количеством пикселов for (i-0: i<8; i++) if ( pTree->Child[i] && pTree->Child[i]->IsLeaf && (pTree->Child[i]->Pixels<=threshold) ) { KNode temp = * pTree->Child[i]; delete pTree->Child[i]; pTree->Child[i] - NULL; Total Node --; Total Leaf --; for (int j=0; j<8; j++) if ( pTree->Child[j] ) { Merge(pTree->Child[j], temp); break; } } } void KOctree;:Merge(KNode * pNode, KNode & target) { while ( true ) i Продолжение х£
732 Глава 13. Палитры Листинг 13.6. Продолжение pNode->Pixels += target.Pixels; pNode->SigmaRed += target.SigmaRed; pNode->SigmaGreen += target.SigmaGreen; pNode->SigmaBlue += target.SigmaBlue; if ( pNode->IsLeaf ) break; KNode * pChild = NULL; for (int i=0; i<8; i++) if ( pNode->Child[i] ) { pChild - pNode->Child[i]; break; } if ( pChild==NULL ) { assert(FALSE); return; } else pNode = pChild; } } void KOctree;;ReduceLeaves(int limit) { for (unsigned thresholds; TotalLeaf>limit; threshold**) Reduce(pRoot, threshold); } int KOctree;:GenPalette(RGBQUAD entry[], int * pFreq. int size) { ReduceLeaves(size); return pRoot->PickLeaves(entry, pFreq, size); } Переменные класса KOctree весьма просты. Переменная pRoot ссылается на корневой узел, от которого ссылки ведут ко всем остальным узлам. Общее количество узлов и листовых узлов в дереве хранится в переменных Total Node и Total Leaf. В начальном состоянии дерево состоит из корневого узла, созданного в конструкторе. Удаление всех узлов производится в деструкторе. Метод AddColor выполняет основную работу по построению дерева. Он получает красную, зеленую и синюю составляющие пиксела в пространстве RGB. Цвет сначала добавляется в корневой узел, после чего по первым битам составляющих RGB формируется индекс узла второго уровня. Пиксел добавляется на всех уровнях до тех пор, пока мы не встретим листовой узел. Если в процессе перебора оказывается, что подузел еще не был создан, метод создает его. Обра-
Квантование цветов 733 тите внимание: объединенные листовые узлы не подвергаются повторному делению. Максимальное количество узлов в классе KOctree устанавливается константой MAXN0DE. В настоящее время эта константа равна 65 536; обычно этого хватает для точного представления 16-разрядных изображений. Максимально допустимое дерево занимает около 3 Мбайт памяти. Если дерево содержит слишком много узлов, AddColor вызывает метод Reduce, чтобы произвести сокращение. Сокращение выполняется с постепенным повышением порога, начальное значение которого равно 1. На первом проходе объединяются все листовые узлы, содержащие один пиксел. Если после первого прохода по-прежнему остается слишком много узлов, порог увеличивается и процесс повторяется. Метод Reduce реализует алгоритм сокращения в три этапа. Сначала все не листовые подузлы сокращаются рекурсивным вызовом Reduce. Если после этого все подузлы текущего узла являются листовыми, а общее количество пикселов не превышает порога, все подузлы удаляются, а текущий узел помечается как листовой. Вспомните, что говорилось выше: AddColor добавляет информацию на каждый уровень дерева, поэтому каждый узел содержит сводные данные обо всех своих подузлах. На последнем этапе Reduce проверяет все листовые подузлы с небольшим количеством пикселов и объединяет их с одним из соседних узлов. Слияние соседних узлов выполняется методом Merge. Метод просто находит ветвь к листовому узлу и включает в нее данные RGB. Более рациональный алгоритм должен обеспечивать поиск ближайшего совпадения. Рассмотренные функции строят дерево и выполняют усечение, необходимое в том случае, если дерево становится слишком большим. После того как дерево построено, метод ReduceLeaves постепенно сокращает его до тех пор, пока количество листовых узлов не окажется ниже допустимого. Для сокращения дерева с увеличивающимся пороговым значением применяется уже знакомый метод Reduce. Мелкие узлы постепенно сливаются в большие узлы более высокого уровня, а большие узлы не участвуют в слиянии до тех пор, пока порог не поднимется до достаточно большой величины. Идея заключается в том, чтобы ограниченное число листовых узлов как можно точнее представляло распределение цветов в изображении. Таким образом, узлы с большим количеством пикселов попадут в итоговый набор цветов с большей вероятностью, нежели узлы с малым количеством пикселов. Метод GetPalette завершает квантование, заполняя массив структур PALETTEENTRY и массив частот. Он вызывает метод ReduceLeaves, чтобы уменьшить количество листовых узлов до заданной величины, и метод KNode: :PickLeaves для заполнения двух массивов. Нам остается лишь передать все пикселы растра классу KOctree для построения дерева, а затем сгенерировать палитру по данным листовых узлов. Класс KPaletteGen приведен в листинге 13.7. Листинг 13.7. Класс KPaletteGen: построение палитры с применением октантного дерева class KPaletteGen : public KPixelMapper {
734 Глава 13. Палитры KOctree octree: // Вернуть true, если данные изменились virtual boo! MapRGB(BYTE & red. BYTE & green. BYTE & blue) { octree.AddColor(red. green, blue); return false; } public: void AddBitmap(KImage & dib) { dib.Pixe!Transform(* this); } int GetPalette(RGBQUAD * pEntry. int * pFreq. int size) { return octree.GenPalette(pEntry, pFreq. size); int GenPalette(BITMAPINFO * pDIB. RGBQUAD * pEntry. int * pFreq. int size) { KImage dib; KPaletteGen pal gen; dib.AttachDIBCpDIB, NULL. 0); palgen.AddBitmap(dib); return palgen.GetPalette(pEntry. pFreq. size); } Класс KPaletteGen является производным от класса KPixelMapper, созданного в главе 12 для преобразования пикселов DIB. Вероятно, вы еще не забыли, что класс KPixel Mapper должен только реализовать метод MapRGB, который будет вызываться для каждого пиксела растра. Метод KPaletteGen::MapRGB просто добавляет цветной пиксел в экземпляр класса KOctree. Метод AddBitmap перебирает все пикселы растра и вызывает MapRGB для каждого пиксела. Метод GetPalette возвращает окончательную цветовую таблицу. Глобальная функция GenPalette генерирует цветовую таблицу для упакованного DIB-растра, для чего она использует классы KImage и KPaletteGen. Палитра, сгенерированная алгоритмом квантования по октантному дереву, обеспечивает очень хорошее качество даже в сравнении с профессиональными графическими пакетами. Ниже приведена 16-цветная цветовая таблица, построенная для изображения тигра с рис. 13.4. Для каждого элемента цветовой таблицы приведены значения RGB и количество пикселов, представляемых данным элементом. Как видите, количества представляемых пикселов неплохо сбалансированы.
Квантование цветов 735 PALETTEENTRY Ра116[] - // Для изображения тигра с рис. 13.4 { 59. { 55. { 76. { 99. { 101. { 113. { 153. { 140. { 166. { 206. { 170. { 173. { 212. { 234. { 232. { 250. 52. 41. 51. 77. 97. 108. 113. 119. 136. 148. 154. 149. 173. 207. 222. 244. 47 } 41 } 42 } 54 } 87 } 84 } 84 } 110 } 113 } 115 } 150 } 142 } 148 } 170 } 209 } 235 } . // . // . // . // . // . // . // . // . // . // . // . // . // . // . // , // 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10, 11. 12. 13. 14. 15. 3874 1792 2893 2823 5567 1652 5417 2475 4136 2521 2312 1899 3749 1610 2659 2781 На рис. 13.8 представлено изображение тигра с палитрами из 16, 64 и 236 цветов, сгенерированными алгоритмом квантования по октантному дереву без полутонирования. Рис. 13.8. Вывод растра с палитрой из 16, 64 и 236 цветов Алгоритм квантования по октантному дереву применяется и для других целей. В графических редакторах часто предусматривается возможность подсчета цветов в растре, чтобы выбрать способ сжатия. Для изображений True Color подсчет точного количества цветов является непростой задачей, поскольку существует 16,7 миллиона возможных вариантов. Октантное дерево является удобной структурой данных для решения этой задачи. Количество цветов в изображении совпадает с количеством листовых узлов в представлении дерева, если только у нас хватит памяти для полного сканирования изображения. Если класс KNode используется лишь для подсчета цветов, его можно оптимизировать для уменьшения затрат памяти. В альтернативном способе подсчета цветов строится массив 256x256x256 бит, в котором каждый бит представляет цвет в пространстве RGB 8x8x8. Общие затраты цамяти равны 2 Мбайт.
736 Глава 13. Палитры Сокращение цветовой глубины растра Итак, у нас имеется хороший алгоритм для построения «оптимальной» палитры. Следующим шагом будет преобразование растров High Color и True Color в индексный растр или вообще сокращения цветовой глубины растра. Например, мы можем преобразовать растр True Color в формат с кодировкой 8 бит/пиксел, что приведет к его сокращению до трети исходного размера, а также возможному выигрышу от сжатия RLE. Кроме того, можно преобразовать 8-разрядный растр в 4-разрядный. При работе с цветовой таблицей или палитрой простейший способ сокращения цветовой глубины сводится к алгоритму поиска ближайшего подходящего цвета. Цвет каждого пиксела в растре сравнивается со всеми цветами в таблице; индекс ближайшего совпадения принимается за новое значение пиксела в новом растре. В листинге 13.8 приведен класс KColorMatch, реализующий линейный поиск цветов методом «грубой силы». Метод KColorMatch::ColorMatch ищет в массиве структур RGBQUAD цвет, ближайший к заданному в цветовом пространстве RGB. Листинг 13.8. Класс KColorMatch: простой подбор цветов class KColorMatch { public: RGBQUAD *m_Colors; int mjiEntries; int squarednt i) { return i * i; } public: BYTE ColorMatch(int red, int green, int blue) { int dis • 0x7FFFFFFF; BYTE best = 0; if ( red<0 ) red=0; else if ( red>255 ) red=255: if ( greenO ) green=0: else if ( green>255 ) green=255: if ( blue<0 ) blue=0: else if ( blue>255 ) blue=255; for (int i-0; i<m_nEntries; i++) { int d - square(red - m_Colors[i].rgbRed): if ( d>dis ) continue: d +- square(green - m_Colors[i].rgbGreen): if ( d>dis ) continue: d +- square(blue - m_Colors[i].rgbBlue):
Сокращение цветовой глубины растра 737 } V0 { if ( d < { dis = best } } return best; dis ) : d; = i; id Setup(int nEntry. RGE mjiEntries m_Colors = nEntry; = pColor; В листинге 13.9 приведен простой класс для сокращения цветовой глубины растра, основанный на классах KColorMatch и KPixelMapper. Класс KColorReduction поддерживает только построение 8-разрядных DIB-растров, однако он легко расширяется для работы с другими форматами. Его главный метод, Convert8bpp, создает новый 8-разрядный растр, строит оптимальную цветовую таблицу с помощью алгоритма квантования по октантному дереву, а затем использует метод KImage: :PixelTransform для обращения к алгоритму подбора цветов. Листинг 13.9. KColorReduction: сокращение цветовой глубины поиском ближайшего цвета class KColorReduction : public KPixelMapper { protected: i nt mjiBPS; BYTE * m_pBits; BYTE *m_pPixel; KColorMatch m__Matcher; // Вернуть true, если данные изменились virtual bool MapRGB(BYTE & red. BYTE & green, BYTE & blue) { *m_pPixel ++ = m_Matcher.ColorMatch(red. green, blue); return false; virtual bool StartLine(int line) { m_pPixel = m_pBits + line * mjiBPS; // первый пиксел строки развертки return true; public: BITMAPINFO * Convert8bpp(BITMAPINF0 * pDIB); BITMAPINFO * KColorReduction::Convert8bpp(BITMAPINF0 * pDIB) Продолжение &
738 Глава 13. Палитры Листинг 13.9. Продолжение { mjiBPS « (pDIB->bmiHeader.biWidth + 3) / 4 * 4; // 8-разрядная // строка развертки int headsize = sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD); BITMAPINFO * pNewDIB - (BITMAPINFO *) new BYTE[headsize + mjiBPS * abs(pDIB->bmiHeader.biHeight)]; memsetCpNewDIB. 0, headsize); pNewDIB->bmiHeader.biSize - sizeof(BITMAPINFOHEADER); pNewDIB->bmiHeader.biWidth = pDIB->bmiHeader.biWidth; pNewDIB->bmiHeader.biHeight = pDIB->bmiHeader.biHeight; pNewDIB->bmiHeader.biPlanes = 1; pNewDIB->bmiHeader.biBitCount = 8; pNewDIB->bmiHeader.biCompression = BI_RGB; memset(pNewDIB->bmiColors, 0. 256 * sizeof(RGBQUAD)); int freq[236]; m_Matcher.Setup(GenPalette(pDIB, pNewDIB->bmiColors( freq. 236), pNewDIB->bmiColors); m_pBits = (BYTE*) & pNewDIB->bmiColors[256]: if ( pNewDIB==NULL ) return NULL; KImage dib; dib.AttachDIB(pDIB, NULL. 0): dib.PixelTransform(* this); return pNewDIB; } Класс KColorReduction обеспечивает почти тот же результат, что и при выводе растра средствами GDI без применения режима HALFTONE. Удивляться не приходится, поскольку GDI использует практически такой же алгоритм, хотя и лучше оптимизированный. В режиме HALFTONE GDI может использовать полутонирование для создания плавных переходов между оттенками цвета. Алгоритм поиска ближайших совпадений подбирает цвет для каждого пиксела независимо от других, тогда как полутоновый алгоритм пытается генерировать блоки пикселов, средний цвет которых аппроксимирует цвет исходного изображения. Режим масштабирования HALFTONE поддерживается только в системах семейства NT. Полутоновый алгоритм, используемый GDI, основан на простом смешении цветов. Существуют и более качественные алгоритмы — например, алгоритм рассеивания ошибок (error-diffusion) Флойда—Стейнберга. В этом алгоритме цвет каждого пиксела суммируется с накапливаемой ошибкой, изначально равной 0. Для полученного цвета обычным образом подбирается соответствие в цветовой таблице, а возвращаемый индекс сохраняется в итоговом растре. Основное от-
Сокращение цветовой глубины растра 739 личие от алгоритма GDI заключается в распределении расхождения между исходным и найденным цветом по соседним пикселам, что влияет на подбор цветов для этих пикселов. В алгоритме Флойда—Стейнберга ошибка делится на четыре неравные части (3/16, 5/16, 1/16 и 7/16), прибавляемые к четырем соседним пикселам. Для уменьшения количества сетчатых узоров, возникающих при смешивании, четные и нечетные строки развертки сканируются в противоположных направлениях. На рис. 13.9 изображена схема распределения ошибок в алгоритме Флойда—Стейнберга. 7/16 1/16 iiiiiiiijiiMiiiiiiiiiiii 5/16 3/16 3/16 lllllllSiBllllllllll 5/16 7/16 1/16 Прямое сканирование Обратное сканирование Рис. 13.9. Распределение ошибок в алгоритме Флойда—Стейнберга В листинге 13.10 приведена наша реализация алгоритма распределения ошибок. Класс KErrorDiffusionColorReduction является производным от класса KColor- Reduction, что позволяет нам использовать готовый код подбора цветов и построения 8-разрядного растра. Вместо функции отображения пикселов переопределяется механизм обработки 24-разрядных строк развертки. Алгоритму рассеяния ошибок нужны дополнительные переменные для хранения накапливаемой ошибки и флага, управляющего направлением сканирования строки. Реализация алгоритма на уровне строк развертки выглядела бы гораздо проще и работала бы быстрее, но для полноты решения мы должны предоставить реализации для строк развертки в других форматах. Листинг 13.10. Алгоритм рассеяния ошибок Флойда—Стейнберга class KErrorDiffusionColorReduction : public KColorReduction { int * red_error; int * green_error; int * blue_error; bool m_bForward; virtual bool StartLine(int line) { m_pPixel = m_pBits + line * m_nBPS; // Первый пиксел строки m_bForward = (line & 1) == 0; return true; } Продолжение &
740 Глава 13. Палитры Листинг 13.10. Продолжение virtual void Map24bpp(BYTE * pBuffer. int width); public: BITMAPINFO * Convert8bpp(BITMAPINF0 * pDIB): }: inline void ForwardDistribute(int error, int * curerror. int & nexterror) { if ( (error<@060>-2) || (error>2) ) // Ошибка -2..2 не распределяется { nexterror = curerror[l] + error * 7 / 16; curerror[-l] += error * 3 / 16; curerror[ 0] += error * 5 / 16; curerror[ 1] += error / 16; } else nexterror = curerror[l]; // // 3/16 X 5/16 7/16 1/16 } inline void BackwardDistribute(int error, int * curerror, int & nexterror) { if ( (error<-2) || (error>2) ) // Ошибка -2..2 не распределяется { nexterror = curerror[-l] + error * 7 / 16; // 7/16 X // 1/16 5/16 3/16 curerror[ 1] += error * 3 / 16 curerror[ 0] += error * 5 / 16 curerror[-l] += error / 16 } else nexterror = curerror[-l]; BITMAPINFO * KErrorDiffusionColorReduction::Convert8bpp(BITMAPINF0 * pDIB) { int extwidth = pDIB->bmiHeader.biWidth + 2; int * error = new int[extwidth*3]: memset(error. 0. sizeof(int) * extwidth * 3); red_error = error + 1; green_error = red_error + extwidth; blue_error = green_error + extwidth; BITMAPINFO * pNew = KColorReduction::Convert8bpp(pDIB); delete [] error; return pNew;
Сокращение цветовой глубины растра 741 void KErrorDiffusionColorReduction::Map24bpp(BYTE * pBuffer, int width) { int next_red. next_green, next_blue; if ( m_bForward ) { next_red = red_error[0] next_green = green_error[0] next_blue = blue_error[0] for (int i=0; i<width; i++) { int red = pBuffer[2] int green = pBuffer[l] int blue = pBuffer[0] BYTE match = m_Matcher.ColorMatch( red+next_red, green+next_green, blue+next_blue ); ForwardDistribute(red - m_Matcher.m_Colors[match].rgbRed . red__error +i. next_red); ForwardDistribute(green - m_Matcher.m_Colors[match].rgbGreen. green_error+i. next_green); ForwardDistribute(blue - m_Matcher.m_Colors[match].rgbBlue, blue_error +i. next_blue); * m_pPixel ++= match; pBuffer += 3; else next_red = red_error[width-l] next_green = green_error[width-l] next_blue = blue_error[width-l] pBuffer += 3 * width - 3; m_pPixel += width - 1; for (int i=width-l; i>=0; i--) { int red = pBuffer[2] int green = pBuffer[l] int blue = pBuffer[0] BYTE match = m_Matcher.ColorMatch( red+next_red. green+next_green, blue+next_blue ); BackwardDistribute(red - m_Matcher.m_Colors[match].rgbRed . red_error +i. next^red); BackwardDistribute(green - m_Matcher.m_Colors[match].rgbGreen, green_error+i. next_green); BackwardDistribute(blue - m_Matcher.m_Colors[match].rgbBlue. blue_error +i, next_blue); Продолжение^
742 Глава 13. Палитры Листинг 13.10. Продолжение * m_pPixel --= match; pBuffer -= 3; } } } Класс рассеяния ошибок содержит четыре дополнительные переменные. В трех из них хранятся массивы ошибок для каналов RGB. Функция Convert8bpp выделяет память под массивы из кучи и инициализирует ее нулями. Обратите внимание: инициализация обеспечивает возможность индексации red_error[-l] и red_error[width], чтобы избежать проверки границ при распределении ошибки. Переменная m_bForward указывает направление сканирования строки развертки (прямое или обратное), ее значение присваивается функцией StartLine. Две подставляемые (inline) функции, ForwardDistribute и BackwardDistribute, распределяют ошибку по трем каналам. Они получают текущую ошибку и указатель на текущую позицию в массиве ошибок, а возвращают следующее значение ошибки. В каждой строке развертки функция Мар24Врр суммирует составляющие цвета каждого пиксела с ошибками каналов, подбирает цвет, после чего распределяет ошибки и переходит к следующему пикселу. Алгоритм рассеяния ошибок обеспечивает гораздо лучший результат, чем алгоритм подбора ближайшего цвета, а в большинстве случаев — лучший, чем полутоновый алгоритм GDI. Одним из дополнительных преимуществ является то, что он может использовать любую палитру, тогда как полутоновый алгоритм GDI обычно работает с меньшим количеством цветов. Итоги Эта глава посвящена проблеме получения качественных цветных изображений на графических устройствах с ограниченным набором цветов. Для решения этой задачи приложению приходится иметь дело с палитрами, использовать их совместно с другими приложениями, строить палитры по цветовой таблице растра, производить квантование и сокращение цветовой глубины. В ближайшем будущем палитры по-прежнему останутся актуальными для приложений, ориентированных на массового потребителя. Если приложение использует более 20 цветов, при проектировании и реализации следует принимать во внимание палитру. С векторной графикой обычно бывает меньше проблем, чем с растрами, поскольку в ней обычно используется меньшее количество цветов. В обычных приложениях полутоновая палитра с равномерным распределением цветов, как правило, обеспечивает достаточно хороший результат. Однако в приложениях, работающих с высококачественной графикой или одновременно отображающих большое количество цветов, оптимальная специализированная палитра способна значительно улучшить качество графики по сравнению с полутоновой.
Итоги 743 Палитры поддерживаются и для поверхностей DirectDraw, что позволяет игровым программам создавать специальные эффекты анимации, основанной на изменении палитры, снижает затраты памяти или просто улучшает быстродействие на маломощных компьютерах. Наше знакомство с растрами и палитрами подошло к концу. В следующей главе мы переходим к совершенно новой теме — шрифтам и работе с текстом. Пример программы К главе 13 прилагается программа Palette, иллюстрирующая весь изложенный материал (табл. 13.3). Таблица 13.3. Программа главы 13 Каталог проекта Описание Samples\Chapt_13\Palette Демонстрация работы с системной палитрой, обработки сообщений палитры, применения полутоновых палитр, web-цветов и оттенков серого цвета, изменения видеорежима, построения палитры на базе растра, квантования цветов, распределения ошибок и т. д.
Глава 14 Шрифты С этой главы начнется наше знакомство со шрифтами и текстовыми операциями в графическом программировании Windows. Шрифты и их применение в печати имеют долгую и интересную историю. Давно, в 2400 году до нашей эры, индусы освоили изготовление резных штампов. Около 450 года нашей эры китайцы научились оставлять на бумаге оттиски штампов, намазанных чернилами, положивших начало современному книгопечатанию. В 1049 году китайцы разработали методику печати с применением глиняных литер, а в 1241 году корейцы перешли на металлические литеры. Еще два века спустя, в 1452 году, Гутенберг открыл новую эпоху в книгопечатании. С его изобретения — печатного станка — начался массовый выпуск типографских литер, используемых при наборе страниц текста. С этого времени полный набор символов одной гарнитуры и кегля стал называться в печатном деле «шрифтом». В 1976 году некий профессор решил выпустить второе издание своей книги, опубликованной за несколько лет до этого с применением тех же свинцовых матриц, что и у Гутенберга. К своему удивлению, он узнал, что старая технология постепенно уходит в прошлое, а новая — фотооптические наборные машины — еще не обеспечивает приемлемого качества. Профессор отказался использовать столь несовершенную технологию для представления плодов своего 15-летнего упорного труда и взялся за решение старых типографских проблем на базе компьютерных технологий. Четыре года спустя он разработал новый способ описания шрифтов математическими формулами, что привело к появлению полноценных наборных систем. С помощью одной из таких систем он и опубликовал свою работу, издание которой задержалось на 4 года. Профессора звали Дональд Кнут (Donald E. Knuth), шрифтовая программа называлась METAFONT, а для верстки использовался пакет ТеХ. Более того, все плоды труда Кнута вместе с полными исходными текстами были доступны для всех желающих, поэтому пользователи всего мира могли конструировать шрифты для любого языка и создавать электронные макеты книг. Шрифты и текст традиционно считаются весьма сложной темой. Эта глава посвящается шрифтам, а следующая — операциям с текстом. В этой главе мы
Что такое шрифт? 745 рассмотрим наборы символов, кодировки, глифы, шрифты вообще и их конкретную разновидность — шрифты TrueType, а также технологию внедрения шрифтов. Что такое шрифт? Компьютерная верстка всегда считалась одной из главных областей применения персональных компьютеров. В школьные годы и на протяжении всей жизни всем нам приходится создавать всевозможные документы и готовить к публикации книги. Процесс компьютерной верстки сильно зависит от поддержки шрифтов и текстовых операций на уровне операционной системы. Впрочем, шрифты и текст не относятся к базовым функциям систем компьютерной графики — в некоторых книгах, посвященных теоретическим основам компьютерной графики, они вообще не упоминаются. Скорее, шрифты и текст следует рассматривать как объекты применения общих принципов для решения целого класса практических задач. Как правило, шрифтовые и текстовые средства операционной системы реализуются с применением базовых графических примитивов (пикселы, линии, кривые, фигуры и растры). Вы даже можете создать собственные средства для работы со шрифтами и текстом на базе этих примитивов. Одним из основных инструментов компьютерной верстки являются шрифты — своего рода шаблоны для представления символов языка, с которым вы работаете. Традиционно шрифт определяется как полный набор литер одной гарнитуры и одного кегля, что соответствует специфике применения шрифта в типографском деле. Литерой называется прямоугольный блок (обычно металлический), на лицевой поверхности которого находится рельефное изображение символа. Цифровые технологии заметно расширили смысл термина и возможности шрифтов. В этом разделе мы рассмотрим базовые концепции и термины, относящиеся к работе со шрифтами в контексте графического программирования Windows. Наборы символов и кодировки Набор символов (character set) в системе Windows определяется... просто как совокупность символов. У каждого набора есть имя и числовой идентификатор. Например, стандартный набор символов Windows называется ANSICHARSET, его идентификатор равен 0, и он содержит символы 7-разрядной стандартной кодировки ANSI, определенной в Windows для западных языков. В окне DOS-сеанса используется набор OEM_CHARSET с идентификатором 255; он содержит те же 7-разрядные символы ANSI с дополнительными символами, которые были определены компанией IBM на ранних порах существования DOS. Наборы символов с однобайтовыми идентификаторами вряд ли можно считать хорошим решением, особенно в эпоху глобальных электронных коммуникаций в Интернете. На смену им пришла концепция кодировок, или кодовых страниц (code pages). Кодировкой называется схема представления символов из
746 Глава 14. Шрифты заданного набора одним или несколькими байтами информации. Таким образом, с формальной точки зрения кодировка представляет собой отображение последовательности битов в набор символов. Кодировки, в отличие от наборов символов, обозначаются двухбайтовыми числовыми идентификаторами, что обеспечивает поддержку большего количества языков. В табл. 14.1 перечислены наборы символов и соответствующие им кодировки, поддерживаемые операционной системой Windows. Первые 14 наборов, от SHIFJISCHARSET до EASTEUROPESET, связаны с кодировками однозначным соответствием. Например, для набора SHI FT JISCHARSET используется кодировка 932 (сокращение JIS означает Japanese Industry Standard, то есть «японский промышленный стандарт»). Набор символов 6B2312CHARSET соответствует кодировке 932 (GB — сокращение китайского национального стандарта). Последним трем наборам, ANSICHARSET, OEM_CHARSET и MAC_CHARSET, соответствуют разные кодировки в зависимости от локального контекста системы/процесса. Они отображаются на разные кодировки в зависимости от того, где действительно находится ваш компьютер или, по крайней мере, где компьютер «думает», что находится. Если в стандартном локальном контексте используется английский язык, то набор ANSICHARSET соответствует кодировке 1252, OEM_CHARSET соответствует кодировке 437, a MAC_CHARSET — кодировке 10000. Таблица 14.1. Наборы символов и кодировки Имя набора символов SHIFTJIS_CHARSET HANGUL_CHARSET J0HAB_CHARSET GB2312_CHARSET CHINESEBIG5_CHARSET GREEK_CHARSET TURKISH_CHARSET VIETNAMESE_CHARSET HEBREW_CHARSET ARABIC_CHARSET BALTIC_CHARSET Идентификатор набора символов 128 129 130 134 136 161 162 163 177 178 186 Кодировка 932, японский 949, корейский 1361 936, китайский (упрощенное письмо) 950, китайский (традиционное письмо) 1253, греческий (Windows) 1254, турецкий (Windows) 1258, вьетнамский (Windows) 1255, иврит (Windows) 1256, арабский (Windows) 1257, прибалтийский (Windows) Применение Япония Корея Китай, Сингапур Тайвань, Гонконг Турция
Что такое шрифт? 747 Имя набора символов RUSSIANCHARSET THAI_CHARSET EASTEUROPE_CHARSET ANSI_CHARSET OEM_CHARSET MAC_CHARSET Идентификатор набора символов 204 222 238 0 255 77 Кодировка 1251, кириллица (Windows) 874, тайский 1250, Windows Latin 2 1252, Windows Latin 1 1250, Windows Latin 2 1256, арабский (Windows) 437, MS_DOS Latin 1 852, MS_DOS Latin 2 864, MS_DOS арабский 10000, Mac (англоязычные страны) 10029, Mac (Центральная Европа) 10007, Mac (кириллица) Применение Славянские страны Центральная Европа США, Великобритания, Канада и т. д. Венгрия, Польша и т.д. Ирак, Египет, Йемен и т. д. США, Великобритания, Канада и т. д. Венгрия, Польша и т. д. Ирак, Египет, Йемен и т. д. США, Великобритания, Канада и т. д. Венгрия, Польша и т.д. Украина, Россия и т. д. Большинство кодировок содержит 256 символов. Один символ в них представляется всего одним байтом, поэтому эти кодировки называются однобайтовыми. Первые 128 символов однобайтовой кодировки обычно совпадают с символами 7-разрядного стандарта ANSI. Первые 32 символа соответствуют не- отображаемым управляющим кодам, за ними следует пробел, знаки математических операций и служебные символы, цифры и буквы английского алфавита в верхнем и нижнем регистре. Содержимое следующих 128 символов сильно изменяется в зависимости от кодировки. Именно здесь хранятся буквы национальных алфавитов, дополнительные знаки, символы псевдографики и даже недавно появившийся знак «евро». На рис. 14.1 приведено содержимое кодировки 1252 (Windows Latin l). Как видно из рисунка, вторая половина кодировки содержит символы национальных алфавитов, денежные знаки, апострофы и кавычки и т. д. Некоторые символы, помеченные пустыми прямоугольниками, не используются. Первый символ, 0x80, недавно был закреплен за знаком «евро». Для сравнения на рис. 14.2 изображена кодировка Windows для работы с кириллицей (1251). Обратите внимание: знак «евро» находится в другой позиции, поскольку символ с кодом 0x80 уже занят.
748 Глава 14. Шрифты 00 10 20 30 40 ЬО 60 70 80 90 АО ВО СО DO ЕО F0 П п 0 (А Р Р € D о А D а б П П 1 1 А 0 а q □ с i ± А N а п П п II о R R b г 1 ' Ф 2 А 0 а 6 П п # ч с я с s / (.С £ 3 А О а 6 П П $ 4 D Т d t ■>■> 55 п ' А 0 а 6 П П % S F, тт е 11 • ¥ l-i А 6 0 а б D □ _ 6 F V f V t - 1 1 1 Ж 0 ае 6 П □ i 7 G W g w + + — § Q X 9 -s- D П ( 8 Н X h X * ~ t Е 0 ё 0 D □ ) 9 I Y 1 У %0 тм © 1 Б и ё и D □ * J Z J z S s a о E U ё u D П + > к [ k { < > « » Ё U ё u D П •> < L \ 1 | (E oe -■ Va I \] i ii П П - = M ] 111 } □ D - '/a I Y i У D > N Л n ~ Z z ® 3/4 I Ь i t D / ? 0 о a a Y i I В i У Рис. 14.1. Кодировка Windows Latin 1 (1252) 00 10 20 30 40 50 60 70 80 90 АО ВО CO DO EO FO □ D 0 @ P " p ъ Ъ о A P a P □ D 1 1 A Q a q г i У ± Б С б с □ D II 2 В R b г ? ? У i в т в т D □ # 3 С S с s г (.(. J i Г У г У D D $ 4 D Т d t 55 55 п г Д Ф д ф □ D % 5 Е и е и • Г И Е X е X □ D _ б F V f V t - 1 1 1 Ж Ц Ж Ц □ □ i 7 G W g w + + — § 3 Ч 3 ч □ D ( 8 Н X h X € D Ё ё И Ш и ш □ D ) 9 I Y 1 У %о тм © № И щ й Щ □ D * J Z J z л> л> е е К Ъ к ъ □ □ + 5 К [ к { < > « » Л ы л ы □ □ 5 < L \ 1 1 Е> н> - J М Ь м ь □ □ - = М ] m } К К - S н э н э □ _ > N А 11 ~ Tl h ® S 0 Ю о ю D / ? О о □ ц ц I i п я п я Рис. 14.2. Кодировка Windows Cyrillic (1251)
Что такое шрифт? 749 Хотя однобайтовых кодировок хватает для представления символов большинства мировых языков, три восточных языка содержат слишком большое количество символов, не укладывающееся в границы однобайтовой кодировки. В китайской письменности используются тысячи иероглифов, часть из которых была позаимствована в Японии и Корее. Символы больших иероглифических наборов представляются несколькими байтами, поэтому такие кодировки обычно называются двухбайтовыми или многобайтовыми. В многобайтовом наборе символов (MultiByte Character Set, MBCS) символы 7-разрядного набора ASCII представляются одним байтом, а иероглифы китайского, японского и корейского языка — двумя байтами. Текстовая строка в кодировке MBCS всегда анализируется слева направо. Если первый (префиксный) байт меньше 128 (0x80), значит, перед нами однобайтовый символ из первой половины кодировки Windows Latin l (1252). Если префиксный байт равен 128 и выше, необходима дополнительная проверка, поскольку в двухбайтовых символах могут использоваться только байты из определенных интервалов. Если префиксный байт принадлежит к допустимому интервалу, происходит дополнительная проверка второго байта. Для кодировки 936, используемой в Китае и Сингапуре, оба байта должны лежать в интервале [0xA1...0xFE], что позволяет представить до 8836 двухбайтовых символов. Кодировка 949, используемая в Корее, устроена чуть сложнее. В ней префиксный байт принадлежит интервалу [0x81..0xFE], а второй байт должен входить в один из интервалов [0x41..0x5а], [0x61..0x7а] и [0x81..OxFE]. Количество допустимых символов увеличивается до 19 278. На рис. 14.3 приведен небольшой фрагмент традиционной китайской кодировки. Обратите внимание: китайские иероглифы в кодировке 950 сортируются по количеству черт. На рис. 14.3 изображены относительно простые иероглифы, содержащие не более четырех черт1. А440 А450 А460 А470 А4А0 А4В0 А4С0 A4D0 А4Е0 A4F0 — L t: Ф 7 if Я £ •х Ш Z, + % % в. iT «J ^ Г № Т ь я г щ ib м ^ ¥ л_ -ь X *} U] тр 01 % X *L ft 73 '. 1"- JH tp № Ъ ^k X Ж_ Л. т X X ф 4- я ?1 X 'Л 7 3t р а ft ъ и /> 4 Ж . ± ± В 3L IK ш X ft я Л Y ± В р 7G ¥ R Ъ & А % $ Ф ^ % fr * В Я Л я * -т -. й м В в JF А А & )\- # тЧ -к а я ф А <L т X Ж ъ Е -н- * Л 73 Ш ? Щ £ £ ж ъ X ЗЕ <| Ъ J. Я я. % Д §1 ± й Л ^ ^ ? t И £ jfr 3? ? Рис. 14.3. Фрагмент кодировки 950 (китайский, упрощенное письмо) На первый взгляд может показаться, что количество черт в некоторых иероглифах больше четырех, однако это связано со специфическими правилами подсчета. — Примеч. перев.
750 Глава 14. Шрифты При работе с разными кодировками (особенно многобайтовыми) в программах возникает немало сложностей. Например, даже для решения простейших задач вроде перехода к следующему символу приходится вызывать функцию Windows API CharNext вместо того, чтобы просто увеличить указатель на 1. С переходом к предыдущему символу дело обстоит еще сложнее — об этом свидетельствует передача дополнительного параметра (начального адреса строки) функции CharPrev. Большие хлопоты возникают и с преобразованием символов между кодировками. Для решения этих проблем и был предложен стандарт Unicode. Разработка, сопровождение и продвижение стандарта двухбайтовой кодировки символов Unicode осуществляется Консорциумом Unicode. В этот консорциум входят Apple, Hewlett-Packard, IBM, Microsoft, Oracle, Sun, Xerox и другие компании. Стандарт Unicode позволяет представить большую часть символов письменности практически всех языков мира. В нем используется 16-разрядное представление без префиксов или переключения режимов, что обеспечивает возможность выражения до 65 536 символов. В Unicode символ представляется 16-разрядным значением от 0000 до FFFF (в шестнадцатеричной записи). Символы группируются на логические зоны. Например, зона 01 соответствует базовым символам латинского алфавита с кодами от 0000 до 007F. В зоне 29 находятся общие знаки препинания с кодами от 2000 до 206F. Самая большая зона 54 содержит 29 902 китайских иероглифов, используемых в Китае, Японии и Корее. Вторая по величине зона 55 содержит И 172 иероглифа хангыль, используемых в Корее. На рис. 14.4 изображены символы, входящие в зону условных знаков Unicode. 2600 2610 2620 2630 2640 2650 2660 D Д ZHZ * ф ф * 0 z ЛИЛ 6 V5 V 1* И V МММ с? О i?i X <& j^jU ч 00 * # □ т ш ш к Ф ♦ • □ t — ¥ © v * □ t т т т т W 1 ♦ < □ f т т а т Е JL * ГС □ f Щ Г й ё> 0 □ * © V & J а •ш О © Ж ® р V яг Ф • © ш л 6 "S3 ф а SI 1 Л <? Ь £ 3> ИР к ь ^ GT ® С -Л. й *1 Ф Р © 5 щ i # Рис. 14.4. Зона условных знаков Unicode Хотя операционная система Windows проектировалась для поддержки разных кодировок и языков, для работы с конкретными кодировками и языками нужны дополнительные файлы, которые могут отсутствовать в стандартном варианте установки вашей системы. Дополнительные пакеты устанавливаются при помощи приложения Regional Settings (Язык и стандарты) панели управления либо с компакт-диска операционной системы, либо с web-сайта Microsoft. Функция EnumSystemCodePages API перечисляет все кодовые страницы, поддерживаемые или установленные в вашей системе.
Что такое шрифт? 751 Глифы Наборы символов и кодовые страницы определяют лишь логическую группировку и представление символов, а не их внешний вид. Символ — всего лишь абстрактная концепция, а не конкретное представление. Нарисованный на бумаге символ обретает графическую форму, которая называется глифом (glyph). Например, в кодировке Windows Latin 1 английская прописная буква А имеет индекс 0x41, однако она может выглядеть по-разному, как показано на рис. 14.5. АААААААААаААЛАлААИЛл Рис. 14.5. Различные глифы для буквы А Взаимосвязь между глифом и символом Между символами и глифами в шрифте обычно существует однозначное соответствие. Один символ представляется ровно одним глифом, а один глиф представляет ровно один символ. Впрочем, это не всегда так. Встречаются символы, которые представляются комбинацией нескольких глифов, а один и тот же глиф может использоваться в разных символах. Такие глифы характерны для китайских или корейских иероглифов, которые часто состоят из нескольких частей, хотя в качественных шрифтах лучше использовать несколько версий одного глифа. Глифы символов также могут изменяться в зависимости от контекста, в котором записывается символ. Например, символы, находящиеся в начале или в конце предложения, могут оформляться специальными глифами. В частности, контекстные формы глифов широко используются в арабских языках, а при вертикальной записи китайского текста изменяется ориентация скобок. Если некоторые комбинации символов расположены по соседству, они могут быть преобразованы в один глиф, называемый лигатурой. В общем случае символ представляется одним или несколькими глифами, которые могут использоваться несколькими символами; также допускается объединение нескольких символов в лигатуру по специальным правилам. На рис. 14.6 продемонстрирована связь между символами и глифами. В первой строке приведена буква О с разными диакритическими знаками, за которой следуют китайские иероглифы с общим левым ключом. Эти примеры показывают, что один символ может соответствовать нескольким глифам. Во второй строке приведены некоторые лигатуры, используемые в датском, норвежском, французском и английском языках. Третья строка показывает, как круглые и квадратные скобки преобразуются в вертикальные глифы при традиционном вертикальном китайском письме, которое продолжает использоваться в особых случаях (например, в свадебных приглашениях). В последней строке изображены четыре группы глифов для трех арабских символов. Каждый арабский символ может иметь до четырех контекстных глифов, для изолированной, начальной, конечной и промежуточной форм.
752 Глава 14. Шрифты \ г j\ ооооо л$щшщш*& А+Е=/Е C+E=QE f+i=fl f+l=fl \1У<.) к1>Ч Л ту. vV. V V V So* \щ+ V V Рис. 14.6. Связь между символами и глифами Элементы глифа Глифы с постоянными атрибутами обычно группируются. Для букв латинского алфавита к таким атрибутам относятся толщина черт, стиль штриха, применение засечек, выравнивание по базовой линии, форма овалов и петель, величина надстрочных и подстрочных частей и т. д. Базовой линией (baseline) называется воображаемая линия, предназначенная для вертикального выравнивания глифов. Латинские буквы обычно выравниваются по базовой линии; исключение составляют буквы с подстрочными элементами (например, f, g, j и Q). Высота строчной буквы х называется х-высотой и обычно определяет высоту основной части всех глифов строчных букв. Некоторые строчные глифы поднимаются над высотой буквы х; их выносные элементы называются надстрочными (ascender). Некоторые строчные глифы спускаются ниже базовой линии; соответствующие элементы глифов называются подстрочными (descender). Кроме того, глифы могут обладать засечками (serifs ) — маленькими поперечными черточками на концах основных линий. Маленький шарик на конце черты (как в буквах а, с, f и у) называется каплевидным элементом (ball, или ball terminator). Внутрибуквенным просветом (counter) называется область, полностью или частично окруженная глифом (как в буквах р, d или е). Термин «полуовал» (bowl) относится к базовой форме таких букв, как С, G и D. На рис. 14.7 изображены некоторые элементы глифов с засечками. Надстрочный выносной элемент Засечка . i _^^^ Полуовал Базовая линия ^^ wmww или ^^ ^ I i\jj |y\JOC*i I GtyfllrDesigm- Каплевидный Внутрибуквенный Подстрочный элемент просвет выносной элемент Рис. 14.7. Структурные элементы глифа для латиницы
Что такое шрифт? 753 Глифы других языков могут иметь аналогичную структуру или содержать другие элементы, унаследованные по историческим причинам. Шрифт После знакомства с наборами символов, кодировками и глифами можно дать определение шрифта. Шрифтом называется совокупность глифов, обладающих сходным графическим стилем, для которой определено отображение символов поддерживаемых кодировок в глифы. Шрифт может поддерживать одну или несколько кодировок; для каждого символа каждой кодировки он устанавливает соответствие с группой глифов, образующих графическое представление символа. Глифы и правила отображения символов в глифы относятся к базовым компонентам шрифта. Шрифты обладают множеством других атрибутов. Так, у каждого шрифта имеется полное имя (например, Times New Roman Bold или Courier New Italic). Имена шрифтов обычно защищаются авторским правом. Например, компания Microsoft обладает правами на шрифт Wingdings, а шрифт Courier New Italic принадлежит Monotype Corp. Шрифты обычно хранятся в физических файлах в подкаталоге шрифтов системного каталога. На панели управления имеется приложение Fonts (Шрифты) для просмотра, установки и удаления шрифтов в системе. Чтобы получить список всех шрифтов, установленных в системе, необходимо перебрать ключи реестра. Код приведенного ниже фрагмента перечисляет все шрифты в системе и использует собранные данные для заполнения списка. void ListFontsCKListView * pList) { const TCHAR Key_Fonts[] « J'CSOFTWAREWMicrosoftWWindows NT" "WCurrentVersionWFonts"); HKEY hKey; if ( RegOpenKeyEx(HKEY_LOCAL_MACHINE. Key_Fonts, 0, KEY_READ, & hKey)==ERROR_SUCCESS ) { for (int i=0; ; i++) { TCHAR szValueName[MAX_PATH]; BYTE szValueData[MAX_PATH]; DWORD nValueNameLen = MAX_PATH; DWORD nValueDataLen = MAX_PATH; DWORD dwType; if ( RegEnumValueChKey. i. szValueName, & nValueNameLen, NULL. & dwType. szValueData, & nValueDataLen) != ERROR_SUCCESS ) break; pList->AddItem(0. szValueName); pList->AddItem(l. (const char *) szValueData); }
754 Глава 14. Шрифты RegCloseKey(hKey); } } Семейство шрифтов и начертание Имя шрифта определяет семейство, к которому он принадлежит, и его начертание. Семейством называется группа шрифтов, обладающих сходными характеристиками и объединенных общим названием. Например, семейство Times New Roman состоит из четырех разных шрифтов: Times New Roman, Times New Roman Italic, Times New Roman Bold и Times New Roman Bold Italic. Видоизменение шрифта в семействе называется начертанием. К числу распространенных начертаний относятся нормальное, полужирное, курсивное, сжатое, с подчеркиванием и перечеркиванием символов и т. д. Вместо создания новых шрифтов начертание может имитироваться изменением параметров глифа. Например, шрифты, созданные программой METAFONT уже упоминавшегося Кнута, зависят от десятка с лишним параметров, позволяющих изменить размер засечек, толщину черт и т. д. Подчеркивание и перечеркивание в Windows обычно имитируется средствами GDI. Семейство шрифтов является удобной абстракцией, но как приложение узнает, к какому семейству относится тот или иной шрифт? GDI поддерживает 8 флагов для классификации семейств шрифтов по базовым характеристикам глифов. Эти флаги перечислены в табл. 14.2. Таблица 14.2. Флаги семейств и шага шрифта Флаг DEFAULT_PITCH FIXED_PITCH VARIABLE_PITCH FF_DONTCARE FF_R0MAN FFJWISS FF_M0DERN FFJCRIPT FF_DECORATIVE Значение 1 2 4 0«4 1«4 2«4 3«4 4«4 5«4 Описание Произвольный шаг шрифта Моноширинный шрифт Пропорциональный шрифт Шрифт с произвольными атрибутами Шрифт с переменной толщиной линий и засечками Шрифт с переменной толщиной линий без засечек Шрифт с постоянной толщиной линий Рукописный шрифт Затейливый оформительский шрифт В моноширинных шрифтах все глифы имеют одинаковую ширину. Моноширинные шрифты обычно применяются в окнах DOS-сеансов, при выводе листингов и вообще всюду, где необходимо обеспечить выравнивание по вертикали. В пропорциональных шрифтах глифы обладают разной шириной; буквы i или 1 занимают гораздо меньше места, чем т. Текст, выведенный пропорциональным шрифтом, лучше воспринимается человеческим глазом, поэтому в книгах, элек-
Что такое шрифт? 755 тронной документации и на web-страницах используются пропорциональные шрифты. Шрифты семейства Roman обладают переменной толщиной линий и засечками. В семействе Swiss используется переменная толщина линий, но без засечек. Шрифты семейств Roman и Swiss обычно являются пропорциональными. Семейство Modern содержит шрифты с постоянной толщиной линий, как правило — моноширинные. Шрифты семейства Script имитируют рукописный текст. Все остальные экзотические шрифты отнесены к семейству Decorative. На рис. 14.8 приведены примеры шрифтов некоторых семейств. Roman Roman Roman Roman Swiss Swiss Swiss Swiss Modem Modern Modern Modern Qtfwfpt Script Script Script Sct0tatiut Secorative $йШга&Ь<& DECORATIVE Рис. 14.8. Классификация семейств шрифтов В приложениях обычно удобнее работать с семействами шрифтов, нежели с отдельными шрифтами, поскольку семейств меньше и из них удобнее выбирать. В GDI существует функция EnumFontFamiliesEx для перечисления всех семейств шрифтов, доступных в системе. int EnumFontFamiliesEx (HDC hDC. LPLOGFONT IpLogFont. FONTENUMPROC IpEnumFontFamExProc, LPARAM IParam. DWORD dwFlags); В первом параметре передается контекст устройства. Некоторые графические устройства (например, лазерные принтеры или принтеры PostScript) могут поддерживать аппаратные шрифты, предназначенные только для данного устройства. Второй параметр указывает на структуру LOGFONT, поля которой 1 fCharset и 1 fFaceName определяют набор символов и гарнитуру, интересующие приложение. Если указать набор символов DEFAULT_CHARSET, семейства шрифтов, поддерживающие несколько наборов, будут многократно включены в список. При указании конкретного набора символов в перечислении участвуют только семейства шрифтов, содержащие заданную категорию глифов (например, для набора SYMB0L_ CHARSET — глифы символических знаков). Поле IfPitchAndFamily структуры LOGFONT должно быть равно нулю. Параметр IpEnumFontFamExProc указывает на глобальную функцию, вызываемую для каждого перечисляемого семейства шрифтов — такое решение плохо соответствует стилю C++. Впрочем, у нас есть параметр IParam с данными, передаваемыми вызывающей стороной функции косвенного вызова; этим параметром можно воспользоваться для стыковки C++ с Win32. Последний параметр dwFl ags должен быть равен 0. Функция EnumFontFamiliesEx играет ключевую роль при заполнении списков доступных шрифтов в диалоговых окнах приложений. С ее помощью можно получить перечень всех семейств, поддерживающих конкретный набор символов, или всех наборов, поддерживаемых для конкретной гарнитуры. В листинге 14.1
756 Глава 14. Шрифты приведен вспомогательный класс для работы с этой функцией. Реализация по умолчанию сохраняет результаты перечисления в списке. Листинг 14.1. Перечисление семейств шрифтов class KEnumFontFamily { KListView * m_pList; int static CALLBACK EnumFontFamExProc(ENUMLOGFONTEX *lpelfe. NEWTEXTMETRICEX *lpntme, int FontType, LPARAM lParam) { if ( lParam ) return ((KEnumFontFamily *) lParam)->EnumProc(lpelfe. Ipntme, FontType); else return FALSE; } publi с: LOGFONT m_LogFont[MAX_LOGFONT]; int mjiLogFont; unsigned mjiType; virtual int EnumProc(ENUMLOGFONTEX *lpelfe. NEWTEXTMETRICEX *lpntme. int FontType) { if ( (FontType & m_nType)==0 ) return TRUE; if ( mjiLogFont < MAX_L0GF0NT ) m_LogFont[m_nLogFont ++] = 1 pelfe->elfLogFont; m_pList->AddItem(0. (const char *) I pelfe->elfFullName); m_pList->AddItem(l. (const char *) 1 pelfe->elfScript): m_pList->AddItem(2, (const char *) lpelfe->elfStyle); m_pList->AddItem(3. (const char *) lpelfe->elfLogFont.lfFaceName); m_pLi st->AddItem(4. 1 pelfe->elfLogFont.1fHeight); m_pLi st->AddItem(5. 1 pelfe->elfLogFont.1fWidth); m_pLi st->AddItem(6, 1 pelfe->elfLogFont.1fWeight); return TRUE; void EnumFontFamilies(HDC hdc, KListView * pList, BYTE charset = DEFAULT_CHARSET, TCHAR * FaceName = NULL, unsigned type - RASTER JONTTYPE | TRUETYPEJONTTYPE | DEVICEJONTTYPE) { m_pList = pList; m_nType = type; LOGFONT If; memset(& If, 0, sizeof(lf)):
Что такое шрифт? 757 If.lfCharSet = charset; lf.lfFaceName[0] = 0; lf.lfPitchAndFamily = 0; if ( FaceName ) _tcscpy(If.IfFaceName. FaceName); Enum FontFamiliesEx(hdc. & If, (FONTENUMPROC) EnumFontFamExProc, (LPARAM) this, 0); На рис. 14.9 сопоставлены результаты перечисления шрифтов и их семейств. Перечисление шрифтов, основанное на просмотре системного реестра, выводит список всех физических шрифтов в системе. Мы видим четыре шрифта семейства Arial, четыре шрифта семейства Courier New и т. д. При перечислении семейств некоторые семейства встречаются в списке многократно, если они поддерживают разные наборы символов. Например, семейство шрифтов Arial поддерживает 9 разных наборов. j^SpS^IV^^^^^'ft.f.'t.ic.Vt'tr.'.Ti t 1.НИШ J Tahoma (TrueType) 1 Microsoft Sans Serif Regular (TrueType) I SimSun 8c NSimSun (TrueType) 1 SimHei (TrueType) 1 MingLiU 8c PMingLiU (TrueType) I Roman (All res) 1 Script (All res) 1 Modern (All res) 1 Arial (TrueType) 1 Arial Bold (TrueType) 1 Arial Bold Italic (TrueType) I Arial Italic (TrueType) | Courier New (TrueType) 1 Courier New Bold (TrueType) 1 Courier New Bold Italic (TrueType) 1 Courier New Italic (TrueType) | Lucida Console (TrueType) лМШ] ' im ш TAHOMATTF i MICROSS.TTF 1 simsun.ttc jj simheLttf II mingliu.ttc J ROMAN.FON SCRIPT.FON J MODERN.FON ARIALTTF 1 ARIALBD.TTF j ARIALBI.TTF i ARIALI.TT? j COUR.TTF i COURBD.TTF ; COURBI.TTF ! COURI.TTF J! LUCONTTF^| tfeiitew» l&te. [ Anal Western ] Anal Hebrew ] Anal Arabic 1 Anal Greek 1 Anal Turkish | Anal Baltic ] Anal Central European | Anal Cyrillic ] Anal Vietnamese | Courier New Western j Courier New Hebrew ] Courier New Arabic 1 Courier New Greek j Courier New Turkish j Courier New Baltic 1 Courier New Central European и i '- iMe Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular Regular .■l.&Bfo&MMlI Anal Arial Arial Arial Arial Arial Arial Arial Arial Courier New Courier New Courier New Courier New Courier New Courier New Courier New мШЩ 15531 36 f 36 1 36 j 36 $ 36 *£ 36 1 36 1 36 1 36 1 36 I 36 I 36 1 36 [ 36 f 36 j зб Л . j£3 Рис. 14.9. Сравнение шрифтов и семейств шрифтов При поддержке двухбайтовых кодировок (для японского, китайского и корейского языков) функция EnumFontFamiliesEx возвращает два семейства. Например, семейство шрифтов Gulim поддерживает набор HANGUL_CHARSET; в процессе перечисления для него будут указаны семейства Gulim и ©Gulim. Семейства шрифтов, имена которых начинаются с символа @, обладают особыми средствами для поворота двухбайтовых глифов, что позволяет имитировать вертикальную письменность, используемую в Китае, Японии и Корее. С помощью флагов семейств и шага шрифта, перечисленных в табл. 14.2, пытаются классифицировать шрифты и семейства всего одним байтом, что, конечно, не обеспечивает необходимой точности. Значительно более точный способ описания шрифта предоставляет структура PANOSE, в 10 байтах которой кодируются сведения обо всех важнейших характеристиках шрифтов — типе семейства, наличии засечек, насыщенности, пропорциональности, контрасте и т. д.
758 Глава 14. Шрифты Растровые шрифты Существуют разные способы представления глифов шрифта. В простейшем варианте пикселы, образующие глиф, представляются в виде растрового изображения. Такие шрифты называются растровыми. Возможны и другие решения — например, описывать контуры глифа прямыми линиями (векторные шрифты). Большинство шрифтов, используемых в системе Windows в наши дни, относятся к категории TrueType или ОрепТуре. В этих шрифтах для представления контура глифа и управления процессом вывода применяются значительно более сложные средства. В этом разделе мы познакомимся с растровыми шрифтами. Другие категории шрифтов рассматриваются в разделах «Векторные шрифты» и «Шрифты TrueType». Растровые шрифты давно применяются при выводе информации. В эпоху DOS в памяти BIOS хранились растровые шрифты для разных разрешений экрана. Когда приложение выдавало программное прерывание на вывод символа в графическом режиме, система BIOS производила выборку данных глифа и отображала его в заданной позиции. В ранних версиях Windows до появления Windows 3.1 никакие другие шрифты, кроме растровых, вообще не поддерживались. Впрочем, и в наши дни растровые шрифты широко применяются при выводе таких элементов пользовательского интерфейса, как меню, диалоговые окна и сообщения-подсказки, не говоря уже об окнах DOS-сеансов. Даже в новейших операционных системах Windows по-прежнему используются десятки растровых шрифтов. Для разных разрешений экрана требуются разные наборы растровых шрифтов, соответствующих разрешению. Например, файл sserife.fon представляет шрифт MS Sans Serif для режима с разрешением 96 dpi и с аспектным отношением 100 %, тогда как шрифт sseriff.fon предназначен для разрешения 120 dpi. При переходе от мелкого системного шрифта (96 dpi) к крупному (120 dpi) вместо sserife.fon задействуется шрифт sseriff.fon. Смена системного шрифта влияет на преобразование единиц, используемых в процессе конструирования диалоговых окон, в экранные координаты, поэтому элементарное переключение шрифта способно испортить ваши тщательно сконструированные диалоговые окна. Некоторые растровые шрифты абсолютно необходимы для нормальной работы системы, поэтому для предотвращения случайного удаления они хранятся в скрытых файлах. Файлы растровых шрифтов обычно имеют расширение .fon. Они хранятся в 16-разрядном исполняемом формате NE, первоначально использовавшемся в 16-разрядных версиях Windows. В FON-файле хранится текстовая строка с описанием характеристик шрифта. Например, для courf.fon описание имеет вид «FONTRES 100,120,120:Courier 10,12,15(8514/a res)»; в нем содержится имя шрифта, аспектное отношение (100), DPI (120 х 120) и поддерживаемые кегли (10, 12, 15). Каждому кеглю, поддерживаемому растровым шрифтом, соответствует один ресурс растрового шрифта, обычно хранящийся в файле с расширением .fnt. Ресурсы растровых шрифтов могут включаться в итоговый файл растрового шрифта в виде ресурса типа FONT. В Platform SDK входит утилита FONTEDIT, предназначенная для редактирования существующих файлов шрифтовых ресурсов (распространяется с исходным текстом).
Растровые шрифты 759 Несмотря на свою старомодность, ресурсы растровых шрифтов заслуживают внимания, поскольку они дают хорошее представление о том, как проектируются и используются шрифты. Ресурсы растровых шрифтов существуют в двух версиях: версии 2.00, используемой в Windows 2.0, и версии 3.00, предназначавшейся для Windows 3.00. Возможно, вы не поверите, но даже Windows 2000 работает с растровыми шрифтами в формате 2.00. Специфические возможности версии 3.00 были реализованы для шрифтов TrueType. Каждый шрифтовой ресурс начинается с заголовка фиксированного размера, содержащего информацию о номере версии, размере, авторских правах, поддерживаемом разрешении, наборе символов и метриках шрифта. Для шрифтов версии 2.00 поле Version равно 0x200. Младший бит поля Туре для растровых шрифтов равен 1. Каждый шрифтовой ресурс рассчитан на одно стандартное разрешение, но допускает и другие возможные разрешения. На современных мониторах вертикальное разрешение обычно совпадает с горизонтальным — например, 96 х 96 dpi. Высота шрифта кегля 10 пунктов на мониторе с разрешением 96 dpi составляет приблизительно 13 пикселов (10 х 96/72). Ресурс растрового шрифта поддерживает только один однобайтовый набор символов. Он содержит глифы всех символов из интервала, заданного полями FirstChar и LastChar. В каждом шрифтовом ресурсе определяется символ по умолчанию, используемый при выводе символов, не принадлежащих поддерживаемому интервалу (поле Default - Char). Поле BreakChar содержит символ разделителя слов. typedef struct { WORD DWORD CHAR WORD WORD WORD WORD WORD WORD WORD BYTE BYTE ByTE WORD BYTE WORD WORD BYTE WORD WORD BYTE BYTE BYTE BYTE DWORD DWORD DWORD DWORD Version; Size; Copyright[60] Type; Points; VertRes; HorizRes; Ascent; IntLeading; ExtLeading; Italic; Underline; StrikeOut; Weight; CharSet; PixWidth; PixHeight; Family; AvgWidth; MaxWidth; FirstChar; LastChar; DefaultChar; WidthBytes; Device; Face; BitsPointer; BitsOffset; // 0x200 для версии 2.0. 0x300 для версии 3. // Размер всего ресурса // Для растровых шрифтов Туре & 1 == О // Номинальный размер в пунктах // Номинальное вертикальное разрешение // Номинальное горизонтальное разрешение 00 // 0 для пропорционального шрифта // Семейство // Ширина символа 'х' // Максимальная ширина // Первый символ, определенный в шрифте // Последний символ, определенный в шрифте // Замена для символов, не входящих в интервал // Количество байт на строку растра // Смещение строки с именем устройства // Смещение строки с именем гарнитуры // Адрес загруженного растра // Смещение графических данных
760 Глава 14. Шрифты BYTE Reserved; // 1 байт, не используется } FontHeader20; После заголовка ресурса шрифта следует таблица символов (вернее, таблица глифов). Для растровых шрифтов версии 2.0 каждому символу из поддерживаемого интервала в таблице символов соответствует два 16-разрядных целых: для ширины и для смещения глифа. В этом проявляется серьезный недостаток архитектуры шрифтовых ресурсов версии 2.00: из-за 16-разрядного смещения объем ресурса ограничивается 64 килобайтами. Таблица символов содержит (LastChar- FirstChar+2) элементов. Лишний элемент остается пустым. typedef struct { SHORT Glwidth; SHORT Gloffset; } GLYPHINFO_20; Версия 2.00 поддерживала только монохромные глифы. Хотя версия 3.00 рассчитана на поддержку глифов с 16 и 256 цветами и даже глифов в формате True Color, на практике такие шрифты не встречаются. В монохромных глифах для представления одного пиксела достаточно одного бита. С другой стороны, порядок этих битов в глифах не имеет ничего общего с теми растровыми форматами, о которых говорилось выше. Первый байт глифа содержит первые 8 пикселов первой строки развертки, второй байт — первые 8 пикселов второй строки развертки и т. д. до завершения первого столбца из 8 пикселов. Затем следуют данные второго столбца из 8 пикселов, третьего столбца и т. д. до полной ширины глифа. Подобная структура когда-то считалась стандартным элементом оптимизации, ускоряющим вывод символов. Ниже приведена функция для вывода одного глифа растрового шрифта. Функция находит таблицу GLYPHINF0 после заголовка, вычисляет индекс глифа в таблице, а затем преобразует глиф в монохромный DIB-растр и выводит его функциями, предназначенными для работы с DIB. int CharOutCHDC hDC. int x, int y, int ch. KFontHeader20 * pH, int sx=l. int sy=l) { GLYPHINFO_20 * pGlyph = (GLYPHINFO_20 *) ( (BYTE *) & pH-> BitsOffset + 5); if ( (ch<pH->FirstChar) || (ch>pH->LastChar) ) ch = pH->DefaultChar; ch -= pH->FirstChar; int width = pGlyph[ch].Glwidth; int height = pH->PixHeight; struct { BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[2]: } dib { { sizeof(BITMAPINFOHEADER). width, -height. 1. 1. BI_RGB }. { { OxFF. OxFF. OxFF. 0 }. { 0. 0. 0. 0 } } int bpl = ( width + 31 ) / 32 * 4;
Растровые шрифты 761 BYTE data[64/8*64]; // Достаточно для 64x64 const BYTE * pPixel = (const BYTE *) pH + pGlyph[ch].GIoffset; for (int i=0; i<(width+7)/8; i++) for (int j=0; j<height; j++) data[bpl * j + i] = * pPixel ++; StretchDIBits(hDC. x, y, width * sx, height * sy. 0. 0, width, height, data. (BITMAPINFO *) & dib. DIB_RGB_COLORS. SRCCOPY); return width * sx; } Если преобразовать шрифтовой ресурс в один из растровых форматов, поддерживаемых GDI, мы сможем выводить символы самостоятельно, без применения текстовых функций GDI. На рис. 14.10 изображены глифы ресурса шрифта MS Sans Serif 8 и 10 пунктов для разрешения 96 dpi. D:\WINNT50\Fonts\SERIFE.FON 8 pts, 96x96 dpi, 0x13 pixel avgw 5, maxw 11, charset 0 !" tt$%8r'()x + .-- /0123456789: ;< = >? ©ABCDEFGHIJKLMN0PQRSTUVWXYZ[\] ~_ 4 abcdef ghi j k 1 minopqrstuvwxyz{| }~| I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I i С i * ¥ | §"©*«— ®~*±гэ'>М- . * ! » УаЫУаЬ kkklLkE^ltttX 1 i I DffDdOOcix0tJtrOu?t>B аааааааздёёёё! i i i И о 6 о о И в ii H ti j> t у 10 pts, 96x96 dpi, 0x16 pixel, avgw 6, maxw 14, charset 0 ! " # $ % h ' ( ) * + , - . / 0 1 2 3 A 5 6 7 8 9 : ; < = > ? ©ABCDEFGHI J KLMNOPQRSTUVWXYZ[ \ ] Л_ s abcdef ghi j kl mnopqr st u v w x у z { | } "I I I I I I I I I I I I I I I I [ I ' I I I I I I I I I I I I I i 0 i * 4 \ § " © * « - - ® * ± г * ' Ц 1 ■ , * ! » У*УгУ* i ААААААддЁЁЁЁ! i t I dn6606o=< 0HOutH aaaaaa«$eeeei i i i &поб6бмвййййу|)у Рис. 14.10. Глифы в растровом формате Из приведенного примера становится ясно, что же такое шрифт. Растровый шрифт в формате Windows 2.00 представляет собой набор шрифтовых ресурсов, разработанных для разных кеглей. Каждый шрифтовой ресурс состоит из монохромных растровых глифов, однозначно отображаемых на символы заданного однобайтового набора. Растровые шрифты поддерживают простое отображение символов набора в индексы глифов в интервале поддерживаемых символов. Глифы легко конвертируются в растровые форматы, поддерживаемые на уровне GDI, и выводятся на графических устройствах. В растровых шрифтах также хранятся простейшие текстовые метрики.
762 Глава 14. Шрифты Растровые шрифты хорошо подходят (как по качеству, так и по быстродействию) для вывода небольших символов на экран; в этом и состоит одна из причин, по которой они еще существуют. Для разных кеглей растровый шрифт должен содержать разные шрифтовые ресурсы. Например, растровые шрифты Windows обычно содержат ресурсы для кеглей 8, 10, 12, 14, 18 и 24 пункта. Для других кеглей или устройств с другим разрешением глифы приходится масштабировать по нужным размерам. Масштабирование растров всегда порождает проблемы, поскольку увеличение приводит к появлению новых пикселов. На рис. 14.11 показан результат масштабирования глифа растрового шрифта. лаА ааААА Рис. 14.11. Масштабирование глифа растрового шрифта В этом примере по обеим осям выполняется целочисленное масштабирование, то есть каждый пиксел глифа просто дублируется нужное количество раз. На рисунке четко видны возникающие дефекты. Масштабирование с дробным коэффициентом может привести к появлению черт разной толщины, поскольку одни пикселы будут дублироваться п раз, а другие — п + 1 раз. Конечно, масштабирование растровых шрифтов не позволяет добиться хорошего качества при выводе на экран и печати. Приходится искать другие способы кодировки шрифтов, обеспечивающие плавное масштабирование без дефектов. Векторные шрифты В растровых шрифтах глифы представляются растровыми изображениями и потому не могут нормально масштабироваться до больших размеров. В другом простом способе представления глиф описывается последовательностью линейных отрезков, которые затем рисуются при помощи пера. Такие шрифты называются векторными. В системе Windows векторные шрифты используют тот же формат шрифтовых ресурсов .fnt и структуру заголовка шрифта. В современных векторных шрифтах поле Version структуры FontHeader20 равно 0x100, а поле Туре равно 1. Главные различия между растровым и векторным шрифтами заключаются в формате данных глифа. В векторном шрифте каждый глиф описывается серией координат, начиная с точки (0,0). При небольших размерах сетки для хранения одной точки достаточно двух байт со знаком. Специальный маркер 0x80 сообщает о начале нового отрезка. Выражаясь более формально, описание векторного глифа в синтаксисе BNF выглядит следующим образом:
Векторные шрифты 763 <векторный_глиф> :: = <отрезок> { <отрезок> } <отрезок> ::= <маркер> { <отн_смещение> <отн_смещение> } <маркер> :: = 0x80 <отн_смещение> :; = <знаковый_байт> Располагая этой информацией, мы можем написать собственную функцию вывода глифов векторных шрифтов средствами GDI: int VectorCharOut(HDC hDC, int x, int y, int ch, const KFontHeader20 * pH. int sx=l, int sy=l) { typedef struct { short offset; short width; } VectorGlyph; const VectorGlyph * pGlyph = (const VectorGlyph *) ( (BYTE *) & pH->BitsOffset + 4); if ( (ch<pH->FirstChar) || (ch>pH->LastChar) ) ch = pH->DefaultChar; else ch -= pH->FirstChar; int width = pGlyph[ch].width; int length = pGlyph[ch+l].offset - pGlyph[ch].offset; signed char * pStroke - (signed char *) pH + pH->BitsOffset + pGlyph[ch].offset; int dx = 0; int dy = 0; while ( length>0 ) { bool move = false; if ( pStroke[0]==-128 ) { move = true; pStroke++; length --; } if ( (pStroke[0]==0) && (pStroke[l]«0) && (pStroke[2]==0) ) break; dx += pStroke[0]; dy += pStroke[l]; if ( move ) MoveToEx(hDC. x + dx*sx. у + dy*sy. NULL); else LineTo(hDC. x + dx*sx, у + dy*sy); pStroke +- 2; length -= 2; } return width * sx;
764 Глава 14. Шрифты В современных версиях ОС Windows используются три векторных шрифта: Roman, Script и Modern. Векторные шрифты обычно занимают меньше места, чем растровые, поскольку отрезки легко масштабируются и для них необходим всего один шрифтовой ресурс. На рис. 14.12 приведена первая половина глифов векторного шрифта Script. D:\WINNT50\Fonts\SCRIPT.FON 36 pts, 2x3 dpi, 0x37 pixel, avgw 17, / 0 1 @A (P£ i Cb p f maxw 33, charset 255 23^56789: ; < = > ? (В С £ £ & t КЗ § X £ МП G (%& и uv wxy $ [ \ ] - _ v- с d <ъ £ а, гь о I hi ггь гь о- *Ъ Л/ t Us О UJ- 00 f f \ I * r^j ♦ Рис. 14.12. Глифы векторного шрифта По сравнению с глифами растровых шрифтов, векторные глифы хорошо масштабируются, хотя с увеличением символа стыки между прямолинейными отрезками становятся все более заметными. На рис. 14.13 показан результат масштабирования глифа А. лА лЛЛЛЛ аЛ, Рис. 14.13. Масштабирование глифа векторного шрифта Толщина использованного на рисунке пера пропорциональна размеру глифа; в GDI глифы векторных шрифтов рисуются пером толщиной один пиксел. Хотя векторные шрифты повышает качество масштабирования при больших размерах символов, они все равно не позволяют выводить высококачественные глифы на графических устройствах высокого разрешения. Для качественного вывода текста применяются шрифты TrueType.
Шрифты TrueType 765 Шрифты TrueType До выхода Windows 3.0 в Windows поддерживались только растровые и векторные шрифты. При масштабировании растровых шрифтов возникали дефекты, а векторные шрифты были слишком тонкими, поэтому ни одна из этих технологий не обеспечивала качественного вывода текста при высоких разрешениях (особенно при печати на принтере). Компания Adobe, обладавшая глубокими технологическими разработками в области языка и шрифтов PostScript, запустила в мир Windows «чужеродное тело» — ATM (Adobe Type Manager). ATM хакерскими приемами вмешивается в работу Windows GDI и позволяет всем приложениям Windows работать с плавно масштабируемыми шрифтами. Рваные края и тонкие линии словно по волшебству заменились ровными, профессиональными глифами, которые одинаково выглядели на экране и на принтере. В Microsoft быстро уловили преимущества новых шрифтовых технологий и, начиная с Windows 3.1, в Windows была внедрена поддержка шрифтовой технологии TrueType компании Apple. В шрифтах TrueType контуры глифа определяются линиями и кривыми, что позволяет масштабировать их до произвольных размеров с сохранением формы глифа. Между шрифтами TrueType и векторными шрифтами существует два главных различия. Во-первых, кривые шрифтов TrueType при масштабировании остаются плавными, а в векторных шрифтах при больших размерах становятся видны пересечения отрезков. Во-вторых, в векторных шрифтах определяются линии, а в шрифтах TrueType определяются контуры глифа. Структура глифа значительно усовершенствуется, поэтому в шрифтах TrueType хранится дополнительная информация, обеспечивающая их преимущества перед старыми шрифтовыми технологиями Windows. Начнем с рассмотрения азов технологии TrueType. Формат файлов шрифтов TrueType Шрифт TrueType обычно хранится в одном файле с расширением .TTF. В операционной системе Windows недавно появилась поддержка шрифтов ОрепТуре, которые представляют собой шрифты PostScript, закодированные в формате, аналогичном TrueType. Файлы шрифтов ОрепТуре имеют расширение .OTF. Технология ОрепТуре также позволяет объединить несколько шрифтов ОрепТуре в один файл. Для таких шрифтов, называемых «коллекциями TrueType», используется расширение .ТТС. Шрифт TrueType кодируется в формате ресурсов контурных шрифтов Macintosh с уникальным тегом «sfnt». Формат ресурсов растровых шрифтов Macintosh (тег «NFNT») в Windows не используется. Шрифт TrueType начинается с небольшого шрифтового каталога с информацией о десятках таблиц, следующих за ним. Шрифтовой каталог содержит номер версии формата шрифта, количество таблиц и одну структуру TableEntry для каждой таблицы. В структуре TableEntry хранится тег ресурса, контрольная сумма, смещение и размер каждой таблицы. Ниже приведено определение шрифтового каталога TrueType на языке С. typedef structs { char tag[4];
766 Глава 14. Шрифты ULONG ULONG ULONG checksum; offset; length; } TableEntry; typedef struct 1 Fixed USHORT USHORT USHORT USHORT sfntversion: numTables; searchRange; entrySelector rangeShift; // 0x10000 для версии 1.0 Tableentry entries[l]; // Переменное количество TableEntry } TableDirectory; Многие программисты Windows даже не знают о том, что шрифты TrueType первоначально разрабатывались компанией Apple для операционных систем, работающих на процессорах Motorola вместо Intel. Во всех данных шрифтов TrueType используется кодировка, при которой старший байт стоит на первом месте. Если шрифт TrueType начинается с 00 01 00 00 00 17, мы знаем, что перед нами ресурс контурного шрифта («sfnt») в формате версии 1.0 с 23 таблицами. В последнем поле структуры TableDi rectory хранится массив структур TableEntry переменной длины, по одной структуре для каждой таблицы в шрифте. Каждая таблица шрифта TrueType содержит логически обособленную информацию — например, данные глифа, отображение символов на глифы, данные кернинга и т. д. Одни таблицы необходимы, присутствие других не обязательно. В табл. 14.3 перечислены самые распространенные таблицы, встречающиеся в шрифтах TrueType. Таблица 14.3. Основные таблицы шрифтов TrueType Тег Название Описание head Заголовок шрифта Глобальная информация о шрифте стар Таблица соответствия между Отображение кодов символов в индексы кодами символов и глифами глифов glyf Таблица глифов Определение контура глифа и инструкции по его размещению в сетке тахр Максимальный профиль Сводные данные шрифта для выделения памяти mmtx Горизонтальные метрики Горизонтальные метрики глифа loca Индексная таблица Преобразование индекса глифа в смещение данных в таблице глифов name Таблица имен Информация об авторских правах, имя шрифта, имя семейства, стиль и т. д. hhea Горизонтальная структура Горизонтальная структура глифов: надстрочный интервал, подстрочный интервал и т. д.
Шрифты TrueType 767 Тег hmtx kern post PCLT OS/2 Название Горизонтальные метрики Таблица кернинга Данные PostScript Данные PCL 5 Метрики, специфические для OS/2 и Windows Описание Полная ширина и левый отступ Массив кернинговых пар Элемент таблицы PostScript Fontlnfo и имена PostScript для всех глифов Данные шрифта для языка принтеров HP PCL 5: номер шрифта, шаг, стиль и т. д. Обязательный набор метрик для шрифта TrueType Все структуры TableEntry в структуре Tab! eDi rectory должны быть отсортированы по именам тегов. Например, структура «стар» должна предшествовать «head», а последняя, в свою очередь, должна располагаться перед структурой «glyf». Расположение самих таблиц в файле шрифта TrueType может быть произвольным. В Win32 API существует функция, при помощи которой приложение может запросить данные шрифта TrueType: DWORD GetFontData(HDC hDC, DWORD dwTable, DWORD dwOffset. LPVOID IpvBuffer, DWORD cbData); Функция GetFontData возвращает информации о шрифте TrueType, соответствующем текущему логическому шрифту, выбранном в контексте устройства, поэтому вместо манипулятора логического шрифта ей передается манипулятор контекста устройства. Вы можете запросить информацию либо обо всем файле TrueType, либо об одной из его таблиц. Чтобы запросить информацию обо всем файле, передайте 0 в параметре dwTable; для получения информации об одной таблице передается ее тег, состоящий из 4 символов, в формате DWORD. Параметр dwOffset содержит начальное смещение таблицы или 0 для всего файла. В параметре IpvBuffer передается адрес, а в параметре cbData — размер буфера. Если в двух последних параметрах передаются NULL и 0, GetFontData возвращает размер шрифтового файла или таблицы; в противном случае данные копируются в буфер, предоставленный приложением. Следующая функция запрашивает служебные данные шрифта TrueType: TableDirectory * GetTrueTypeFont(HDC hDC, DWORD & nFontSize) { // Запросить размер шрифта nFontSize = GetFontData(hDC. 0. 0. NULL. 0); TableDirectory * pFont = (TableDirectory *) new BYTE[nFontSize]; if ( pFont==NULL ) return NULL; GetFontData(hDC. 0. 0. pFont. nFontSize); return pFont; }
768 Глава 14. Шрифты Функция GetFontData ориентирована на приложения, внедряющие шрифты TrueType в свои документы, чтобы их можно было прочитать на другом компьютере, где данный шрифт может отсутствовать. Предполагается, что приложение запрашивает данные шрифта, сохраняет их в составе документа и устанавливает шрифт при открытии документа. В результате документ выглядит так же, как и на том компьютере, где он был создан. Например, спулер Windows NT/ 2000 при печати на сервере внедряет шрифты TrueType в спулинговые файлы, чтобы документ был правильно напечатан на другом компьютере. После получения служебных данных шрифта TrueType анализ заголовочной структуры TableDi rectory не вызовет никаких проблем. Достаточно проверить версию и количество таблиц, после чего можно переходить к проверке отдельных таблиц. Мы рассмотрим самые важные и интересные таблицы. Заголовок шрифта Заголовок шрифта (таблица «head») содержит глобальную информацию о шрифте TrueType. Определение структуры заголовка приведено ниже. typedef struct { Fixed Table; // 0x00010000 для версии 1.0 Fixed fontRevision; // Задается разработчиком шрифта ULONG checkSumAdjustment; ULONG magicNumber; // Равно 0x5F0F3CF5 USH0RT unitsPerEm; // Интервал допустимых значений 16..16384 longDT created; // Дата в международном формате (8 бит) longDT modified; // Дата в международном формате (8 бит) FWord xMin; // Для всех ограничивающих блоков глифов FWord yMin; // Для всех ограничивающих блоков глифов FWord xMax; // Для всех ограничивающих блоков глифов FWord yMax; // Для всех ограничивающих блоков глифов USH0RT macStyle; USH0RT lowestRecPPEM; // Минимальный читаемый размер в пикселах SHORT fontDirecti onHi nt; SHORT indexToLocFormat; // 0 - короткое смещение, 1 - длинное SHORT glyphDataFormat; // 0 для текущего формата } Tablejiead; История шрифта (номер версии, даты создания и последней модификации) хранится в трех полях. Даты хранятся в 8-байтовых полях в виде количества секунд, прошедших с полуночи 1 января 1904 года, поэтому нам никогда не придется беспокоиться о «проблеме Y2K» (и даже «проблеме Y2M»). Шрифт конструируется на эталонной сетке, называемой em-квадратом; глифы шрифта описываются координатами этой сетки. Следовательно, размер эталонной сетки влияет на масштабирование шрифта и его качество. В заголовке шрифта хранятся размеры em-квадрата и данные ограничивающих блоков всех глифов. Размеры em-квадрата могут лежать в интервале от 16 до 16 384, хотя обычно используются значения 2048, 4096 и 8192. Например, для шрифта Wing- ding размер em-квадрата равен 2048, а ограничивающий блок глифа описывается четверкой [0,-432, 2783,1841].
Шрифты TrueType 769 Среди других данных в таблице заголовка шрифта хранится минимальный читаемый размер шрифта в пикселах, хинт направления шрифта, индекс глифа в формате индексной таблицы, формат данных глифа и т. д. Максимальный профиль Шрифт TrueType обладает весьма динамичной структурой. Он может содержать переменное количество глифов, описываемых разным количеством контрольных точек, и неизвестное количество инструкций. Таблица максимального профиля (таблица «тахр») содержит данные о затратах памяти на растеризацию шрифтов, чтобы перед использованием шрифта можно было выделить достаточный объем памяти. Поскольку при растеризации шрифтов важнейшим фактором является быстродействие, динамические структуры вроде массива САггау MFC, нуждающиеся в частом копировании данных, для этого не подходят. Ниже приведена структура, описывающая максимальный профиль шрифта. typedef struct { Fixed Version; // 0x00010000 для версии 1.0 USHORT numGlyphs; // Количество глифов в шрифте USHORT maxPoints; // Макс.кол-во точек в простом глифе USHORT maxContours; // Макс.кол-во контуров в простом глифе USHORT maxCompositePoints; // Макс.кол-во точек в составном глифе USHORT maxCompositeContours; // Макс.кол-во контуров в составном глифе USHORT maxZones: USHORT maxTwilightPoints; USHORT maxStorage; // Количество блоков хранения данных USHORT maxFunctionDefs; // Количество FDEF USHORT maxInstructionDefs; // Количество IDEF USHORT maxStackElements; // Максимальная глубина стека USHORT maxSizeOflnstructions; // Макс.байт в инструкциях глифа USHORT maxComponentElements; // Макс.кол-во компонентов верхнего уровня USHORT maxComponentDepth; // Максимальная глубина рекурсии } Tablejnaxp; В поле numGlyphs хранится общее количество глифов в шрифте, определяющее размер индекса глифа в индексной таблице, а также используемое для проверки индексов. Глифы шрифтов TrueType делятся на составные (composite) и простые (noncomposite). Простой глиф состоит из одного или нескольких контуров, каждый из которых определяется несколькими контрольными точками. Составной глиф определяется как результат объединения других глифов. В полях maxPoints, maxContours, maxCompositePoints и maxCompositeContours хранятся данные о сложности определений глифов. Помимо определений глифов, в шрифтах TrueType используются инструкции для растеризации шрифтов. Инструкции регулируют положение контрольных точек, чтобы растеризованные глифы были сбалансированными и хорошо выглядели. Инструкции глифов также могут храниться на глобальном уровне в программной таблице шрифта («fpgm») и в программной таблице контрольных величин («prep»). Инструкции глифов TrueType пишутся на байт-коде стековой псевдомашины (вроде виртуальной машины Java). Поля maxStackElements
770 Глава 14. Шрифты и maxSizeOflnstructions сообщают стековой машине степень сложности этих инструкций. Пример: шрифт Wingding содержит 226 глифов, максимальное количество контуров в глифе равно 47, а максимальное количество точек в простом глифе равно 268. Составные глифы содержат до 141 точки и 14 контуров. В худшем случае для вывода потребуется 492 уровня в стеке, а самая длинная инструкция состоит из 1119 байт. Отображение символов в индексы глифов Таблица отображения символов в глифы (таблица «стар») определяет соответствие между символами разных кодовых страниц и индексом глифа — ключевой характеристикой для получения информации о глифе в шрифте TrueType. Таблица «стар» может состоять из нескольких подтаблиц для поддержки разных платформ и кодировок символов. Ниже приведено описание структуры таблицы «стар». typedef struct { USHORT Platform; // Идентификатор платформы USHORT EncodinglD; // Идентификатор кодировки ULONG TableOffset; // Смещение таблицы кодировки } submap; typedef struct { USHORT TableVersion; // Версия О USHORT NumSubTable; // Количество таблиц кодировки submap TableHead[l]; // Заголовки таблиц кодировки } Table_cmap; typedef struct { USHORT format; // Формат: О. 2. 4. 6 USHORT length: // Размер USHORT version: // Версия BYTE map[l]; // Данные отображения } Table_Encode; Таблица «стар» (структура Tab1e_cmap) начинается с номера версии, количества подтаблиц и заголовков всех подтаблиц. Каждая подтаблица (структура submap) содержит идентификатор платформы, идентификатор кодировки и смещение данных подтаблицы для заданной платформы и кодировки. В операционных системах Microsoft идентификатор платформы равен 3, а рекомендуемый идентификатор кодировки равен 1 (Unicode). Существуют и другие идентификаторы кодировок — 0 для кодировки Symbol, 2 для Shift-JIS (Japanese Industrial Standard), 3 для Big5 (китайский, традиционное письмо), 4 для PRC (китайский, упрощенное письмо) и т. д. Собственно таблица кодировки (TableJEncode) начинается с полей формата, длины и версии, за которыми следуют данные отображения. В настоящее время определены четыре разных формата таблицы. Формат 0 используется для про-
Шрифты TrueType 771 стой кодировки, позволяющей отображать до 256 символов. В формате 2 используется 8/16-разрядная кодировка для японского, китайского и корейского языков. Формат 4 является стандартным для систем Microsoft. Формат определяет усеченное табличное отображение. Типичный шрифт TrueType, используемый в Windows, содержит две таблицы кодировки — однобайтовую таблицу формата 0 для отображения символов ANSI на индексы глифов и таблицу формата 4 для отображения символов Unicode на индексы глифов. С концептуальной точки зрения таблица отображения представляет собой простую структуру данных, устанавливающую соответствие между парами целых чисел, однако формат 4 слишком сложен, чтобы его можно было описать в нескольких абзацах. При отображении кода символа на индекс глифа по таблице отсутствующие символы отображаются на специальный глиф с индексом 0. Таблица «стар» обычно остается скрытой от приложения, если только вы не захотите получить ее данные функцией GetFontData. В Windows 2000 появились две новые функции, упрощающие доступ к этой информации в приложениях. typedef struct { WCHAR wcLow; USHORT cGlyphs; } typedef struct { DWORD cbThis; // sizeof(GLYPHSET) + sizeof(WCRANGE) * (cRanges-1) DWORD flAccel; DWORD cGlyphsSupported; DWORD cRanges; WCRANGE ranges[l]; // ranges[cRanges]; } GLYPHSET; DWORD GetFontUnicodeRanges(HDC hDC, LPGLYPHSET Ipgs); DWORD GetGlyphlndicesCHDC hDC. LPCTSTR lpstr. int c. LPWORD pgi. DWORD f1); Обычно шрифт содержит глифы лишь для некоторого подмножества символов кодировки Unicode, причем эти символы могут группироваться по интервалам. Функция GetFontUnicodeRanges заносит в структуру GLYPHSET количество поддерживаемых глифов, количество интервалов Unicode и дополнительную информацию об интервалах для текущего шрифта, выбранного в контексте устройства. Структура GLYPHSET имеет переменный размер, зависящий от количества поддерживаемых интервалов Unicode, поэтому функция GetFontUnicodeRanges (как и другие функции Win32 API, поддерживающие структуры переменного размера) обычно вызывается дважды. При первом вызове в последнем параметре передается указатель NULL; GDI возвращает фактический размер структуры. Вызывающая сторона выделяет блок нужного размера и снова вызывает функцию для получения данных. В обоих случаях функция GetFontUnicodeRanges возвращает размер блока, необходимого для хранения всей структуры. В MSDN
772 Глава 14. Шрифты утверждается, что если второй параметр равен NULL, функция GetFontUnicodeTanges возвращает указатель на структуру GLYPHSET. Следующая функция возвращает структуру GLYPHSET для текущего шрифта в контексте устройства. GLYPHSET *QueryUnicodeRanges(HDC hDC) { // Запросить размер DWORD size = GetFontUnicodeRanges(hDC, NULL); if (size==0) return NULL; GLYPHSET * pGlyphSet = (GLYPHSET *) new Byte[size]; // Получить данные pGlyphSet->cbThis = size; size = GetFontUnicodeRanges(hDC. pGlyphSet); return pGlyphSet: } Если вызвать функцию GetFontUnicodeRanges для некоторых шрифтов TrueType системы Windows, выясняется, что эти шрифты часто поддерживают свыше тысячи глифов, сгруппированных по сотням интервалов Unicode. Например, шрифт Times New Roman содержит 1143 глифа в 145 интервалах, первым из которых является интервал 7-разрядных печатных ASCII-кодов 0x20..0x7F. Функция GetFontUnicodeRanges использует лишь часть данных о шрифте TrueType, хранящихся в таблице «стар», — а именно общие сведения об отображении символов Unicode в индексы глифов. Функция GetGlyph Indices выполняет непосредственное преобразование текстовой строки в массив индексов глифов. Она получает манипулятор контекста устройства, указатель на строку, длину строки, указатель на массив WORD и флаг. В массиве WORD сохраняются сгенерированные индексы глифов. Если флаг равен CGIMASKNONEXISTINGGLYPHS, отсутствующие символы заменяются индексом OxFFFF. Индексы глифов, сгенерированные этой функцией, могут передаваться другим функциям GDI — например, функции ExtTextOut. Индексная таблица Конечно, самые важные данные в файле шрифта TrueType хранятся в таблице глифов («glyf»). Для преобразования индекса глифа в смещение данных глифа в таблице используется индексная таблица (таблица «loca»). Индексная таблица содержит п + 1 смещений в таблице глифов, где п — количество глифов, хранящееся в таблице максимального профиля. Дополнительное смещение в конце указывает не на новый глиф, а на конец последнего глифа. Такая структура позволяет шрифтам TrueType обойтись без сохранения длины каждого глифа в шрифте. Вместо этого растеризатор шрифтов вычисляет длину глифа как разность смещений текущего и следующего глифа. Индексы в индексной таблице хранятся в формате unsigned short или unsigned long в зависимости от значения поля indexToLocFormat заголовка шрифта. Глиф должен выравниваться по границе unsigned short; при использовании короткого
Шрифты TrueType 773 формата смещение хранится в таблице в формате WORD вместо BYTE. Это позволяет короткой форме индексной таблицы поддерживать таблицу данных глифов размером до 128 Кбайт. Данные глифов Таблица глифов (таблица «glyf») содержит самую важную информацию во всем шрифте TrueType, поэтому обычно она имеет наибольший размер. Поскольку данные о соответствии между индексами и глифами хранятся в отдельной таблице, таблица данных глифов не содержит ничего, кроме последовательности глифов, каждый из которых начинается со структуры заголовка глифа. typedef struct { WORD numberOfContours: // Число контуров; <0 для составных глифов Fword xMin; // Минимальное значение х для координат Fword yMin; // Минимальное значение у для координат Fword xMax; // Максимальное значение х для координат Fword yMax; // Максимальное значение у для координат } GlyphHeader; Для простых (не составных) глифов поле numberOfContours содержит количество контуров в текущем глифе; для составных глифов поле numberOfContours отрицательно. В последнем случае общее количество контуров вычисляется по данным всех глифов, образующих составной глиф. В следующих четырех полях структуры GlyphHeader хранится ограничивающий блок глифа. Для простых глифов за структурой GlyphHeader следует описание глифа. Описание состоит из нескольких значений: индексов конечных точек всех контуров, инструкций и последовательности контрольных точек. Для каждой контрольной точки указываются координаты (х,у) и флаг. Теоретически для задания контрольных точек достаточно той же информации, что и для функции PolyDraw GDI: массива флагов и массива координат. Впрочем, в шрифтах TrueType контрольные точки кодируются весьма изощренным способом. Ниже приведено обобщенное описание глифа. USH0RT USH0RT BYTE BYTE BYTE BYTE endPtsOfContoursCn]: instructionlength; instruction[i]; flags[]; xCoordinates[]; yCoordinates[]; // n = количество контуров // i = длина инструкции // переменный размер // переменный размер // переменный размер Глиф может содержать один или несколько контуров. Например, буква «о» содержит два контура, внутренний и наружный. Для каждого контура в массиве endPtsOfContours хранится индекс конечной точки, по которому вычисляется количество точек в контуре. Например, endPtsOfContours[0] — количество точек в первом контуре, a (endPtsOfContours[l] - endPtsOfContours[0]) — количество точек во втором контуре. За массивом конечных точек следует длина инструкции глифа и массив инструкций. Впрочем, мы сначала разберемся с контрольными точками. Контрольные точки глифа хранятся в трех массивах: флагов, координат х и координат у. Начало массива флагов находится просто, однако не существует ни поля разме-
774 Глава 14. Шрифты pa массива флагов, ни прямых ссылок на два других массива. Чтобы найти массивы координат и разобраться с ними, вам придется декодировать массив флагов. Выше уже упоминалось, что максимальный размер em-квадрата равен 16 384 единицам, поэтому обычно каждая из координат х и у представляется двумя байтами. Для экономии места (а это главная причина для выбора этого способа кодировки) в описании глифа хранятся относительные координаты. Координаты первой точки задаются относительно (0,0); для всех остальных точек хранятся смещения относительно предыдущей точки. У одних точек эти смещения оказываются достаточно малыми, что позволяет представить их одним байтом; у других точек они равны 0, а у третьих они не помещаются в одном байте. В массиве флагов хранится информация о кодировке отдельных точек в сочетании с другой информацией. Ниже показано, как интерпретируются отдельные биты флагов. typedef enum G ONCURVE G_REPEAT G XMASK G XADDBYTE G XSUBBYTE G XSAME GJADDINT G YMASK G YADDBYTE G YSUBBYTE G YSAME - 0x01, - 0x08. - 0x12, - 0x12. - 0x02. - 0x10. - 0x00. - 0x24. - 0x24. - 0x04. - 0x20. G YADDINT - 0x00. // На кривой или вне кривой // Следующий байт содержит счетчик повторений // X - положительный байт // X - отрицательный байт // X совпадает с прежним значением // X - слово со знаком // Y - положительный байт // Y - отрицательный байт // Y совпадает с прежним значением // Y - слово со знаком }: В главе 8, посвященной линиям и кривым, упоминалось, что сегмент кубической кривой Безье определяется четырьмя точками: начальной точкой кривой, двумя контрольными точками, лежащими за пределами кривой, и конечной точкой кривой. Контур глифа в шрифте TrueType описывается кривой Безье второго порядка, определяемой двумя концами кривой и одной контрольной точкой. Несколько контрольных точек могут стоять подряд — не для того, чтобы определить кубическую или другую кривую Безье более высокого порядка, а просто для сокращения количества контрольных точек. Например, в последовательность четырех точек «точка кривой — контрольная — контрольная — точка кривой» между двумя контрольными точками неявно добавляется еще одна точка кривой, в результате чего данная последовательность определяет два сегмента кривых Безье второго порядка. Если бит G_0NCURVE установлен, точка находится на кривой; в противном случае она является контрольной точкой, лежащей за пределами кривой. Если установлен бит G_REPEAT, следующий байт массива флагов содержит счетчик повторений, а текущий флаг повторяется заданное количество раз (некая разновидность сжатия RLE в массиве флагов). Остальные биты флагов описывают кодировку соответствующих координат х,у; они показывают, совпадает ли относительная координата с предыдущей, кодируется ли положительным или отрицательным байтом или же требует двухбайтовой величины со знаком.
Шрифты TrueType 775 Описание глифа расшифровывается за два прохода. На первом проходе мы перебираем массив флагов, находим его конец и определяем длину массива координат х; в результате определяются начальные точки массивов х и у. На втором проходе мы перебираем каждую точку определения глифа и преобразуем ее к более удобному формату. В листинге 14.2 приведена функция расшифровки глифа TrueType, оформленная в виде метода класса TrueType. Листинг 14,2, KTrueType::DecodeGlyph: расшифровка простого глифа int «TrueType::Decodedyphdnt index, «Curve & curve. XFORM * xm) const { const GlyphHeader * pHeader = GetGlyph(index); if ( pHeader—NULL ) return 0; intnContour - (short) reverse(pHeader->numberOfContours); if ( nContourO ) // Составной глиф f return DecodeCompositeGlyph(pHeader+l. curve); // После заголовка if ( nContour==0 ) return 0; curve.SetBound(reverse((WORD)pHeader->xMin), reverse((WORD)pHeader->yMin), reverse((WORD)pHeader->xMax), reverse((WORD)pHeader->yMax)); const USHORT * pEndPoint - (const USHORT *) (pHeader+1); // Всего точек: конец последнего контура + 1 int nPoints = reverse(pEndPoint[nContour-l]) + 1; // Длина инструкций int nlnst = reverse(pEndPoint[nContour]); // Массив флагов: после массива инструкций const BYTE * pFlag - (const BYTE *) & pEndPoint[nContour] + 2 + nlnst; const BYTE * pX = pFlag; int xlen = 0; // Проанализировать массив флагов для определения // начальной позиции и размера массива координат х for (int i=0: i<nPoints; i++. pX++) { int unit = 0; switch ( pX[0] & GJMASK ) { case GJADDBYTE: case GJSUBBYTE: unit = 1: Продолжение^
776 Глава 14. Шрифты Листинг 14.2. Продолжение break; case GJADDINT: unit = 2; } if ( pX[0] & G_REPEAT ) { xlen += unit * (pX[l]+l): i += pX[l]; pX ++: } else xlen += unit; } const BYTE * pY = pX + xlen;// Массив координат у следует // после массива координат х int х = 0; int у = 0; i = 0; BYTE flag - 0; int rep =0; // Одновременный перебор всех трех массивов for (int j=0; j<nContour; j++) // По одному контуру { int limit = reverse(pEndPoint[j]); while ( i<=limit ) { if ( rep==0 ) { flag = * pFlag++; rep = 1; if ( flag & G_REPEAT ) rep += * pFlag ++; } int dx = 0, dy = 0; switch ( flag & GJMASK ) { case GJADDBYTE: dx - pX[0]: pX ++; break; case GJSUBBYTE; dx = - pX[0]; pX ++; break; case GJADDINT; dx - (short )( (pX[0] « 8) + pX[l]); pX+=2; } switch ( flag & GJMASK ) {
Шрифты TrueType 777 case GJADDBYTE case G_YSUBBYTE case GJADDINT: pY+=2; } x += dx; У += dy; assert(abs(x)<16384); assert(abs(y)<16384); if ( xm ) // Применить преобразование, если оно задано curve.Add((int) ( х * xm->eMll + у * xm->eM21 + xm->eDx ), (int) ( x * xm->eM12 + у * xm->eM22 + xm->eDy ), (flag & G_0NCURVE) ? KCurve::FLAG_0N : 0); else curve.Add(x, y. (flag & GJJNCURVE) ? KCurve::FLAG_0N : 0); rep --: i ++; } curve. CloseO; } return curve.GetLengthO; } Класс KTrueType загружает и расшифровывает шрифты TrueType; его полный код находится на прилагаемом компакт-диске. Метод DecodeGlyph выполняет расшифровку одного глифа по индексу и необязательной матрице преобразования. Параметр класса KCurve предназначен для сбора определения глифа в простой 32-разрядный массив точек и простой массив флагов, которые затем легко выводятся средствами GDI. На основе этого метода даже можно построить простейший редактор шрифтов TrueType. Программа вызывает метод GetGlyph, который по индексной таблице находит структуру GlyphHeader заданного глифа. Из таблицы извлекается количество контуров в глифе. Обратите внимание на перестановку байтов в полученной величине, связанную с обратным порядком следования байтов в шрифтах TrueType. Если значение отрицательно (признак составного глифа), вызывается метод DecodeCompositeGlyph. Затем программа находит массив endPtsOfContours, определяет общее количество точек и пропускает инструкции, переходя к началу массива флагов. Теперь мы должны определить начальную точку массива координат х и длину массива однократным перебором массива флагов. Каждая точка может занимать в массиве координат от 0 до 2 байт в зависимости от того, представляется ли ее относительное смещение 0, одно- или двухбайтовой величиной. По адресу и длине массива координат х определяется адрес массива координат у. Затем программа последовательно перебирает все контуры, расшифровывает данные всех точек, преобразует относительные координаты в абсолютные и затем прибавляет точку к объекту кривой, применяя к ней преобразование (если оно было задано). dy = pY[0]: pY ++; break; dy = - pY[0]; pY ++; break; dy = (short )( (pY[0] « 8) + pY[l]);
778 Глава 14. Шрифты Как говорилось выше, в шрифтах TrueType используются кривые Безье второго порядка, причем между двумя точками кривой может находиться несколько контрольных точек. Чтобы упростить алгоритм вывода кривой, метод KCurve: :Add добавляет лишнюю точку кривой между каждой парой контрольных точек. void AddCint x. int у, BYTE flag) { if ( mjen && ( (flag & FLAG_ON)==0 ) && ( CmJlagOnJen-l] & FLAG__ON)==0 ) ) { Append((m_Point[mJen-l].x+x)/2, (m_Point[mJen-l].y+y)/2. FLAG_0N | FLAGJEXTRA); // Добавить промежуточную точку } Append(x, у. flag); } Разобравшись с простыми глифами, перейдем к составным. Составной глиф определяется последовательностью преобразованных глифов. Каждое определение преобразованного глифа состоит из трех частей: флагов, индекса глифа и матрицы преобразования. Поле флагов описывает кодировку матрицы преобразования (также спроектированную для экономии памяти), а также содержит признак конца последовательности. Полное двумерное аффинное преобразование определяется шестью величинами. Впрочем, для простого смещения достаточно всего двух величин (dx, dy), которые могут храниться в двух байтах или двух словах. Если одновременно со смещением значения хиу масштабируются в одинаковой пропорции, коэффициент масштабирования можно хранить всего в одном экземпляре. В общем случае используются все шесть величин, но в большинстве конкретных ситуаций несколько байт удается сэкономить. Параметры преобразования хранятся в формате 2.14 с фиксированной точкой; исключением являются параметры dx и dy, хранящиеся в виде целых чисел. Составной глиф строится объединением нескольких глифов, каждому из которых сопоставляется матрица преобразования. Например, если глиф представляет собой точное зеркальное отражение другого глифа, он может быть определен как составной глиф, сгенерированный в результате применения зеркального отражения к другому глифу. В листинге 14.3 приведен код расшифровки составных глифов. Листинг 14.3. KTrueType::DecodeCompositeGlyph int «TrueType::DecodeCompositeGlyph(const void * pGlyph, KCurve & curve) const { KDataStream str(pGlyph); unsigned flags; int 1 en - 0; do { flags * str.GetWordO; unsigned glyphlndex - str.GetWordO;
Шрифты TrueType 779 signed short argumenti; signed short argument2; if ( flags & ARG_1_AND_2_ARE_W0RDS ) { argumenti - str.GetWordO; // (SHORT or FWord) argumenti; argument2 - str.GetWordO; // (SHORT or FWord) argument2; } else { argumenti - (signed char) str.GetByteO; argument2 - (signed char) str.GetByteO: } signed short xscale, yscale, scaled. scalelO; xscale - 1; yscale - 1; scaleOl - 0; scalelO - 0; if ( flags & WE_HAVE_A_SCALE ) { xscale - str.GetWordO; yscale - xscale; // Формат 2.14 } else if ( flags & WE_HAVE_AN_X_AND_Y_SCALE ) { xscale - str.GetWordO; yscale - str.GetWordO; } else if ( flags & WE_HAVE_A_M)_BY_TWO ) { xscale - str.GetWordO; scaleOl - str.GetWordO; scalelO - str.GetWordO; yscale « str.GetWordO; if ( flags & ARGS_ARE_XY VALUES ) { XFORM xm; xm.eDx - (float) argumenti; xm.eDy - (float) argument2; xm.eMll - xscale / (float) 16384.0; xm.eM12 - scaleOl / (float) 16384.0; xm.eM21 - scalelO / (float) 16384.0; xm.eM22 - yscale / (float) 16384.0; len +« DecodeGlyph(glyphIndex, curve, & xm); } else assert(false); Продолжение £
780 Глава 14. Шрифты Листинг 14,3, Продолжение while ( flags & MORE_COMPONENTS ); if ( flags & WE_HAVE_INSTRUCTIONS ) // Пропустить инструкции { unsigned numlnstr = str.GetWordO: for (unsigned i=0: i<numlnstr; i++) str.GetByteO; } return Ten; } Метод DecodeCompositeGlyph получает флаги, индекс глифа и матрицу преобразования для каждого глифа, входящего в составной глиф, и расшифровывает глиф при помощи метода DecodeGlyph. Обратите внимание на передачу матрицы преобразования при вызове DecodeGlyph. Метод завершает работу, обнаружив сброшенный флаг M0REC0MP0NENTS. Полный код находится на прилагаемом компакт- диске. Расшифрованные глифы шрифтов TrueType можно было бы легко вывести средствами GDI, если бы не одна маленькая проблема. GDI рисует только кубические кривые Безье, поэтому контрольные точки кривых Безье второго порядка, полученные из таблицы глифов, необходимо преобразовать в контрольные точки кубических кривых Безье. Немного повозившись с исходным математическим определением кривых Безье, мы приходим к простой функции вывода кривых Безье второго порядка средствами GDI: // Вывод сегмента кривой Безье 2-го порядка BOOL Bezier2(HDC hDC. int & xO. int & yO. int xl. int yl, int x2. int y2) { // pO pi p2 -> pO (p0+2pl)/3 (2pl+p2)/3. p2 POINT P[3] - { { (x0+2*xl)/3. (y0+2*yl)/3 }, { (2*xl+x2)/3. (2*yl+y2)/3 }, { x2. У2 } }; xO « x2; yO = y2; return PolyBezierTo(hDC.P.3); } Для кривой Безье второго порядка, определяемой тремя точками (р0, ри р2), соответствующие точки кубической кривой Безье вычисляются по формулам (Ро> (Ро +2 х Pl)/3, (2 х Pl + р2)/3, р2). На рис. 14.14 показан результат применения кода, реализованного в классе KCurve. На заднем плане изображен em-квадрат, разделенный сеткой на 16 частей по обеим осям. Прямоугольник представляет ограничивающий блок глифа, в данном примере — символа @. Точки обозначены маленькими кружками. Как видно из рисунка, точки на линии чередуются с контрольными точками. Но самое важное — то, что построенные кривые соответствуют контуру, определяемому сложным описанием шрифта.
Шрифты TrueType 781 Рис. 14.14. Описание глифа TrueType Инструкции глифа При просмотре листингов 14.2 и 14.3 может возникнуть впечатление, что растеризатор шрифтов TrueType легко реализуется преобразованием контуров глифов — скажем, заполнением траектории, которая создается при выводе контуров, функцией GDI StrokeFinAndPath. Такой примитивный растеризатор шрифтов вряд ли принесет какую-нибудь практическую пользу, разве что на устройствах высокого разрешения (например, на принтерах). Рисунок 14.15 поможет вам убедиться в этом. Рис. 14.15. Растеризация глифов На рисунке сравниваются два варианта растеризации глифов TrueType: простейший растеризатор из листингов 14.2 и 14.3 и настоящий механизм растери-
782 Глава 14. Шрифты зации глифов для шрифтов TrueType операционных систем Microsoft. Сверху показан результат применения простейшего растеризатора, а снизу — то, что реализует ОС. Результаты приведены как в исходном размере, так и в увеличении. В правой части рисунка изображены контуры глифов TrueType, аппроксимируемые обеими реализациями. Как видно из рисунка, простейший растеризатор создает изображения с разной толщиной линий, выпадением пикселов, потерей элементов изображения, утратой симметрии и т. д. При уменьшении кегля результат становится еще хуже. Масштабирование контура глифа, определенного на большом em-квадрате (обычно 2048 единиц), в сетку меньшего размера (скажем, 32 х 32) неизбежно приводит к потере точности и появлению ошибок. Допустим, в единицах em- квадрата определяются две вертикальные черты с ограничивающими блоками [14,0,25,200] и [31,0,42,200]; обе черты обладают одинаковыми размерами Их 200. Все выглядит замечательно, но давайте попробуем уменьшить изображение 10 раз с округлением. Первая черта масштабируется в блок [1,0,3,20], а вторая — в блок [3,0,4,20]. Обратите внимание: размеры первой черты теперь равны 2 х 20, а размеры второй — 1 х 20. Именно так возникают черты разной толщины. Посмотрите на рисунок — нижняя черта буквы В толще средней и верхней. В технологии TrueType проблемы растеризации решаются путем управления масштабированием контура из сетки em-квадрата в итоговую сетку, чтобы результат лучше выглядел и сохранял сходство с исходным дизайном глифа. Эта методика, называемая подгонкой по сетке, имеет три основные цели. О Устранение случайных зависимостей от расположения контуров в сетке, чтобы при растеризации одинаковая толщина линий сохранялась независимо от их расположения в сетке. О Сохранение ключевых размеров внутри одного глифа и между разными глифами. О Сохранение симметрии и других важных аспектов глифа (например, засечек). Соответствующие требования для шрифта TrueType кодируются в двух местах: в таблице контрольных величин и в инструкциях подгонки по сетке, задаваемых на уровне отдельных глифов. Таблица контрольных величин («cvt») предназначена для хранения массива, элементы которого могут использоваться в инструкциях. Например, для шрифта с засечками в числе контролируемых параметров могут быть высота засечки, ширина засечки, толщина черт прописной буквы и т. д. Эти значения заносятся в таблицу контрольных величин в порядке, известном разработчику шрифта, и позднее инструкции ссылаются на них по индексам. В процессе растеризации шрифтов значения таблицы контрольных величин масштабируются в соответствии с текущим кеглем. Использование масштабированных величин в инструкциях гарантирует, что будут применяться одни и те же значения независимо от их относительной позиции в сетке. Например, если горизонтальную черту [14,0,25,200] задать в виде [14,0,14+CVT[stem_width],0+CVT[stem_height]] с использованием двух значений из таблицы CVT, то ширина и высота останутся постоянными при любом расположении линии в сетке. С каждым определением глифа связывается серия инструкций, называемых инструкциями глифа и управляющих подгонкой глифа по сетке. Ссылки на па-
Шрифты TrueType 783 раметры из контрольной таблицы в инструкциях глифов гарантируют, что эти параметры будут выдерживаться во всех глифах. Инструкции глифов предназначены для стековой псевдомашины. Стековая машина широко используется в интерпретируемых средах из-за простоты своей реализации. В частности, Forth (простой и мощный язык встраиваемых систем), RPL (язык научных калькуляторов HP) и виртуальная машина Java построены на базе стековых машин. Стековая машина обычно не имеет регистров, поскольку все вычисления производятся в стеке (у некоторых стековых машин контрольный стек отделен от стека данных). Например, инструкция PUSH заносит значение в стек, инструкция POP удаляет из стека верхний элемент, а инструкция бинарного сложения удаляет из стека два верхних элемента и заносит в стек их сумму. Виртуальная машина TrueType не относится к числу стековых машин общего назначения. Это специализированная псевдомашина, предназначенная для единственной цели — подгонки контуров глифов по сетке. Кроме значений из таблицы контрольных величин, она использует несколько переменных графического состояния (эталонная точка 0, эталонная точка 1, вектор проекции и т. д.). Мы не будем рассматривать весь набор инструкций глифов TrueType. Вместо этого базовые принципы будут продемонстрированы на простом примере буквы «Н» из шрифта Tahoma. Контур глифа изображен на рис. 14.16. Иомп Рис. 14.16. Контур буквы «Н» шрифта Tahoma Буква Н шрифта Tahoma состоит из одного контура с 12 контрольными точками, которые все расположены на линии; другими словами, в данном глифе кривые Безье отсутствуют. Помимо точек глиф содержит 50 байт инструкций, которые занимают больше места, чем координаты. Ниже приведен список координат и инструкций глифа. Координаты 0: 1232. О 1: 1034, 0
784 Глава 14. Шрифты 2 3 4 5 6 7 8 9 К 1 Длина 1034, 349. 349, 151, 151, 349, 349. 1034, ): 1034, L: 1232. 729 729 0 0 1489 1489 905 905 1489 1489 инструкций: 50 00: NPUSHB (28): 3 53 8 8 5 10 7 3 8 9 2 20 0 101 13 64 13 2 8 3 100 12 30: SRP0 31: MIRP[srpO,nmd.rd,2] 32: MIRP[srpO,md,rd,l] 33: SHP[rp2,zpl] 34: DELTAP1 35: SRPO 36: MIRP[srp0.nmd.rd,2] 37: MIRPEsrpO.md.rd.l] 38: SHP[rp2,zpl] 39: SVTCA[y-axis] 40: MIAP[rd+ci] 41: ALIGNRP 42: MIAP[rd+ci] 43: ALIGNRP 44: SRP2 45: IP 46: MDAP[rd] 47: MIRP[nrpO,md.rd.l] 48: IUP[y] 49: IUP[x] 50 байт инструкций глифа разделены на 21 инструкцию. Большинство инструкций (кроме первой) состоит из одного байта. У каждой инструкции имеется мнемоническое название, набор флагов в квадратных скобках и ряд дополнительных параметров. Давайте последовательно рассмотрим все инструкции. 1. Инструкция NPUSHB (занести N байт в стек) заносит в стек заданное количество байт. В данном примере в стек заносятся 28 байт из потока инструкций. Верхний элемент стека равен 12. 2. Инструкция SRP0 (установить эталонную точку 0) извлекает значение 12 из стека и назначает контрольную точку 12 эталонной точкой 0. Контрольная точка 12 соответствует базовой точке em-квадрата. 3. Инструкция MIRP[srp0,nmd,rd,2] (относительное перемещение эталонной точки) извлекает из стека значения 100 и 5 и перемещает точку 5 так, чтобы ее расстояние от эталонной точки 0 было равно CVT[100] (элемент таблицы
Шрифты TrueType 785 контрольных величин с индексом 100). Эта инструкция привязывает крайнюю левую точку глифа к заданному расстоянию от базовой точки по оси х. 4. Инструкция MIRP[srpO,md,rd,l] (относительное перемещение эталонной точки) извлекает из стека значения 20 и 3 и перемещает точку 3 относительно точки 5 в соответствии со значением CVT[20]. Тем самым обеспечивается фиксированная ширина горизонтальной черты. 5. Инструкция SHP[rp2,zpl] (сдвинуть точку по эталонной точке) извлекает из стека значение 8 и сдвигает точку 8 на то же расстояние, на которое была сдвинута эталонная точка (точка 3). 6. Инструкция DELTAP1 (дельта-исключение Р1) извлекает из стека значения 2, 13, 64, 13 и 15 и создает исключения со значением 13 в точках 64 и 15. В результате заданные точки перемещаются на величину, определяемую парными величинами (13). В данном случае номера точек, похоже, неверны. 7. Инструкция SRP0 (установить эталонную точку 0) извлекает значение 13 из стека и назначает контрольную точку 13 эталонной точкой 0. Точка 13 является автоматически добавляемой точкой, расстояние которой от базовой точки em-квадрата (точка 12) равно полной ширине глифа. 8. Инструкция MIRP[srpO,nmd,rd,2] (относительное перемещение эталонной точки) извлекает из стека значения 101 и 0 и перемещает точку 0 относительно точки 13 со смещением CVT[101]. Кроме того, эталонная точка 0 перемещается в точку 0. 9. Инструкция MIRP[srpO,nmd,rd,2] (относительное перемещение эталонной точки) извлекает из стека значения 20 и 2 и перемещает точку 2 относительно точки 0 со смещением CVT[20]. 10. Инструкция SHP[rp2,zpl] (сдвинуть точку по эталонной точке) извлекает из стека значение 9 и сдвигает точку 8 на то же расстояние, на которое была сдвинута эталонная точка (точка 2). 11. Инструкция SVTCA[y-axis] перемещает проекционный вектор на ось у. Подгонка по оси х закончена, мы переходим к оси у. 12. Инструкция MIAP[rd+ci] извлекает из стека значения 8 и 15 и перемещает точку 5 в абсолютную позицию CVT[8] = 0. 13. Инструкция ALIGNRP (выровнять по эталонной точке) извлекает из стека значение 1 и выравнивает точку 1 по эталонной точке 0 (точка 5). 14. Инструкция MAIP[rd+ci] извлекает из стека значения 3 и 7 и перемещает точку 7 в абсолютную позицию CVT[3] = 1489. Это гарантирует однозначное определение высоты буквы Н. 15. Инструкция ALIGNRP (выровнять по эталонной точке) извлекает из стека значение 10 и выравнивает точку 10 по эталонной точке 0 (точка 7). 16. Инструкция SRP2 (установить эталонную точку 2) извлекает значение 15 из стека и назначает контрольную точку 5 эталонной точкой 2. 17. Инструкция IP (интерполировать точку) извлекает из стека значение 8 и интерполирует позицию точки 8 с учетом исходного отношения между эталонными точками (5 и 10).
786 Глава 14. Шрифты 18. Инструкция MDAP[rd] (абсолютное перемещение эталонной точки) извлекает из стека значение 8, устанавливает эталонные точки 0 и 1 в точку 8 и округляет точку 8. 19. Инструкция MIRP[nropO,md,rl,l] (относительное перемещение эталонной точки) извлекает из стека значения 53 и 3 и перемещает точку 3 относительно точки 80 со смещением CVT[53]. 20. Инструкция IUP[y] интерполирует остальные точки контура в направлении оси у. 21. Инструкция ШР[х] интерполирует остальные точки контура в направлении осих Впрочем, это всего лишь упрощенное описание инструкций простейшего глифа. Полный набор инструкций глифов TrueType и их семантика — гораздо более сложная тема. Существует более 100 различных инструкций, 20 переменных графического состояния и несколько типов данных. За полной информацией обращайтесь к руководству «TrueType Reference Manual» на сайте fonts.apple.com. Горизонтальные метрики Информация, хранящаяся в таблице данных глифа, недостаточна для горизонтального выравнивания последовательности глифов, образующих строку текста, или вертикального выравнивания строк абзаца. Базовые метрики латинских шрифтов TrueType хранятся в двух таблицах: таблице горизонтальной структуры и таблице горизонтальных метрик (таблицы «hhea» и «htmx»). Прежде чем рассматривать эти таблицы, необходимо познакомиться с некоторыми шрифтовыми метриками, показанными на рис. 14.17. Подстрочный интервал ^ Левый / отступ Высота строки Базовая линия \ Правый отступ Рис. 14.17. Метрики глифа Надстрочным интервалом (ascent) называется расстояние от верхней границы прописных букв до базовой линии. Надстрочный интервал является атрибу-
Шрифты TrueType 787 том всего шрифта, а не отдельного глифа. Эта метрика определяет положение базовой линии текстовой строки от начальной позиции вывода. Подстрочный интервал (descent) также является атрибутом шрифта и определяет расстояние от базовой линии до нижней границы подстрочных элементов (в таких глифах, как Q, q или g). Сумма подстрочного интервала с надстрочным образует высоту строки шрифта, хотя при выводе абзацев могут использоваться дополнительные междустрочные интервалы. У каждого глифа имеется ограничивающий блок, в шрифтах TrueType являющийся частью заголовка глифа. Ограничивающий блок описывается четверкой [xmin,ymin,xmax,ymax], то есть минимальными и максимальными координатами контрольных точек глифа. По горизонтали между базовой точкой и позицией xmin глифа обычно существует небольшой зазор, который называется левым отступом. После размещения глифа в строке базовая точка следующего глифа смещается от позиции хтах на расстояние, называемое правым отступом. Левый и правый отступы, как и ограничивающий блок, относятся к числу атрибутов отдельных глифов. Сумма левого отступа, ширины глифа (хтах - xmin) и правого отступа называется полной шириной. Полная ширина определяет горизонтальное смещение базовой точки после размещения глифа в строке. Следующий глиф выводится от новой базовой точки. Значения левого и правого отступов обычно положительны, что соответствует разделению глифов дополнительными промежутками. Впрочем, иногда они бывают отрицательными для сближения глифов. Например, в шрифте Times New Roman строчная буква «j» имеет отрицательный левый отступ, а строчная буква «f» имеет отрицательный правый отступ. На рис. 14.18 изображена буква «F» курсивного шрифта с отрицательными отступами с обеих сторон. Рис. 14.18. Глиф с отрицательными значениями левого и правого отступов В шрифтах TrueType такие атрибуты, как надстрочный и подстрочный интервалы шрифта, хранятся в горизонтальной заголовочной таблице, а данные уровня глифа (такие, как левый отступ и полная ширина) — в таблице горизонтальных метрик.
788 Глава 14. Шрифты Определение структуры горизонтальной заголовочной таблицы («hhea») выглядит следующим образом: typedef struct Fixed FWord FWord FWord FWord FWord FWord FWord SHORT SHORT SHORT SHORT version; Ascender; Descender; LineGap; advanceWidthMax; minLeftSideBearing; minRightSideBearing xMaxExtent; caretSlopeRise; caretSlopeRun; reserved[5]; metricDataFormat; USHORT numberofHMetrics; } TableJHoriHeader; В горизонтальной заголовочной таблице («hhea») хранятся надстрочные и подстрочные интервалы шрифта, междустрочный промежуток, максимальная полная ширина, минимальный левый и правый отступы, максимальные габариты (левый отступ + хтах - xmin), хинты для вывода каретки и информация о таблице горизонтальных метрик. В таблице горизонтальных метрик (таблица «htmx») хранится информация горизонтальных метрик уровня глифа. Для каждого глифа должен существовать способ получения левого отступа и полной ширины, по которым правый отступ вычисляется по формуле «полная ширина - левый отступ - (хтах - xmin)». Впрочем, для моноширинных шрифтов с постоянным значением полной ширины хранение нескольких копий полной ширины считается расточительством, поэтому таблица горизонтальных метрик делится на две части: в первой части хранится полная ширина и левый отступ каждого глифа, а во второй — только левые отступы. В таблице должны содержаться сведения обо всех глифах шрифта; количество глифов, имеющих полные горизонтальные метрики, хранится в последнем поле горизонтальной заголовочной таблицы (поле numberOfHMetrics). Ниже приведено описание структуры таблицы горизонтальных метрик. Обратите внимание: обе части представляют собой массивы переменной длины. typedef struct { FWord advanceWidth; FWord lsb; } IngHorMetric; typedef struct { longHorMetric hMetrics[l]; // numberOfHMetrics; FWord leftSideBearing[l]; // С предыдущим advanceWidth } Table_HoriMetrics; Данные горизонтальных метрик шрифта можно получить средствами GDI при помощи функций GetCharABCWidths, GetCharABCWidthsFloat и GetCharABCWidthsI. В терминологии GDI левый отступ называется метрикой А, хтах - xmin назы- // 0x00010000 для версии 1.0 // Типографский надстрочный интервал // Типографский подстрочный интервал // Типографский междустрочный интервал // Максимальная полная ширина // Минимальный левый отступ ; // Минимальный правый отступ // Мах(левый отступ + (хМах - xMin)) // Наклон курсора // 0 для вертикального положения. // Присваивается 0. // 0 означает текущий формат // элементы hMetric в таблице 'htmx'
Шрифты TrueType 789 вается метрикой В, а правый отступ — метрикой С. Мы рассмотрим эти функции в следующей главе при знакомстве с форматированием текста, поскольку эти функции в большей степени связаны с логическими шрифтами GDI, нежели с физическими шрифтами TrueType. Кернинг При размещении глифов в строке используются параметры левого и правого отступов, улучшающие ее внешний вид, однако для каждого глифа эти атрибуты являются постоянными величинами. Когда два конкретных глифа находятся по соседству, из-за особенностей их формы эти глифы иногда должны располагаться ближе или дальше друг от друга. Регулировка интервалов между определенными парами глифов называется кернингом. Благодаря кернингу сочетания этих глифов выглядят более естественно. В режиме TrueType данные кернинга берутся из таблицы, созданной разработчиком шрифта. Ниже приведены структуры таблицы кернинга (таблица «kern») для шрифтов TrueType. typedef struct { FWord FWord FWord } KerningPair; typedef struct { FWord FWord FWord FWord FWord FWord FWord FWord FWord KerningPair leftglyph; rightglyph: move; Version; nSubTables; SubTableVersion; Bytesinsubtable; Coveragebits; Numberpairs; SearchRange; EntrySelector; RangeShift; KerningPair[lJ: // Переменный размер } TableJCerning; Таблица кернинга имеет довольно простую структуру — она состоит из заголовка и простого массива структур KerningPair; каждая структура содержит два индекса глифов и поправку. Пары кернинга сообщают подсистеме вывода текста о необходимости отрегулировать расстояние между двумя конкретными глифами, следующими в указанном порядке. Например, поля первой пары кернинга шрифта Tahoma равны 4, 180, -94. Это означает следующее: «Если глиф 180 следует непосредственно за глифом 4, его базовая точка смещается влево на 94 единицы em-квадрата, чтобы глифы располагались ближе друг к другу». Для шрифта, содержащего п глифов, максимальное количество пар кернинга равно п х п; если шрифт состоит из тысяч глифов, число получается очень большим. К счастью, разработчики шрифта определяют пары кернинга лишь для относи-
790 Глава 14. Шрифты тельно небольшого количества пар. Например, в шрифте Tahoma определены 674 пары. Приложение может получить данные кернинга шрифта при помощи функции GDI GetKerningPairs. typedef struct { WORD wFirstl WORD wSecond; int iKernAmount; } KERNINGPAIR; DWORD GetKerningPairs(HDC hDC. DWORD nNumPairs. LPKERNINGPAIR Ipkrnpair): Чтобы получить данные кернинга для текущего логического шрифта, выбранного в контексте устройства, сначала вызовите функцию GetKerningPair с параметрами 0 (nNumPairs) и NULL (Ipkrnpair); функция вернет количество определенных пар. Выделите память pi вызовите функцию повторно для получения фактических данных кернинга. Учтите, что значение iKernAmount в структуре KERNINGPAIR задается в логических координатах контекста устройства, а не в единицах em-квадрата TrueType. Конечно, таблицу кернинга можно также получить функцией GetFontData. Метрики OS/2 и Windows В таблице «OS/2» хранятся важные метрические данные, используемые в операционных системах семейств OS/2 (IBM) и Windows (Microsoft). По названию можно предположить, что первоначально эта таблица предназначалась для OS/2. Графическая система должна иметь возможность как-то охарактеризовать различные шрифты, установленные в системе, чтобы при поступлении запроса от приложения можно было подобрать установленный шрифт, наиболее близко отвечающий требованиям. Таблица «OS/2» содержит большое количество атрибутов, учитываемых графической системой при обработке запросов. Таблица «OS/2» имеет следующую структуру: typedef struct USHORT SHORT USHORT USHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT SHORT version; xAvgCharWidth; usWeightClass; usWidthClass; fsType; ySubscriptXSize; ySubscriptYSize; ySubscriptXOffset ySubscriptYOffset ySuperscriptXSize ySuperscriptYSize ySuperscriptXOffset; ySuperscriptYOffset; yStrikeoutSize; yStrikeoutPosition; sFamilyClass; // 0x0001 // Взвешенная средняя ширина a..z // FW THIN .. FW BLACK // ULTRA_C0NDENSED .. ULTRA_EXPANDED // Возможность внедрения шрифта // Толщина перечеркивающей линии // Шрифты IBM
Шрифты TrueType 791 PANOSE ULONG ULONG ULONG ULONG CHAR USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT ULONG ULONG panose; ulUnicodeRangel ulUnicodeRange2 ulUnicodeRange3 u!UnicodeRange4 achVendID[4]; fsSelection; // Биты 0-31 Интервал символов Unicode // Биты 32-63 // Биты 64-95 // Биты 96-127 // Идентификатор поставщика // ITALIC.REGULAR usFirstCharlndex; // Первый символ UNICODE usLastCharlndex sTypoAscender; sTypoDescender; sTypoLineGap; usWinAscent; usWinDescent; ulCodePageRange] // Последний символ UNICODE // Типографский надстрочный интервал // Типографский подстрочный интервал // Типографский междустрочный интервал // Надстрочный интервал для Windows // Подстрочный интервал для Windows L: // Биты 0-31 ulCodePageRange2; // Биты 32-63 } Table 0S2; Таблица «OS/2» содержит подробную информацию в формате, достаточно близком к структурам шрифтовых метрик GDI — таких, как LOGFONT, TEXTMETRICS, ENUMTEXTMETRIC и OUTLINETEXTMETRIC. Вследствие мультиплатформенной природы шрифтов TrueType обилие непоследовательной информации иногда сбивает с толку. Например, в таблице «OS/2» хранятся два набора надстрочных и подстрочных интервалов, которые не всегда совпадают с одноименными атрибутами, хранящимися в горизонтальной заголовочной таблице. Другие таблицы Мы подробно рассмотрели важнейшие таблицы шрифта TrueType. Впрочем, шрифты ТгиеТуре/ОрепТуре могут содержать другие таблицы, относящиеся к нетривиальным возможностям, используемые на других платформах или просто при печати на принтере. Таблица имен («name») позволяет связывать со шрифтом TrueType строковые данные на нескольких языках. Строки могут содержать названия шрифтов, семейств, стилей, информацию об авторских правах и т. д. Таблица PostScript («post») содержит дополнительную информацию для принтеров PostScript, в том числе описание Fontlnfo и имена PostScript всех глифов шрифта. Программная таблица контрольных величин («prep») содержит инструкции TrueType, которые должны выполняться при каждом изменении шрифта, кегля или матрицы преобразования, перед интерпретацией контура глифа. Программная таблица шрифта («fpgm») содержит инструкции, выполняемые при первом использовании шрифта. Таблица базовой линии («BASE») содержит информацию, используемую при выравнивании глифов разных начертаний и размеров в одной строке. Таблица определения глифов («GDEF») содержит данные классификации глифов, точки входа для упрощения доступа к данным и кэширования растров и т. д. Таблица размещения глифов («GPOS») позволяет точно управлять положением глифов при нетривиальном форматировании текста в каждом начертании и языке, поддерживаемом шрифтом. Таблица подстановки глифов
792 Глава 14. Шрифты («GSUB») содержит информацию подстановки глифов для воспроизведения поддерживаемых начертаний и языков. Она применяется для поддержки лигатур, контекстной замены глифов и т. д. Таблица выключки («JSFT») обеспечивает возможность дополнительного управления заменой и позиционированием глифов в тексте, выровненном по ширине. Вертикальная заголовочная таблица («vhea») и таблица вертикальных метрик («vmtx») содержат метрические данные для вертикальных шрифтов, включая зеркальные копии горизонтальной заголовочной таблицы и таблицы горизонтальных метрик. Таблица электронной подписи («DSIG») содержит электронную подпись шрифта ОрепТуре, на основе которой реализуются некоторые меры безопасности. Например, по электронной подписи операционная система может проверить источник и целостность шрифтовых файлов перед их использованием, а разработчик шрифта может установить ограничения на внедрение шрифта в документы. Коллекции TrueType Технология Microsoft ОрепТуре позволяет упаковать несколько шрифтов ОрепТуре в один шрифтовой файл, называемый «коллекцией TrueType» (TrueType Collection, TTC). Коллекции TrueType удобны для работы с похожими шрифтами, имеющими большое количество одинаковых глифов. Например, японский набор символов делится на небольшое количество глифов каны (японской слоговой азбуки) и тысячи глифов кандзи (иероглифов). В группе японских шрифтов было бы вполне разумно определить уникальные глифы каны при использовании общих глифов кандзи. Как говорилось выше, нормальный шрифт TrueType/OpenType состоит из одного каталога и нескольких таблиц. Файл коллекции TrueType состоит из одной заголовочной таблицы ТТС, нескольких каталогов таблиц (по одному для каждого шрифта) и большого количества таблиц (используемых совместно или раздельно). Заголовочная таблица ТТС устроена достаточно просто. В ней хранится тег («ttcf»), версия, количество каталогов и массив смещений каталогов таблиц TrueType. typedef struct { ULONG TTCTag; //Тег ТТС 'ttcf ULONG Version: // Версия ТТС (изначально 0x0001000) ULONG DirectoryCount; // Количество каталогов таблиц DWORD Directory[l]; // Смещения каталогов (переменный размер) } TTCJeader; Хотя коллекции шрифтов экономят память и место на диске, они нарушают работу функции GetFontData. При вызове GetFontData приложение запрашивает данные TrueType для всего шрифта, сохраняет их и передает на другой компьютер, где позднее этот шрифт устанавливается. Однако при работе с коллекцией приложение не знает, являются ли полученные данные полными или же они входят в коллекцию шрифтов TrueType. Что еще хуже, некоторые смещения задаются
Установка и внедрение шрифтов 793 относительно невидимого заголовка коллекции TrueType вместо текущего каталога таблиц. Например, смещения в структуре Tab! eDi rectory задаются относительно начала физического файла, поэтому они зависят от того, откуда были получены данные — из отдельного шрифта или из коллекции. Обходное решение заключается в проверке размеров всех шрифтов в коллекции по тегу ТТС. Сравнивая их с размерами текущего шрифта, можно определить его смещение в коллекции и в дальнейшем использовать его для поиска нужных таблиц. Установка и внедрение шрифтов Шрифты распространяются в виде файлов. Чтобы шрифт мог использоваться приложениями, он должен быть предварительно установлен операционной системой. В GDI существует несколько функций, управляющих установкой и удалением шрифтов, а также используемых при внедрении шрифтов в приложения или документы. BOOL CreateScalableFontResourceCDWORD fdwHidden, LPCTSTR IpszFontRes. LPCTSTR IpszFontFile, LPCTSTR 1pszCurrentPath); int AddFontResource(LPCTSTR IpszFileName); BOOL RemoveFontResourceCLPCTSTR IpFileName); int AddFontResourceExCLPCTSTR IpszFileName. DWORD f 1, DESIGNVECTOR * pdv); int RemoveFontResourceExCLPCTSTR IpszFileName, DWORD f1, DESIGNVECTOR * pdv); HANDLE AddFontMemResourceEx(LPVOID pbFont, DWORD cbFont. DESIGNVECTOR * pdb, DWORD * pcFonts); int RemoveFontMemResourceEx(HANDLE fh); Ресурсные файлы шрифтов Основными типами шрифтов в операционных системах Windows считались векторные и растровые шрифты, а форматы TrueType, OpenType и PostScript поначалу воспринимались как что-то постороннее. Несколько ресурсов растровых или векторных шрифтов (обычно относящихся к одной гарнитуре, но с разным кеглем) объединялись в 16-разрядные библиотеки DLL, называемые файлами шрифтовых ресурсов. В этих файлах шрифты подключались к приложению в виде двоичных ресурсов типа FONT (RTF0NT). Непосредственная поддержка установки шрифтов предусмотрена в GDI только для шрифтов в старом 16-разрядном формате файлов шрифтовых ресурсов. Для установки шрифта TrueType необходимо создать ресурсный файл масштабируемого шрифта. Ресурсный файл масштабируемого шрифта имеет тот же формат 16-разрядной библиотеки DLL, однако он не содержит копии шрифта TrueType. Вместо этого в нем указывается имя файла шрифта TrueType, по которому GDI находит данные шрифта. Чтобы создать ресурсный файл масштабируемого шрифта, вызовите функцию CreateScalableFontResource и передайте ей
794 Глава 14. Шрифты целочисленный флаг, имя создаваемого ресурсного файла, имя существующего файла шрифта TrueType и путь к нему (если он не включен в имя). Флаг fdwHidden сообщает GDI, должен ли шрифт быть скрыт от остальных процессов в системе. Функция CreateScalableFontResource записывает на диск небольшой файл шрифтового ресурса. Ресурсным файлам шрифтов TrueType рекомендуется назначать расширение .FOT, чтобы они отличались он ресурсов растровых и векторных шрифтов с расширениями .FON. Установка открытых шрифтов Функция AddFontResource устанавливает шрифт в системе по имени ресурсного файла, который может соответствовать растровому, векторному или шрифту TrueType. В результате установки шрифта ресурсный файл заносится в системную таблицу шрифтов и начинает использоваться при перечислении шрифтов, подстановке шрифтов, создании логических шрифтов и выводе текста. Шрифт, установленный функцией AddFontResource, доступен для всех приложений, если только шрифтовой ресурс не был создан со специальным флагом, скрывающим его в процессе перечисления шрифтов. Впрочем, шрифт, установленный функцией AddFontResource, доступен только во время текущего сеанса. После перезагрузки шрифт не будет автоматически добавлен в таблицу шрифтов. Чтобы установленный шрифт присутствовал в системе постоянно, информация о нем должна быть включена в реестр. Функция RemoveFontResource решает противоположную задачу — она удаляет шрифтовой ресурс из системной таблицы. При этом работающие приложения необходимо оповестить об изменениях в системной таблице шрифтов. Приложение, изменяющее таблицу шрифтов, должно оповестить об этом все окна верхнего уровня рассылкой сообщения WM_FONTCHANGE. Приложение, использующее список установленных шрифтов, должно обрабатывать сообщение WM_FONTCHANGE и обновлять содержимое списка. Установка закрытых шрифтов и шрифтов Multiple Master OpenType В Windows 2000 появились новые функции AddFontresourceEx и RemoveFontRe- sourceEx. Второй параметр AddFontResourceEx управляет «закрытостью» шрифта. При установке бита FPPRIVATE шрифт не может использоваться другими процессами и становится недоступным после завершения текущего процесса; если установлен флаг FP_N0T_ENUM, шрифт не участвует в перечислении. При установке любого из этих флагов вам уже не придется рассылать сообщение WM_F0NTCHANGE и оповещать другие приложения о шрифте, с которым они не могут работать. Функция RemoveFontResourceEx использует тот же параметр, что и AddFontResourceEx, для удаления шрифта, установленного функцией AddFontResourceEx. В последнем параметре передается указатель на структуру DESIGNVECT0R, используемую только для шрифтов Multiple Master OpenType. Шрифты Multiple Master OpenType строятся на базе шрифтовой технологии PostScript Type 1. Несколько шрифтов Multiple Master OpenType могут обладать общими характеристиками, принимающими значения из определенного интервала (такие характе-
Установка и внедрение шрифтов 795 ристики называются осями), что позволяет осуществлять точную регулировку внешнего вида шрифта. Например, ось насыщенности шрифта Multiple Master ОрепТуре может изменяться в интервале от 300 (тонкий) до 900 (тяжелый). Структура DESIGNVECT0R имеет переменный размер и содержит информацию о количестве характеристик и их значениях. Установка шрифтов из образа в памяти Для установки шрифта TrueType функцией AddFontResource или AddFontResourceEx на диске должны находиться два физических файла — файл шрифта TrueType и ресурсный файл шрифта. Это затрудняет программирование приложений, работающих с закрытыми шрифтами, и полную маскировку закрытых шрифтов от других приложений. Функция AddFontMemResourceEx, появившаяся в Windows 2000, пытается решить эти проблемы, позволяя устанавливать шрифты из образа в памяти. Первые два параметра этой функции задают адрес и размер блока памяти, содержащего один или несколько шрифтовых ресурсов. Третий параметр содержит указатель на структуру DESIGNVECT0R для шрифтов Multiple Master ОрепТуре. Функция AddFontMemresource устанавливает шрифты из образа в памяти, возвращая манипулятор и количество установленных шрифтов. Шрифты, установленные функцией AddFontResourceEx, всегда остаются закрытыми для приложения, в котором была вызвана эта функция. Далее приложение может удалить шрифты функцией RemoveFontMemResourceEx, передавая ей полученный манипулятор. Если приложение этого не сделает, шрифты будут автоматически удалены при завершении процесса. Блок памяти, переданный функции AddFontMemResource, заполняется в формате непосредственных данных ресурса, а не в формате 16-разрядной библиотеки DLL шрифтового ресурса. По сравнению с функциями AddFontResource и AddFontResourceEx функция AddFontMemResourceEx гораздо удобнее, поскольку она позволяет приложению устанавливать и использовать шрифты независимо от других приложений. Внедрение шрифтов При передаче документов на другие компьютеры нередко возникают серьезные проблемы со шрифтами. Установив на своем компьютере нужные шрифты, вы можете отформатировать документ и придать ему желаемый вид. Но если открыть этот документ на другом компьютере с другим набором установленных шрифтов, он может выглядеть совершенно иначе. Подобные проблемы возникают в приложениях, использующих специализированные шрифты, при работе с документами текстовых редакторов, web-страницами и даже файлами спулера при печати на удаленном сервере. Технология внедрения шрифтов (font embedding) позволяет включить специальные шрифты прямо в документ. При открытии документа внедренные шрифты автоматически устанавливаются на другом компьютере, благодаря чему документ сохраняет прежний вид. Внедрение шрифтов должно соответствовать лицензионным правилам использования шрифтов. Для шрифтов TrueType/OpenType определены шесть уров-
796 Глава 14. Шрифты ней внедряемости, обозначаемые флагом fsType в таблице метрик OS/2 и Windows («OS/2»). О Внедрение с возможностью установки (0x0000): шрифт может внедряться в документы и устанавливаться в удаленной системе для постоянного использования. Большинство шрифтов из поставки ОС Windows допускает именно этот способ внедрения. О Внедрение для редактирования (0x0008): шрифт может внедряться в документы, но только для временной установки в удаленной системе. Например, при внедрении такого шрифта в документ Word вы сможете просматривать и редактировать документ на удаленном компьютере, однако при выходе из WinWord шрифт автоматически удаляется из системы. О Внедрение для просмотра (0x0004), также называемое внедрением только для чтения: шрифт может внедряться в документы, но только для временной установки в удаленной системе. Документы могут открываться только для чтения. Данные шрифта должны быть зашифрованы в документе. На удаленном компьютере шрифт расшифровывается в скрытый файл без расширения .TTF, устанавливается в качестве скрытого шрифта, используется только для просмотра и печати документа и удаляется при выходе из приложения. О Запрет частичного внедрения (0x0100): допускается только полное внедрение всего шрифта. О Внедрение растров (0x0200): внедрение разрешается только для растров, содержащихся в шрифте. Если шрифт состоит из одних контуров глифов, он не может внедряться. О Запрет внедрения (0x0002): шрифт не может внедряться в документы. Учтите, что уровень внедряемости шрифта относится только к внедрению шрифтов в документы, но не в приложения. Согласно MSDN, шрифты не могут внедряться в приложения, а в поставку приложений не могут входить документы, содержащие внедренные шрифты. Функция GetOutlineTextMetrics используется для проверки возможности внедрения шрифтов ТгиеТуре/ОрепТуре. Она возвращает структуру OUTLINETEXTMETRIC, содержимое которой близко к содержимому таблицы метрик OS/2 и Windows (таблица «OS/2») в файле шрифта TrueType. Поле otmfsType этой структуры имеет то же значение, что и описанное выше поле f sType. В листинге 14.4 приведены две функции установки и удаления шрифтов ТгиеТуре/ОрепТуре. Функция Install Font получает образ шрифта TrueType/ ОрепТуре в памяти, создает файлы .TTF и .FOT и устанавливает шрифт. Функция RemoveFont исключает шрифт из системного списка и удаляет файлы .TTF и .FOT. Обе функции получают параметр option, который сообщает, должен ли шрифт быть открытым, скрытым, закрытым, не перечисляемым или устанавливаемым прямо из образа в памяти. В зависимости от значения option выбирается функция GDI, вызываемая при установке и удалении шрифта. Листинг 14.4. Установка и удаление шрифтов #define FR_HIDDEN 0x01 #define FR_MEM 0x02
Установка и внедрение шрифтов 797 BOOL RemoveFont(const TCHAR * fontname. int option. HANDLE hFont) { if ( option & FR_MEM ) { return RemoveFontMemResourceEx(hFont); } TCHAR ttffile[MAX_PATH]; TCHAR fotfile[MAX_PATH]; GetCurrentDirectory(MAX_PATH-l, ttffile); _tcscpy(fotfile. ttffile); wsprintf(ttffile + _tcslen(ttffile). "\Us.ttf". fontname); wsprintf(fotfile + _tcslen(fotfile), "\Us.fot". fontname); BOOL rslt; switch ( option ) { case 0; case FR_HIDDEN: rslt = RemoveFontResource(fotfile); break; case FR_PRIVATE: case FR_NOT_ENUM; case FR_PRIVATE | FR_NOT_ENUM: rslt = RemoveFontResourceEx(fotfile, option. NULL): break; default: assert(false); rslt = FALSE; } if ( ! DeleteFile(fotfile) ) rslt = FALSE; if ( ! DeleteFile(ttffile) ) rslt = FALSE; return rslt; HANDLE InstallFont(void * fontdata. unsigned fontsize. const TCHAR * fontname. int option) { if ( option & FR_MEM ) { DWORD num; return AddFontMemResourceEx(fontdata. fontsize. NULL. & num); } TCHAR ttffile[MAX_PATH]; Продолжение &
798 Глава 14. Шрифты Листинг 14.4. Продолжение TCHAR fotfile[MAX_PATH]; GetCurrentDirectory(MAX_PATH-1. ttffi 1 e); _tcscpy(fotfile. ttffile); wsprintf (ttffile + Jcslen(ttffile). "\Us.ttf". fontname); wspnntf(fotfile + Jxslen(fotfile). "\Us.fot". fontname); HANDLE hFile = CreateFileCttffile. GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN. 0); if ( hFile==INVALIDJANDLE_VALUE ) return NULL; DWORD dwWritten; WriteFile(hFile. fontdata. fontsize. & dwWritten, NULL); FlushFileBuffers(hFile); CloseHandle(hFile); if ( ! CreateScalableFontResource(option & FR_HIDDEN. fotfile, ttffile, NULL) ) return NULL; switch ( option ) { case 0; case FRJIDDEN: return (HANDLE) AddFontResource(fotfile); case FR_PRIVATE; case FRJOTJNUM: case FR_PRIVATE | FRJOTJNUM: return (HANDLE) AddFontResourceEx(fotfile, option, NULL); default: assert(false); return NULL; Функции, приведенные в листинге 14.4, были использованы в простой демонстрационной программе FontEmbed. Эта программа представляет собой простое приложение на базе диалогового окна (рис. 14.19). В диалоговом окне программы FontEmbed расположены три кнопки. Кнопка Generate генерирует «документ» с внедренными шрифтами ТгиеТуре/ОрепТуре, выбранными пользователем, применяя несложный механизм шифрования. Кнопка Load загружает сгенерированный документ и устанавливает внедренные шрифты в системе. Режим использования шрифта определяется группой переключателей. Кнопка Unload удаляет все установленные шрифтовые ресурсы. Справа показаны результаты, полученные при выводе текста внедренными шрифтами.
Установка и внедрение шрифтов 799 1!^Н1ШНнняН1 бшшЫ© toad Urtoacf №W|l|l|WWl'|lWiMlM|TMl"|iWWlMlMil 4e Г Private Ozzie Black С No Enumerate ^ # л# г Memcv Ozzie Blueli Italic ж Рис. 14.19. Демонстрация внедрения шрифтов При построении рисунка были использованы три бесплатных шрифта TrueType с web-страницы HP FontSmart Homage (www.fonstmart.com): Euro Sign, Ozzie Black и Ozzie Black Italic. Если эти шрифты не установлены в системе, первая строка выводится стандартным шрифтом Symbol, а две других — шрифтом Arial. После установки шрифтов диалоговое окно принимает вид, показанный на рисунке, но после удаления шрифтов окно возвращается к прежнему виду. Если у вас нет этих шрифтов, загрузите их, а если есть — найдите в Интернете какие-нибудь новые бесплатные или условно-бесплатные шрифты. Запустите программу FontEmbed, поэкспериментируйте с разными вариантами установки и проверьте, доступен ли шрифт после установки в текущем приложении и в других приложениях. Системная таблица шрифтов В Windows NT/2000 список шрифтов, постоянно присутствующих в системе, хранится в следующем разделе реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts Во время загрузки системы шрифты загружаются в системную таблицу шрифтов, что дает возможность их использовать. Шрифты в списке соответствуют физическим шрифтам, совместно используемым всеми процессами в системе. На самом деле графический механизм хранит в адресном пространстве режима ядра целых три таблицы — для открытых шрифтов, для закрытых шрифтов и для шрифтов устройств, которые обычно поддерживаются современными принтерами (например, принтерами PostScript). Постоянные шрифты, предоставленные операционной системой, обычно должны быть доступны для всех приложений, поэтому они хранятся в таблице открытых шрифтов. Если файл шрифтового ресурса OpenType/TrueType создается с флагом скрытия, при передаче флага FR_HIDDEN при вызове CreateFontResourceEx или при использовании функции CreateFontMemResourceEx шрифт хранится в таблице закрытых шрифтов. Если флаг FR_NOT_ENUM используется без флага FRHIDDEN, шрифт заносится в таб-
800 Глава 14. Шрифты лицу открытых шрифтов. В системном списке шрифтов хранятся полные пути к файлам каждого шрифта. Если шрифт устанавливался из ресурса, находящегося в памяти, для него используется имя псевдофайла типа «MEMORY-1». В расширении отладчика GDI поддерживаются три команды pubft, pvtft и devft для вывода содержимого таблиц шрифтов. Вы можете использовать эти команды в управляющей программе Fosterer (см. главу 3). Итоги Эта глава посвящена основным принципам вывода текста в графическом Windows-программировании. Она начинается с описания базовых концепций шрифтов: символов, наборов символов, глифов, кодировок и отображения символов в глифы. Далее описываются три основных типа шрифтов системы Windows: растровые, векторные и шрифты TrueType. Мы знакомимся с тем, как в каждом типе шрифта представляются глифы и как происходит их вывод в процессе растеризации. Глава завершается описанием установки и удаления шрифтов, а также внедрения шрифтов в документы. Руководствуясь хорошим пониманием шрифтов, заложенным в этой главе, в главе 15 мы переходим к их практическому применению — выводу текста. Примеры программ К главе 14 прилагаются два примера программ (табл. 14.4). Таблица 14.4. Программы главы 14 Каталог проекта Описание Samples\Chapt_14\Fonts Иллюстрация общих концепций — наборов символов, кодировок, глифов, семейств шрифтов, процесса перечисления и трех основных типов шрифтов (растровые, векторные и шрифты TrueType) Samples\Chapt_14\FontEmbed Иллюстрация установки, удаления и внедрения шрифтов в документы
Глава 15 Текст Как было показано в предыдущей главе, шрифты являются основным элементом выводимого текста. В этой главе рассматриваются логические шрифты, функции вывода текста, простейшее форматирование, качественное и точное форматирование и специальные эффекты, используемые при выводе текста. Логические шрифты В главе 14 были описаны важнейшие особенности трех основных шрифтовых технологий, применяемых в Windows-программировании, — растровых шрифтов, векторных шрифтов и шрифтов ТшеТуре/OpenType. Впрочем, даже если вы досконально разбираетесь в устройстве физических шрифтов, работать с ними напрямую — дело сложное и долгое, на которое явно не стоит тратить время программиста. К счастью, при выводе текста приложениям Windows (и даже графическому механизму) не приходится напрямую общаться с физическими шрифтами. Прикладная программа обычно работает только с логическими шрифтами при помощи специальных функций API. С физическими шрифтами работают шрифтовые драйверы, находящиеся в системе на одном уровне с драйверами графических устройств. В графическом механизме Windows NT/2000 реализованы три шрифтовых драйвера для трех типов шрифтов, непосредственно поддерживаемых Microsoft. Шрифты ATM поддерживаются отдельным шрифтовым драйвером (atmfd.dll). Поддержка логических шрифтов основана на взаимодействии графического механизма с шрифтовыми драйверами. По сравнению с физическими шрифтами логические шрифты обладают рядом существенных преимуществ. О Логические шрифты обеспечивают независимость от устройства. Логический шрифт создается по перечню требований пользователя к шрифту. Графический механизм отвечает за подбор шрифта с указанными параметрами среди физических шрифтов, установленных в системе. Система сможет подобрать
802 Глава 15. Текст похожий шрифт даже в том случае, если некоторые шрифты в ней отсутствуют. При этом для разных графических устройств могут выбираться разные шрифты, отвечающие заданным требованиям. О Логические шрифты поддерживают использование кодировок. Чтобы найти в шрифте TrueType глиф для заданной кодировки, вам придется провести поиск в таблице отображения символов на индексы глифов. Логические шрифты маскируют индексы глифов от приложений. О Логические шрифты позволяют создавать экземпляры шрифтов с заданными размерами. Описания глифов в шрифте представляют собой общие шаблоны для построения глифов с любым кеглем или углом поворота. Растровый шрифт обычно содержит разные шрифтовые ресурсы для разных кеглей. Векторные шрифты и шрифты TrueType/OpenType допускают произвольное масштабирование и любые преобразования. При выборе логического шрифта в контексте устройства создается конкретный экземпляр шрифта с заданным кеглем и углом поворота. Такая архитектура позволяет графическому механизму и шрифтовым драйверам кэшировать масштабированные и растеризованные версии глифов для повышения быстродействия системы. О Логические шрифты позволяют имитировать определенные возможности на программном уровне. Некоторые распространенные начертания шрифтов (например, подчеркивание и перечеркивание) не реализуются в физических шрифтах, а имитируются GDI. Кроме того, GDI может имитировать курсивное и полужирное начертание в тех случаях, когда соответствующий физический шрифт недоступен. Метрики шрифтов в Windows Прежде чем переходить к подробному рассмотрению логических шрифтов, давайте познакомимся с терминами, используемыми при работе со шрифтами в Windows. Учтите, что смысл некоторых терминов Windows GDI слегка отличается от смысла этих терминов в шрифтовой спецификации TrueType и традиционном печатном деле. На рис. 15.1 показаны основные метрики, применяющиеся при форматировании текста в GDI. Воображаемая линия, по которой осуществляется вертикальное выравнивание глифа, называется базовой линией. Нижняя точка большинства прописных букв находится практически на базовой линии. Символы располагаются в ячейках одинаковой высоты. Расстояние от верхнего края ячейки до базовой линии называется надстрочным интервалом. Обычно даже самые высокие глифы не достают до верхнего края ячейки, поэтому в GDI понятие «надстрочный интервал» несколько отличается от типографских надстрочных интервалов, используемых в шрифтах TrueType. Расстояние от базовой линии до нижней части ячейки символа называется подстрочным интервалом. Нижняя точка подстрочного элемента глифа также может отделяться некоторым расстоянием от нижней стороны ячейки. Сумма надстрочного и подстрочного интервалов называется высотой шрифта. В промежутке между надстрочной линией и верхней стороной ячейки обычно размещаются акценты и другие диакритические знаки. Высота этого проме-
Логические шрифты 803 жутка называется внутренним зазором (internal leading). Когда несколько строк текста образуют абзац, нижняя сторона ячеек предыдущей строки отделяется от верхней стороны ячеек текущей строки дополнительным интервалом, который называется внешним зазором (external leading). Внешний зазор I Надстрочный] интервал Высота Метрика А Внутренний зазор Метрика С Рис. 15.1. Метрики шрифтов в Windows Размер текста измеряется в пунктах. В традиционном печатном деле один пункт равен 0,01389 дюйма (1/71,99424 дюйма). В компьютерной верстке пункт округляется до 1/72 дюйма, поэтому один дюйм состоит ровно из 72 пунктов. Погрешность составляет всего 1/12 500 дюйма, поэтому для практических целей ей можно пренебречь. При упоминании текста или шрифта термин «кегль» относится к метрике «надстрочный интервал + подстрочный интервал - внутренний зазор», то есть «высота - внутренний зазор». Обратите внимание: кегль не включает ни внутренний, ни внешний зазор. Например, в абзаце 10-пунктового текста сумма «надстрочный интервал + подстрочный интервал - внутренний зазор» равна 10 пунктам, что соответствует 13,3 пиксела на экране с разрешением 96 dpi или 83,3 пиксела на принтере с разрешением 600 dpi. В абзацах с кеглем 10 пунктов расстояние между строками обычно равно 12 или 13 пунктам, то есть 6 или 5,54 строки на дюйм. Горизонтальные метрики, используемые в GDI, почти совпадают с метриками шрифтов TrueType. Расстояние между двумя соседними символами называется пол7юй шириной. Полная ширина делится на три части. Левая часть обычно соответствует пробелу перед крайней левой точкой глифа; она называется метрикой А (левый отступ в терминологии шрифтов TrueType). Средняя часть определяет фактическую ширину глифа в ячейке и называется метрикой В. Правая часть обычно соответствует пробелу после крайней правой точки глифа и называется метрикой С (правый отступ в TrueType). Полная ширина символа равна сумме метрик А, В и С. Метрики А и С могут иметь отрицательные значения для сближения глифов, особенно в курсивных шрифтах.
804 Глава 15. Текст Стандартные шрифты Логический шрифт представляет собой объект GDI, описывающий требования к конкретному воплощению физического шрифта. Объект логического шрифта, как и другие объекты GDI, находится под управлением GDI, а с точки зрения приложения он представляют собой «черный ящик». Пользовательские приложения работают с логическими шрифтами только через манипуляторы логических шрифтов, относящиеся к типу HF0NT. В системе определяются семь стандартных (встроенных) логических шрифтов GDI, используемых операционной системой при выводе пользовательского интерфейса, а также в приложениях. Манипуляторы стандартных логических шрифтов возвращаются вызовами GetStockOb ject (DEFAULTGU I_F0NT), GetStockObject (SYSTEMFONT) и т. д. Большинство стандартных логических шрифтов относится к категории растровых шрифтов, используемых для ускоренного вывода заголовков окон, меню, диалоговых окон и т. д. На рис. 15.2 показаны 7 стандартных шрифтов на мониторе с разрешением 96 dpi. Для каждого стандартного шрифта приведен способ получения манипулятора функцией GetStockObject и содержимое структуры L0GF0NT, о которой речь пойдет ниже. DialogBasellnits: baseunixX=8, baseunitY=16 GetDeviceCaps(LOGPIXELSX)=96, GetDeviceCaps(LOGPIXELSX)=96 GetStockObjecKDEFAULT.GULFONT) M 1,0,0,0,400,0,0,0,0,0,0,0,0, MS Shell Dig} GetStockObject<OEM_FIXED_FONT> <12, 8, 0, 0, 400, 0, 0, 0, 255, 1, 2, 2, 49, Terminal> GetStockObject(ANSI_FIXED_FONT) {12, 9, 0, 0, 400, 0, 0, 0, 0, 0, 2, 2, 1, Courier} GetStockObiect(ANSI_VAR^FONT) {12,9,0,0,400, 0,0,0, 0, 0, 2,2,2, MS Sans Serif} GetStockObject(SYSTEM_FONT) {16,7, 0, 0, 700, 0, 0, 0, 0, 1, 2, 2, 34, System} GetStockObject(DEVICE_DEFAULT_FONT| {16, 7, 0, 0, 700, 0, 0, 0, 0, 1, 2, 2, 34, System} GetStockObject(SVSTEM_FIXED_FONT) {15, 8, 0, 0, 400, О, О, О, О, 1, 2, 2, 49, Fixedsys} Рис. 15.2. Стандартные шрифты в разрешении 96 dpi Стандартные шрифты часто встречаются в заголовках окон, меню и текстах, выводимых в различных элементах управления. Размер стандартного шрифта в пикселах изменяется при изменении логического разрешения экрана. Например, логическое разрешение нормального экрана равно 96 dpi — так называемый режим «мелких шрифтов». При помощи панели управления можно переключиться в режим «крупных шрифтов» с разрешением 120 dpi. При переключении экрана из режима мелких шрифтов в режим крупных шрифтов все стандартные шрифты приходится заново отображать на физические шрифты большего раз-
Логические шрифты 805 мера, для чего обычно перезагружают систему. После этого все заголовки окон, меню, элементы и диалоговые окна увеличиваются в соответствии с изменениями в размере шрифта. Проектирование пользовательского интерфейса, который бы идеально выглядел в обоих режимах (крупных и мелких шрифтов) — задача не из простых. Вы можете воспользоваться функцией GetSystemMetrics для получения различных системных метрик, в том числе текущих размеров строк заголовка и меню. Например, вызов GetSystemMetrics(SM_CYMENU) возвращает высоту строки меню с одной строкой команд. Диалоговые окна проектируются в аппаратно-независи- мых шаблонных диалоговых единицах. При создании диалогового окна шаблонные единицы преобразуются в экранные пикселы с учетом текущих базовых диалоговых единиц по следующим формулам: pixelX = (templateunitX * baseunitX) / 4; pixelY = (templateunitY * baseunitY) / 8; Базовые диалоговые единицы определяются средней шириной и высотой символов стандартного шрифта, используемого для вывода элементов в диалоговых окнах. Их значения можно получить при помощи функции GetDialogBaseUnits. В разрешении 96 dpi baseunitX = 8, a baseunitY =16, поэтому каждая шаблонная диалоговая единица преобразуется в два экранных пиксела. В разрешении 120 dpi baseunitX = 10, baseunitY = 20, а каждая шаблонная диалоговая единица преобразуется в 2,5 экранных пиксела. В результате при переключении из режима мелких шрифтов в режим крупных шрифтов диалоговые окна увеличиваются на 12,5 %. На первый взгляд кажется, что все очень здорово, поскольку вы «бесплатно» получаете текст высокого разрешения, однако не все элементы пользовательского интерфейса справляются с подобным увеличением. Если в диалоговом окне присутствуют растры и значки или вы используете немодальное диалоговое окно, внедренное в недиалоговое окно, в увеличенном диалоговом окне может наблюдаться уменьшение растров и значков, усечение текста и нарушение выравнивания диалоговых окон относительно недиалоговых. Создание логических шрифтов Область применения стандартных шрифтов обычно ограничивается простым выводом элементов пользовательского интерфейса. Для любых других целей вам придется создавать собственные логические шрифты. В GDI предусмотрены три функции для создания логических шрифтов. typedef struct tagLOGFONT { LONG LONG LONG LONG LONG LONG LONG LONG LONG LONG LONG IfHeight; IfWidth; IfEscapement; 1 fomentation; IfWeight; Ifltalic; IfUnderline; IfStrikeOut; IfCharSet; IfOutPrecision; IfClipPrecision;
806 Глава 15. Текст LONG lfQuality; LONG IfPitchAndFamily; LONG 1fFaceName[LF_FACESIZE]; } LOGFONT. *PLOGFONT; typedef struct tagENUMLOGFONTEX { LOGFONT elfLogFont; TCHAR elfFul1Name[LF_FULLFACESIZE]; TCHAR elfStyle[LF_FACESIZE]; TCHAR elfScript[LF_FACESIZE]; } ENUMLOGFONTEX, *LPENUMLOGFONTEX; typedef struct tagENUMLOGFONTEXDV { ENUMLOGFONTEX elfEnumLogfontEx; DESIGNVECTOR elfDesignVector; } ENUMLOGFONTEXDV, *PENUMLOGFONTEXDV; HFONT CreateFont (int nHeight, int nWidth. int nEscapement. int nOrientation. int fnWeight. DWORD fdwltalic, DWORD fdwUnderline, DWORD fdwStrikeOut, DWORD fdwCharSet. DWORD fdwOutputPrecision, DWORD fdwClipPrecision, DWORD fdwQuality, DWORD fdwPitchAndFamily. LPCTSTR IpszFace); HFONT CreateFontIndirect(CONST LOGFONT * Iplf); HFONT CreateFontIndirectEx(const ENUMLOGFONTEXDV * penumlfex); Параметры этих трех функций описывают требования пользователя к создаваемому логическому шрифту. Функция CreateFont использует для описания логического шрифта 14 параметров — рекорд для функций GDI. Функция CreateFontlndirect получает указатель на структуру LOGFONT, в которой упакованы все 14 параметров. Новая функция CreateFontlndirectEx, появившаяся только в Windows 2000, получает указатель на структуру ENUMLOGFONTEXDV. В структуру ENUMLOGFONTEXDV добавляется поле DESIGNVECTOR, в котором содержится уникальное имя шрифта, имена начертания и модификации. Таким образом, базовые требования к логическому шрифту описываются структурой LOGFONT, передаваемой при вызове CreateFontlndirect; функция CreateFont просто получает развернутую версию структуры LOGFONT, тогда как функция CreateFontlndirectEx всего лишь использует расширенный вариант этой структуры. LOGFONT и другие шрифтовые структуры играют очень важную роль для понимания шрифтов GDI, поэтому мы должны рассмотреть их основные поля. О If Height. Желательная высота шрифта в логических единицах. Если значение равно 0, используется стандартная высота шрифта, равная примерно 12 пунктам. Положительные значения определяют требуемую высоту ячеек (то есть сумму надстрочного и подстрочного интервалов). Отрицательные значения определяют высоту символов шрифта (надстрочный интервал + подстрочный интервал - внутренний зазор). О lfWidth. Желательная ширина шрифта в логических единицах. Если значение равно 0, поиск осуществляется сравнением аспектного отношения графического устройства с аспектным отношением физического шрифта. Экраны и принтеры обычно обладают одинаковым разрешением по вертикали и горизонтали — например, 120 х 120 dpi или 600 х 600 dpi. В этом случае нулевое
Логические шрифты 807 значение параметра отдает предпочтение шрифтам с аспектным отношением 1:1. О 1 fEscapement. Угол (в десятых долях градуса против часовой стрелки) между базовой линией текста и осью х устройства. Например, 1 fEscapement = 900 означает, что весь текст выводится вдоль базовой линии, параллельной оси у. О IfOrientation. Угол (в десятых долях градуса против часовой стрелки) между базовой линией каждого символа и осью х устройства. Следует помнить, что ориентация определяет угол поворота отдельных символов, а наклон (lfEscapement) — угол поворота всей строки. Если устройство работает в расширенном графическом режиме (GM_ADVANCED), доступном лишь в Windows NT/ 2000, наклон и ориентация задаются независимо друг от друга. В совместимом графическом режиме (GM_C0MPATIBLE), поддерживаемом в Windows 95/98, поле lfEscapement определяет IfOrientation, и значения этих полей должны совпадать. О lfWeight. Насыщенность (жирность) шрифта в интервале от 0 до 1000. Значение FMJD0NTCARE (0) позволяет GDI выбрать шрифт с произвольной насыщенностью, FMJI0RMAL (400) соответствует средней насыщенности, а FW_HEAVY (900) обычно определяет самый жирный шрифт. О lfltalic. Если значение этого поля равно TRUE, предпочтение отдается курсивным шрифтам. О If Underline. Если значение этого поля равно TRUE, текст выводится с подчеркиванием. О IfStrikeOut. Если значение этого поля равно TRUE, текст выводится перечеркнутым (посреди строки проводится линия). О IfCharSet. Набор символов шрифта; также определяет кодировку, в которой строки передаются функциям вывода текста GDI. Наборы символов и кодировки описаны в разделе «Что такое шрифт?» главы 14. У поля IfCharSet имеется специальное значение DEFAULT_CHARSET. В Windows 95/98 шрифт определяется значениями других полей, а в Windows NT/2000 будет задействован набор символов, используемый по умолчанию для текущего системного локального контекста. Например, если системный локальный контекст соответствует английскому языку, используется значение ANSI CHARSET. При работе с экзотическими языками поле 1 fCharSet играет очень важную роль для выбора правильного шрифта, поскольку глифы нужного набора могут поддерживаться лишь небольшим количеством физических шрифтов. О IfOutPrecision. Желательные параметры подбора физических шрифтов. Значение 0UT_DEFAULT_PRECIS указывает на стандартный способ подбора шрифтов. При значении 0UTDEVICEPRECIS предпочтение отдается шрифтам устройств, а при значении OUTRASTERPRECIS — растровым шрифтам. Значение 0UT_0UTLINE_ PRECIS (только в Windows NT/2000) отдает предпочтение контурным шрифтам, в том числе и шрифтам TrueType. При значении 0UT_JT_PRECIS предпочтение отдается шрифтам TrueType, а при значении 0UTTT0NLYPRECIS подбор осуществляется только среди шрифтов TrueType. О IfClipPrecision. Способ отсечения шрифтов. Для этого поля определено несколько флагов, но похоже, что к отсечению имеет отношение только флаг
808 Глава 15. Текст CLIPDEFAULTPRECIS (стандартная процедура отсечения). Если поле lfClipPre- cision равно CLIPEMBEDDED, допускается использование внедренных шрифтов, доступных только для чтения. При указании флага CLIPLHANGLES направление поворота глифов шрифтов устройств зависит от того, является ли логическая система координат левосторонней или правосторонней; в противном случае шрифты устройств всегда поворачиваются против часовой стрелки. О lfQuality. Качество вывода глифов. Значение DEFAULTQUALIYY сообщает GDI, что внешний вид символов несущественен. Значение DRAFT_QUALITY говорит о том, что размер шрифта важнее качества глифа, что позволяет GDI масштабировать растровые шрифты по нужным размерам с возможными искажениями. Значение PR00FQUALITY указывает на то, что качество глифа важнее размера шрифта, поэтому масштабирование растровых шрифтов запрещается. Для шрифтов TrueType константы DRAFTQUALIT Y и PROOFQUALITY несущественны, поскольку контуры глифов свободно масштабируются до нужной величины. Значение ANTIALIASEDQUALITY заставляет GDI выполнять сглаживание текста, если оно поддерживается шрифтом, а сам шрифт не слишком велик и не слишком мал. Значение NONANTIALIASEDQUALITY запрещает сглаживание. О lfPitchAndFamily. Шаг и семейство шрифта определяются в одном поле. Младшие 2 бита могут быть равны DEFAULTPITCH (шаг по умолчанию,) FIXEDPITCH (моноширинный шрифт) или VARIABLEPITCH (пропорциональный шрифт). Биты 4-7 определяют семейство шрифта в виде константы FFDECORATIVE, FF_DONTCARE, FF_M0DERN, FF_R0MAN, FFJCRIPT и FFJWISS. Семейства шрифтов описаны в разделе «Что такое шрифт?» главы 14. О IfFaceName. Имя гарнитуры шрифта. Имена гарнитур шрифтов, установленных в настоящий момент, перечисляются функцией EnumFontFamilies. О elf Full Name. Уникальное имя шрифта, включающее название компании, имя гарнитуры, начертания и т. д. О elf Sty! е. Начертание шрифта — например, Bold Italic. О elf Script. Название языковой модификации шрифта — например, Cyrillic. О elfDesignVector. Оси шрифтов Multiple Master OpenType. Функции CreateFont, CreateFontIndirect и CreateFontlndirectEx создают объект логического шрифта и возвращают его манипулятор вызывающей стороне. Вызывая по манипулятору объекта GDI функцию GetObject, можно получить структуру LOGFONT или ENUMLOGFONTEX с описанием логического шрифта. Когда объекты логических шрифтов становятся ненужными, их, как и остальные объекты GDI, следует удалить функцией Del eteObject. При создании логического шрифта следует прежде всего рассчитать высоту шрифта в логических координатах. Если вы знаете размер шрифта в пунктах, следует преобразовать его в логические координаты по эталонному контексту устройства. Ниже приведена функция, которая преобразует размер шрифта в пунктах в размер, заданный в логических координатах. // Преобразование пунктов в логические координаты int PointSizetoLogicaKHDC hDC. int points, int divisor) {
Логические шрифты 809 POINT P[2] = // Две точки (POINT) в координатах устройства, // расстояние между которыми равно высоте шрифта { { 0. О }, { 0. ::GetDeviceCaps(hDC. L0GPIXELSY) * points / 72 / divisor DPtoLPChDC. P, 2); // Преобразовать координаты устройства // в логические координаты return abs(P[l].y - P[0].y); } Функция Poi ntSizeToLogi cal получает манипулятор эталонного контекста устройства, размер в пунктах и необязательный делитель, повышающий точность вычислений. Сначала пункты преобразуются в пикселы на основании вертикального разрешения устройства, после чего значение преобразуется в высоту, заданную в логической системе координат. Например, высота шрифта с кеглем 12 пунктов вычисляется вызовом Poi ntSi zetoLogi cal (hDC,12), а для шрифта с кеглем 12,25 используется вызов PointSizetoLogicaKhDC, 1225, 100). На устройствах высокого разрешения (скажем, на принтере с разрешением 1200 dpi) каждый пиксел равен 0,06 пункта, поэтому дробная часть кегля может влиять на форматирование текста. Заполнение 14 полей структуры L0GF0NT или передача 14 параметров функции CreateFont — утомительная процедура, которая нередко чревата ошибками. В листинге 15.1 приведен простой класс KLogFont, инкапсулирующий структуру логического шрифта L0GF0NT. Листинг 15.1. Класс KLogFont: инкапсуляция структуры LOGFONT class KLogFont public: LOGFONT mjf; KLogFont(int height, const TCHAR * typeface=NULL) i m If.lfHeight mJf.lfWidth mjf. If Escapement mjf Л fomentation m lf.lfWeight mjf.lfltalic m If.IfUnderline mJf.lfStrikeOut mJf.lfCharSet mJf.lfOutPrecision mJf.lfClipPrecision m If.lfQuality mJf.lfPitchAndFamily if ( typeface ) = height; - 0; = 0; = 0; - FW NORMAL; - FALSE; - FALSE; = FALSE; - ANSI CHARSET; = OUT TT PRECIS; = CLIP DEFAULT PRECIS: - DEFAULT QUALITY; - DEFAULT PITCH | FF D0NTCARE; Jxsncpy(mJf.lfFaceName. typeface. LF_FACESIZE-1) else Продолжение &
810 Глава 15. Текст Листинг 15.1. Продолжение mJf.lfFaceName[0] = 0; HFONT CreateFont(void) return ::CreateFontlndirect(& mjf); int Get0bject(HF0NT hFont) return ::GetObject( hFont. sizeof(mjf), &mjf); }: Класс KLogFont сокращает количество параметров с 14 до 2. Остальным параметрам присваиваются разумные значения по умолчанию, которые можно изменить через поля открытой переменной ml f. В следующем фрагменте создается логический курсивный шрифт с кеглем 36 пунктов для шрифта Times New Roman: KLogFont lf(- PointSizetoLogical (hDC. 36), "Times New Roman"; lf.mjf.lfltalic = TRUE; HFONT hFont - lf.CreateFontO; Подстановка шрифта Новый логический шрифт, созданный функцией CreateFont, CreateFontlndirect или CreateFontlndirectEx, не ассоциируется ни с каким физическим шрифтом, поскольку он еще не ассоциирован с контекстом устройства. При выборе логического шрифта в контексте устройства перед GDI встает задача — подобрать физический шрифт, соответствующий заданному описанию. Этот процесс называется подстановкой шрифта (font matching). В процессе подстановки GDI сверяет требования логического шрифта с данными всех шрифтов, доступных для графического устройства. Помимо шрифтов, постоянно установленных в системе, в подстановке также могут участвовать внедренные шрифты и шрифты устройств. В главе 14 было показано, как внедрить шрифт в документ, установить его при открытии документа и получить список установленных шрифтов. Шрифты устройств поддерживаются драйвером графического устройства и реализуются графическим устройством на аппаратном уровне. Например, принтер PostScript обычно поддерживает несколько десятков шрифтов PostScript и передает информацию о них GDI, чтобы эти шрифты использовались при выводе текста. Обычно пользовательское приложение форматирует текст на основании метрических данных, запрашиваемых у контекста устройства. При непосредственном получении команд вывода драйвер принтера может генерировать команды, использующие шрифты устройства, вместо загрузки шрифтов TrueType. В классических растровых и векторных шрифтах Windows структура заголовка шрифта очень похожа на структуру TEXTMETRIC, используемую в GDI. Структура TEXTMETRIC содержит практически те же данные, что и L0GF0NT, — высоту, среднюю ширину, насыщенность, семейство и тип, курсив, подчеркивание, перечеркивание и т. д. GDI без особых усилий подбирает нужный шрифт, сопостав-
Логические шрифты 811 ляя содержимое L0GF0NT с заголовком шрифта. Иначе говоря, создание логических шрифтов по структуре L0GF0NT ориентировано на работу с растровыми и векторными шрифтами. Шрифты TrueType и ОрепТуре содержат гораздо более подробную информацию о характеристиках физического шрифта. Метрические данные шрифтов TrueType/OpenType хранятся в таблице метрик OS/2 и Windows, похожей на структуру GDI OUTLINETEXTMETRIC. Самым важным фактором при подборе физического шрифта является набор символов. Хотя большинство шрифтов поддерживает набор ANSI, символы других языков иногда поддерживаются лишь незначительной долей шрифтов, установленных в системе. Например, шрифты очень редко поддерживают декоративные знаки. Когда приложение запрашивает конкретный набор символов, GDI прикладывает все усилия к тому, чтобы найти шрифт с поддержкой именно этого набора; в противном случае символы могут выводиться совершенно неверными глифами. Растровые и векторные шрифты поддерживают лишь один набор символов; шрифт TrueType может поддерживать десятки наборов. В каждом шрифте TrueType/OpenType хранится 64-разрядное поле флагов с определением кодировок, поддерживаемых шрифтом. Очень большое внимание также уделяется точности вывода. Этот показатель ограничивает кандидатов определенными типами шрифтов. Например, 0UT_ OUTLINEPRECIS отдает предпочтение контурным шрифтам. Моноширинные шрифты по внешнему виду сильно отличаются от пропорциональных, поэтому тип шрифта также является важным фактором при подстановке. Первостепенное внимание уделяется и имени гарнитуры. Обнаружив физический шрифт с точным совпадением имени гарнитуры, у которого совпадают другие важные факторы (набор символов, высота, курсивное начертание и насыщенность), подсистема подстановки шрифтов GDI прекращает дальнейшие поиски. В системном реестре хранится список синонимов для имен гарнитур, заданных пользователем. Например, этот список может сообщить системе подстановке шрифтов, что «Helv» является синонимом «MS Sans Serif», «MS Shell Dig» — синонимом «Microsoft Sans Serif», a «Times» — синонимом «Times New Roman». Другими важными факторами, учитываемыми в процессе подстановки для растровых шрифтов, является семейство шрифта, высота, ширина и аспектное отношение. Для контурных шрифтов насыщенность шрифта, подчеркивание, перечеркивание, высота, ширина и аспектное отношение уже не столь существенны. Система подстановки шрифтов PANOSE Как видите, процесс подбора шрифтов по данным L0GF0NT выглядит вполне логично. Однако в нем учитываются лишь те данные, которые передаются при вызовах CreateFont/CreateFontlndirect и хранятся в заголовках растровых и векторных шрифтов. Если документ пересылается на компьютер с другим набором шрифтов, ситуация значительно усложняется. Допустим, документ хранит в структуре L0GF0NT информацию о шрифте с гарнитурой Antique Olive Compact. Как следует действовать GDI, чтобы подобрать правильный физический шрифт?
812 Глава 15. Текст Хотя структура OUTLINETEXTMETRIC шрифтов ТшеТуре/OpenType содержит копию простой структуры TEXTMETRIC, основным средством классификации шрифтов является структура PANOSE. Система подстановки шрифтов PANOSE предназначена для классификации и подбора шрифтов в соответствии с их внешним видом. В настоящее время шрифты TrueType используют технологию PANOSE 1.0, которая описывает шрифт 10 однобайтовыми характеристиками: typedef struct tagPANOSE { BYTE bFamilyType; BYTE bSerifStyle; BYTE bWeight; BYTE bProportion; BYTE bContrast; BYTE bStrokeVariation; BYTE bArmStyle; BYTE bLetterForm; BYTE bMidline; BYTE bxHeight; } PANOSE, * LPPANOSE; В отличие от структуры L0GF0NT, в которой к внешнему виду шрифта относятся всего два поля (IfWeight и IfPitchAndFamily), структура PANOSE закладывает основу для более точной подстановки шрифтов. В частности, в PANOSE определяются 14 разных стилей засечек — квадратные, треугольные, закругленные и т. д. Структура PANOSE обеспечивает компактный и эффективный способ классификации и подстановки шрифтов в системе. Для каждого шрифта TrueType/ ОрепТуре заполняется структура PANOSE, и степень сходства двух шрифтов оценивается по «расстоянию» между соответствующими точками 10-мерного пространства характеристик шрифтов. Технология PANOSE 2.0 идет еще дальше — для описания шрифтов в ней используется 36 значений. За дополнительной информацией о системе подстановки шрифтов PANOSE обращайтесь по адресу www.fonts.com/hp.panose/index.htm. Хотя технология PANOSE обеспечивает значительно лучший результат, чем подстановка шрифтов на основании структур L0GF0NT и TEXTMETRIC, в GDI не существует функций для ее непосредственной поддержки. Функции CreateFont, CreateFontIndirect и CreateFontlndirectEx не используют структуру PANOSE при определении логического шрифта. На самом деле работа алгоритма подстановки шрифтов PANOSE основана на СОМ-интерфейсе IPANOSEMapper, реализованном в одной из малоизвестных системных библиотек panmap.dll. В частности, этот интерфейс используется приложением Fonts (Шрифты) панели управления, когда пользователь запрашивает группировку схожих шрифтов. На рис. 15.3 показана система подстановки шрифтов PANOSE в действии. На рисунке показано, как выглядит окно приложения при выборе команды View ► List Fonts by Similarity (Вид ► Группировать схожие шрифты). Если выбрать в качестве эталона шрифт Tahoma, то шрифт Verdana будет обозначен как «очень похожий», шрифт Arial — «весьма похожий», а шрифт Courier — «не похожий». Для некоторых шрифтов в списке имеет место запись о недоступности сведений (то есть данные PANOSE отсутствуют).
Логические шрифты 813 9# £с& $ew ¥$т%т 1<А "* « Si I Фв««Ь <&?<**** &НМоф ] Ш Ш\Ш jj &®$ j Sinia#loT#iQma ■ иищвдЧВДГ Mam© |.CJJ] Tahoma \d\ Verdana Ш Aria| У Arial Black i*j Arial N arrow fifl Rnnkro*nn.HShd* Very similar Very similar Fairly similar Fairly similar Fairly similar F^irln <?imil*r ?11опЩр1и$$2КШепЗ Рис 15.3. Механизм PANOSE в приложении панели управления В листинге 15.2 приведен простой класс для работы с интерфейсом IPANOSEMapper. Листинг 15.2. Класс KFontMapper: использование интерфейса IPANOSEMapper class KFontMapper { IPANOSEMapper * m_pMapper; const PANOSE * m_pFontList: int mjiFontNo; public: KFontMapper(void) { m_pMapper = NULL; m_pFontList = NULL; mjiFontNo = 0; CoInitialize(NULL); CoCreateInstance(CLSID_PANOSEMapper, NULL. CLSCTX_INPROC_SERVER, IID_IPANOSEMapper, (void **) & m_pMapper); void SetFontList(const PANOSE * pFontList. int nFontNo) { m_pFontList = pFontList; m nFontNo = nFontNo: int PickFonts(const PANOSE * pTarget, unsigned short * pOrder, unsigned short * pScore, int nResult) / Продолжение &
814 Глава 15. Текст Листинг 15.2. Продолжение m_pMapper->vPANRelaxThreshold(); int rslt = m_pMapper->unPANPickFonts( pOrder, // Порядок (от лучшего к худшему) pScore, // Результат поиска (BYTE *) pTarget, // Метрика PANOSE для сравнения nResult. // Количество возвращаемых шрифтов (BYTE *) m_pFontList, // Метрика PANOSE первого шрифта mjiFontNo. // Количество сравниваемых шрифтов sizeof(PANOSE), рТа rget->bFami1уТуре); m_pMapper->bPANRestoreThreshold(); return rslt; } -KFontMapper0 { if ( m_pMapper ) m_pMapper->Release(); CoUninitializeO; Помимо конструктора и деструктора, класс KFontMapper содержит две функции. Функция SetFontList заполняет массив структур PANOSE для доступных шрифтов. Функция PickFonts получает метрику PANOSE и пытается найти для нее хорошие совпадения. Результаты возвращаются в двух массивах — шрифтов и расстояний между исходной структурой PANOSE и подобранными вариантами. Чтобы использовать класс KFontMapper, необходимо решить две проблемы. Первая — определение метрики PANOSE для шрифта, которому вы подбираете замену. Вторая — построение базы данных с метриками PANOSE для всех доступных шрифтов в системе. В одном из возможных решений метрика PANOSE сохраняется вместе со структурой L0GF0NT в документе. При создании логического шрифта и его выборе в контексте устройства GDI подбирает для логического шрифта физический шрифт, установленный в системе. Функция GetOutlineTextMetric GDI возвращает структуру OUTLINETEXTMETRIC для физического шрифта. В поле otmPanoseNumber этой структуры хранится метрика PANOSE. Метрика PANOSE сохраняется в форматах RTF (Rich Text Format) и EMF (Enhanced Metafile). Формат RTF используется расширенными текстовыми полями, исходными справочными файлами системы Windows, такими приложениями, как WordPad и даже Microsoft Word. В MSDN Knowledge Base имеется статья с упоминанием о дефекте Word 97. Хотя формат RTF, используемый в Word 97, сохраняет метрики PANOSE со шрифтами, при подстановке отсутствующих шрифтов Word 97 эти метрики игнорирует. Если провести поиск слова «PANOSE» в заголовочном файле wingdi.h GDI, выясняется, что оно используется в структуре EXTLOGFONT. Структура EXTLOGFONT является расширением L0GF0NT с полными именами гарнитуры и стиля, идентификатором разработчика, метрикой PANOSE и т. д. Таким образом, структура
Логические шрифты 815 содержит информацию как о логическом, так и о физическом шрифтах. Как ни странно, ни одна документированная функция GDI не получает и не возвращает структуру EXTL0GF0NT. Существует лишь одно документированное применение EXTL0GF0NT - в структуре EMREXTCREATEFONTINDIRECTW, используемой для записи команды создания логического шрифта в формате EMF. Задача построения базы данных чисел PANOSE для всех доступных шрифтов может показаться простой. В главе 14 мы выяснили, как при помощи функции EnumerateFontFamiliesEx получить список всех семейств шрифтов в системе. Для каждого семейства EnumerateFontFamiliesEx вызывает функцию, переданную приложением, и передает ей структуру NEWTEXTMETRICEX, в которой среди прочих интересных данных хранится поле для метрики PANOSE. Но проблема заключается в том, что в этих функциях перечисляются не физические шрифты, а семейства шрифтов, причем каждое семейство обычно включается в список несколько раз для каждой поддерживаемой кодировки. Например, в семейство Arial входят четыре разных шрифта: Arial, Arial Bold, Arial Bold Italic и Arial Italic, однако функция EnumerateFontFamiliesEx считает их за одно семейство Arial, которое включается в список 9 раз для каждой поддерживаемой модификации (латиница, иврит, арабский, греческий, турецкий, прибалтийский, центрально- европейский, кириллица и вьетнамский). Конечно, шрифт Arial заметно отличается от Arial Bold Italic, но функция EnumerateFontFamiliesEx выводит только один шрифт семейства и скрывает все остальные. Если вы воспользуетесь ей для заполнения базы данных PANOSE, база данных получится неполной. Собственно, такая база данных уже хранится в реестре Windows по ключу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Panose Список установленных физических шрифтов хранится в реестре по ключу SOFTWAREWMicrosoftWWindows NTWCurrentVersionWFonts В результате перебора списка физических шрифтов можно получить имена гарнитур шрифтов и отфильтровать их, оставив только шрифты TrueType/ ОрепТуре. По имени гарнитуры вы создаете логический шрифт, выбираете его в контексте устройства и отображаете на физический шрифт. Если найденный физический шрифт является шрифтом TrueType/OpenType, его метрику PANOSE можно получить функцией GetOutlineTextMetrics. Функция, приведенная в листинге 15.3, по имени гарнитуры возвращает метрику PANOSE и имя подставленной гарнитуры. Методика перечисления шрифтов рассматривается в главе 14. Листинг 15.3. Получение метрики PANOSE по имени гарнитуры // 'Arial Bold Italic' -> PANOSE bool GetPANOSECHDC hDC. const TCHAR * full name, PANOSE * panose. TCHAR facenameCJ) { TCHAR name[MAX_PATH]; // Удалить начальные пробелы while (fullname[0]==' ') full name ++; Продолжение^
816 Глава 15. Текст Листинг 15.3. Продолжение _tcscpy(name. full name); // Удалить завершающие пробелы for (int i=_tcslen(name)-l; (i>=0) && (name[i]==' '); i--) name[i] = 0; LOGFONT If; memset(&lf. 0, sizeof(lf)); If.lfHeight « 100; If.lfCharSet - DEFAULT_CHARSET; If.IfWeight = FW_REGULAR; if ( strstr(name, "Italic") ) If.lfltalic = TRUE; if ( strstr(name, "Bold") ) If.IfWeight - FW_B0LD; _tcscpy(lf.IfFaceName, name); HFONT hFont = CreateFontIndirect(& If); if ( hFont==NULL ) return false; HGDIOBJ hOld = SelectObjectChDC. hFont); { KOutlineTextMetric otm(hDC); if ( otm.GetName(otm.m_pOtm->otmpFaceName) ) { _tcscpy(facename. otm.GetName(otm.m_pOtm->otmpFaceName) ); * panose = otm.m_pOtm->otmPanoseNumber; } else facename[0] = 0; } SelectObjectChDC. hOld); DeleteObject(hFont); return facename[0] != 0; } На рис. 15.4 показано окно PANOSE Font Matching демонстрационной программы Font. Основное место в нем занимает список всех доступных шрифтов и их атрибутов. Если щелкнуть правой кнопкой мыши на одной из строк списка, метрика PANOSE этого шрифта сравнивается с метриками PANOSE всех остальных шрифтов. В окне, расположенном в правой части рисунка, приведены результаты сопоставления для шрифта Courier New. Обратите внимание: у шрифта MingLiU нет метрики PANOSE, что приводит к некоторому искажению результатов. Этот шрифт следовало бы исключить из массива чисел PANOSE. Из ри-
Получение информации о логическом шрифте 817 сунка видно, что шрифт Courier New близок к шрифтам Andale Mono, Lucida Console, Georgia и Palatino Linotype. ШШШШ^^У^'У ' ' \im&*№. \ Courier New j Courier New Bold J Courier New Bold Italic 1 Courier New Italic 1 Lucida Console J Lucida Sans Unicode 1 Times New Roman 1 Times New Roman В... 1 Times New Roman В... I Times New Roman It... 1 Wingdings I Symbol 1 Verdana м fmb Text and Display Text and Display Text and Display Text and Display Text and Display Text and Display Text and Display Text and Display Text and Display Text and Display Pictorial Pictorial Text and Display 3 $*fl Thin Thin Thin Thin Normal Sans Normal Sans Cove Cove Cove Cove Any Obtuse Sq Normal Sans J } Vtafcrt* Light Medium Medium Thin Medium Medium Medium Bold Demi Book Any No Fit Medium j Рщийж Monospaced Mono:f£»fo> МОПО:^ МОПО: МОПО: Old St Mode* Mode* Mode* Mode* Any Old St Even' .УЛ-. n 1 a 3 4 5 S 7 8 a ,~iafxi I CorWil None | 0 24 35 38 5B 12 71 m ш 190 зй\ Cowrie? New з €ounef^«wBdcl ! PW»*UU ШдШ ; €out&*te#M*$c Andab Mono £шш Hew Bd4 ЫЬ iucida Consols Ошд» Pa&inoUttu^pfc OK j Рис. 15.4. Иллюстрация системы подстановки шрифтов PANOSE Качество замены отсутствующих шрифтов можно повысить несколькими способами. Например, в процессе построения документа наряду со структурой L0GF0NT можно сохранить метрику PANOSE вместе с другими данными физического шрифта. За образец можно взять структуру EXTL0GF0NT, используемую в EMF. При открытии документа на другом компьютере приложение проверяет сходство физического шрифта, предложенного GDI, с физическим шрифтом, использовавшимся на исходном компьютере. Степень сходства оценивается сравнением полных имен шрифтов или их чисел PANOSE. Если приложение решает, что исходный шрифт в системе отсутствует, а предложенная замена неприемлема, оно выполняет подстановку самостоятельно. Для этого оно может построить собственную базу данных чисел PANOSE для всех доступных шрифтов, найти оптимальную замену при помощи класса KFontMapper или другого средства и затем заново создать логические шрифты для лучших кандидатов, найденных на локальном компьютере. Получение информации о логическом шрифте После того как созданный объект логического шрифта выбран в контексте устройства, GDI подбирает для него физический шрифт из числа установленных в системе. Когда это происходит, логический объект ассоциируется с реализованным шрифтом. Реализованный шрифт не стоит путать с физическим; это всего лишь конкретный экземпляр физического шрифта с конкретным размером, ас- пектным отношением, углом поворота, имитацией особых возможностей и т. д. Например, физический шрифт Times New Roman в конкретный момент времени может существовать в нескольких воплощениях; одно будет соответствовать ло-
818 Глава 15. Текст гическому шрифту с кеглем 12 для экрана с разрешением 96 dpi, другое — логическому шрифту с кеглем 24 для принтера с разрешением 300 dpi, повернутому на 30 градусов. Реализация физического шрифта — сложная и длительная операция, требующая больших затрат памяти. Как было показано в главе 14, шрифты TrueType имеют весьма сложную структуру, и анализ и поиск в их исходной форме весьма затруднены. Чтобы найти глиф для символа конкретной кодировки, символ приходится преобразовывать в Unicode и затем находить индекс глифа по специальной таблице. В процессе построения глифа его контуры масштабируются по заданным размерам с учетом инструкций, хранящихся в шрифте, а затем преобразуются в растровую форму. Примитивная реализация, при которой вывод каждого символа начинается с отображения кода символа на индекс глифа, окажется непомерной нагрузкой для быстродействия системы. На практике графический механизм поддерживает сложные структуры данных, описывающие соответствие между объектами логических шрифтов и физическими шрифтовыми файлами. В Windows NT/2000 для каждого используемого физического шрифта в адресном пространстве ядра создается структура данных (PFF), содержащая связный список реализаций шрифта (FONTOBJ). В каждой структуре FONTOBJ имеется кэш построенных глифов для их повторного использования. В каждом объекте логического шрифта имеется указатель на недокументированный объект GDI — объект PFE, содержащий ссылки на соответствующие объекты PFF. Эта сложная организация данных обеспечивает возможность эффективного кэширования реализованных шрифтов и их многократного использования на системном уровне, одновременно позволяя GDI свободно создавать, использовать и удалять логические шрифты. Внутренние структуры данных графического механизма, относящиеся к работе со шрифтами, подробно описаны в главе 3. После того как логический шрифт выбран в контексте устройства, вы можете получить дополнительную информацию о подобранном физическом шрифте и о метриках текущей реализации физического шрифта. Для этого используются следующие функции: int GetTextFace(HDC hDC. int nCount, LPSTR lpFaceName); DWORD GetFontLanguagelnfoCHDC hDC); int GetTextCharSeKHDC hDC); int GetTextCharSetInfo(HDC hDC. LPFONTSIGNATURE IpSig. DWORD dwFlags): BOOL GetTextMetrics(HDC hDC, LPTEXTMETRIC Iptm); UINT Get0ut1ineTextMetrics(HDC hDC. UINT cData. LPOUTLINETEXTMETRIC IpOtm); Функция GetTextFace возвращает имя гарнитуры физического шрифта, соответствующего логическому шрифту в контексте устройства (может отличаться от имени гарнитуры, использованного при создании логического шрифта). Функция GetFontLanguagelnfo возвращает информацию о текущем шрифте, выбранном в контексте устройства, в том числе о поддержке двухбайтовых глифов, о присутствии диакритических знаков, о наличии таблицы кернинга и т. д. Информация, полученная при помощи этой функции, часто применяется при нетривиальном форматировании текста (например, при непосредственной работе с глифами с использованием функций GetCharacterPl acement или ExtTextOut).
Получение информации о логическом шрифте 819 Функция GetFontLanguagelnfo возвращает комбинацию нескольких флагов, самыми распространенными из которых являются FLIGLYPHS (0x40000) и GCP_ USERKERNING (0x0008). Флаг FLIGLYPHS означает, что шрифт содержит дополнительные глифы, к которым невозможно обратиться через текущую кодировку. Флаг GCPJJSERKERNING означает, что в шрифте присутствует таблица кернинга. Если на компьютере реализована поддержка арабского языка или иврита, для некоторых шрифтов TrueType функция GetFontLanguagelnfo возвращает флаги GCP_RE0RDER, GCP_GLYPHSHARE, GCP_LIGATE, GCPJHACRITIC и GCP_KASHIDA. Например, шрифты Arial, Lucida Sans Unicode, Tahoma и Andalus поддерживают GCP_ REORDER, a «Times New Roman» не поддерживает. Функция GetTextCharset возвращает идентификатор набора символов для текущего шрифта, выбранного в контексте устройства. По полученному значению можно проверить, поддерживает ли физический шрифт набор символов, необходимый для логического шрифта. Например, если при создании логического шрифта был запрошен набор HANGULCHARSET, но в вашей системе нет ни одного корейского шрифта, GDI может выбрать набор символов по умолчанию; в этом случае функция GetTextCharset вернет ANSICHARSET. Функция GetTextCharset Info возвращает структуру F0NTSIGNATURE с информацией о поддиапазонах Unicode и кодировках, поддерживаемых шрифтом True- Туре/OpenType. Первые четыре двойных слова F0NTSIGNATURE образуют 128-разрядное поле USB (Unicode subset bitfield), а два оставшихся двойных слова образуют 64-разрядное поле СРВ (code page bitfield). Например, бит 9 USB показывает, поддерживаются ли глифы кириллицы, а бит 16 СРВ является признаком поддержки кодировки 874 (тайская). Для шрифта Tahoma в СРВ устанавливаются 12 бит, поскольку этот шрифт содержит глифы 12 разных кодировок. Функции GetTextMetrics и GetOutlineTextMetrics возвращают важные метрические данные о текущей реализации физического шрифта. Функция GetTextMetrics возвращает структуру TEXTMETRIC. Функция GetOutlineTextMetrics возвращает для шрифтов TrueType/OpenType структуру 0UTLINETEXTMETRIC — расширенную версию TEXTMETRIC, содержащую дополнительную информацию. Метрики растровых и векторных шрифтов Структура TEXTMETRIC изначально разрабатывалась для заголовков растровых и векторных шрифтов Windows, но она подходит и для шрифтов TrueType/Open- Type. Чтобы получить заполненную структуру TEXTMETRIC для текущего шрифта, выбранного в контексте устройства, вызовите функцию GetTextMetrics с манипулятором контекста устройства и указателем на TEXTMETRIC. Структура TEXTMETRIC определяется следующим образом: typedef struct tagTEXTMETRIC { LONG tmHeight; LONG tmAscent; LONG tmDescent: LONG tmlnternalLeading; LONG tmExternalLeading; LONG tmAveCharWidth;
820 Глава 15. Текст LONG LONG LONG LONG LONG BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE BYTE } TEXTMETRIC; tmMaxCharWidth; tmWeight; tmOverhang; tmDigitizedAspectX; tmDigitizedAspectY; tmFirstChar; tmLastChar; tmDefaultChar; tmBreakChar; tmltalic: tmUnderlined; tmStruckOut; tmPitchAndFamily: tmCharSet; Поле tmAscent определяет надстрочный интервал (высоту символа над базовой линией). Поле tmDescent определяет подстрочный интервал (высоту части символа, находящейся ниже базовой линии), а поле tmHeight определяет общую высоту символа (tmAscent+tmDescent) — см. рис. 15.1. Поле tmlnternalLeading определяет величину внутреннего зазора — промежутка, в котором обычно размещаются акценты и диакритические знаки, а поле tmExternalLeading определяет внешний зазор — рекомендуемый дополнительный интервал между строками. Разность между tmHeight и tmlnternal Leading соответствует кеглю шрифта — стандартной метрике размера символов. Например, для шрифта с кеглем 36 пунктов в экранном контексте с разрешением 96 dpi и в режиме ММ_ТЕХТ поле If Height структуры LOGFONT будет равно -48 (36 х 96,72). Если создать по этой структуре LOGFONT логический шрифт и выбрать его в экранном контексте устройства, поле tmHeight структуры TEXTMETRIC, возвращаемой функцией GetTextMetrics, будет равно 55, а поле tmlnternal Leading — 7. Разность между ними равна 48 — абсолютной величине поля If Height структуры LOGFONT. Для растровых шрифтов при запрещенном масштабировании (флаг PROOF_QUALITY в поле If Quality структуры LOGFONT) GDI иногда не удается точно подобрать шрифт для заданного размера. Например, для 10-пунктового шрифта гарнитуры Terminal поле If Height в структуре lfHeight равно -13, но поле tmHeight может быть равно 12 при внутреннем зазоре, равном 0. Если не удается подобрать растровый шрифт заданного размера, обычно используется меньший шрифт. Сумма tmHeight и tmExternal Leading составляет рекомендуемый межстрочный интервал. Высота п строк текста вычисляется по формуле tmHeight x n + tmExternal Leading x (n - 1), поскольку перед первой и за последней строкой дополнительный промежуток не нужен. Допустим, у шрифта с кеглем 36 пунктов в экранном контексте с разрешением 96 dpi и в режиме ММТЕХТ поле tmHeight равно 55, а поле tmExternal - Leading равно 2. Общая высота строки равна 57 единицам или 42,75 пункта. Следует помнить, что разные шрифты одного кегля могут иметь разные значения полей tmHeight и tmExternal Leading или их суммы. Поле tmAveCharWidth определяет среднюю ширину символов шрифта. В документации Microsoft сказано, что средняя ширина обычно равна ширине строч-
Получение информации о логическом шрифте 821 ной буквы «х». В шрифтах ТшеТуре/OpenType средняя ширина символов более точно вычисляется как взвешенная сумма ширин строчных букв a-z латинского алфавита и пробела. В моноширинных шрифтах все символы имеют одинаковую ширину, и поле tmAveCharWidth может использоваться для вычисления длины символьной строки. Средняя ширина символов также используется при подборе шрифтов. В поле tmMaxCharWidth хранится максимальная ширина символов шрифта. Поле tmWeight определяет насыщенность шрифта и совпадает с полем lfWeight структуры LOGFONT. Следует учитывать, что все ресурсы растровых и векторных шрифтов, а также физические шрифты TrueType обладают фиксированной насыщенностью. Гарнитура TrueType обычно содержит четыре физических начертания — обычное, курсивное, полужирное и полужирное курсивное. Насыщенность первых двух начертаний обычно равна 400 (FW_N0RMAL), а двух последних — 700 (FWBOLD). GDI пытается найти оптимальное соответствие для заданной насыщенности среди доступных шрифтов. Если точное совпадение найти не удается, GDI имитирует нужную насыщенность при помощи простого алгоритма. Поле tmOverhang определяет величину дополнительных промежутков, используемых GDI при синтезе шрифтов. Если требуемая насыщенность превышает доступную, GDI утолщает символы; если запрашивается курсивное начертание, а физический курсивный шрифт недоступен, GDI слегка наклоняет глифы. В любом случае размер строки немного увеличивается. Поле tmOverhang позволяет приложению точно рассчитать горизонтальные размеры строки символов, чтобы она не вышла за пределы отведенного ей места. На практике у растровых и векторных шрифтов это поле отлично от нуля, а у шрифтов TrueType/Open- Type оно всегда равно нулю. Например, для курсивного шрифта Wingdings с кеглем 72 пункта, имеющего только обычное физическое начертание, в поле tmOverhang возвращается 0. Поле tmFirstChar определяет первый символ, для которого в шрифте имеется глиф; поле tmLastChar определяет последний символ. Оба поля объявляются с типом BCHAR (WCHAR в Unicode, BYTE в остальных кодировках). Растровые и векторные шрифты содержат глифы для всех символов в интервале от tmFirstChar до tmLastChar. В шрифтах TrueType/OpenType однобайтовых версий полей tmFirstChar и tmLastChar недостаточно для представления истинного интервала символов, для которых в шрифте имеются глифы, а Unicode-версии полей не означают, что шрифт содержит глифы для всех символов между tmFirstChar и tmLastChar. Поле tmDefaultChar определяет символ замены для символов, не имеющих глифа в шрифте (обычно это прямоугольная рамка). В шрифтах TrueType по умолчанию обычно используется первый глиф с индексом 0. Поле tmBreakChar задает символ, по которому определяются границы слов при выравнивании текста. Следующие три поля повторяют поля LOGFONT с аналогичными именами. Поле tmltalic отлично от нуля, если требуется курсивное начертание; поле tmUnderline отлично от нуля, если требуется подчеркивание символов, а поле tmStruckOut отлично от нуля, если требуется перечеркивание символов. Помните, что эти поля отражают лишь требования, указанные в объекте логического шрифта, а не характеристики физического шрифта. Начертания, отсутствующие в физическом шрифте, синтезируются средствами GDI.
822 Глава 15. Текст Поле tmPitchAndFamily задает тип, технологию и семейство физического шрифта. Старшая половина поля совпадает со старшей половиной поля IfPitchAndFamily структуры L0GF0NT. Младшая половина состоит из четырех независимых флагов и отличается от младшей половины IfPitchAndFamily. О TMPFFIXEDPITCH (0x01) — устанавливается для пропорциональных шрифтов. Все поставлено с ног на голову — почему было не назвать это поле TMPFPROPPITCH? О TMPF_VECT0R (0x02) — устанавливается для контурных шрифтов (проще говоря, для всех, кроме растровых). О TMPF_TRUETYPE (0x04) — устанавливается для шрифтов TrueType/OpenType. О TMPF_DEVICE (0x08) — устанавливается для шрифтов устройств. Последнее поле tmCharSet определяет набор символов логического шрифта. Его значение совпадает с полем IfCharSet структуры L0GF0NT (если это не DEFAULT_ CHARSET) и с возвращаемым значением функции GetTextCharSet. Шрифт TrueType/ ОрепТуре обычно поддерживает несколько наборов символов, информацию о которых можно получить при помощи функции GetTextCharlnfo. Метрики шрифтов TrueType/ОрепТуре Шрифты TrueType/OpenType обладают значительно большим количеством метрик, для которых была разработана структура 0UTLINETEXTMETRIC. Приставка «outline» может вызвать недоразумения, поскольку эта структура не относится к векторным шрифтам — только к шрифтам TrueType/OpenType и шрифтам устройств, для которых шрифтовой драйвер может предоставить структуру OUTLINE- TEXTMETRIC. Ниже приведено определение структуры 0UTLINETEXTMETRIC. typedef struct JXJTLINETEXTMETRIC { UINT otmSize; TEXTMETRIC otmTextMetrics; BYTE otmFiller; PANOSE otmPanoseNumber; UINT otmfsSelection; UINT otmfsType; int otmsCharSlopeRise; int otmsCharSlopeRun; int otmltalicAngle; UINT otmEMSquare; i nt otmAscent; int otmDescent; UINT otmLineGap; UINT otmsCapEmHeight; UINT otmsXHeight; RECT otmrcFontBox; int otmMacAscent; int otmMacDescent; UINT otmMacLineGap: UINT otmusMinimumPPEM; P0INT otmptSubscri ptSi ze; POINT otmptSubscri ptOffset; POINT otmptSuperscriptSize;
Получение информации о логическом шрифте 823 POINT otmptSuperscriptOffset; UINT otmsStrikeoutSize; int otmsStrikeoutPosition; int otmsUnderscoreSize; int otmsUnderscorePosition; PSTR otmpFamilyName; PSTR otmpFaceName: PSTR otmpStyleName; PSTR otmpFullName; } OUTLINETEXTMETRIC; После того как манипулятор логического шрифта выбран в контексте устройства (при условии, что ему соответствует физический шрифт TrueType/ ОрепТуре), можно вызвать функцию GetOutlineTextMetrics и получить от GDI заполненную структуру OUTLINETEXTMETRIC. Хотя структура OUTLINETEXTMETRIC выглядит не такой уж сложной (если не считать большого количества полей), эта простота обманчива. Описание OUTLINETEXTMETRIC в документации Microsoft оставляет желать лучшего. Во-первых, эта структура имеет переменный размер, поскольку ее последние четыре поля содержат смещения строк, которые обычно присоединяются к блоку данных за последним полем. Здесь же кроется и вторая хитрость: в последних четырех полях хранятся не указатели, как указано в объявлении, а смещения относительно начала блока данных. Последнее поле называется otmSize, и по названию можно предположить, что перед вызовом GetOutlineTextMetrics в это поле следует занести размер структуры. В действительности этого делать не нужно, поскольку размер блока данных передается во втором параметре GetOutlineTextMetrics. Поскольку структура OUTLINETEXTMETRIC имеет переменный размер, функцию GetOutlineTextMetrics приходится вызывать дважды. При первом вызове вы получаете реальный размер структуры, выделяете блок нужного размера и передаете его при втором вызове для получения данных. На прилагаемом компакт- диске имеется класс KOutlineTextMetric, предназначенный для получения структуры OUTLINETEXTMETRIC. Ниже приведено объявление этого класса. class KOutlineTextMetric { public: OUTLINETEXTMETRIC * m_pOtm; KOutlineTextMetricCHDC hDC); -KOutlineTextMetricO; }: Конструктор класса KOutlineTextMetric получает структуру OUTLINETEXTMETRIC в блок памяти, выделенный из кучи. Деструктор освобождает память при выходе экземпляра класса из области видимости. Если вы смотрели программный код этого класса, возможно, вы обратили внимание на странную проверку смещения поля otmFiller. Самое коварное свойство структуры OUTLINETEXTMETRIC заключается в том, что ее поля должны выравниваться по границе двойных слов. Это ограничение не документировано и не форсируется заголовочными файлами Windows. Автор в течение нескольких дней пытался понять, почему структура OUTLINETEXTMETRIC, возвращаемая функцией GetOutlineTextMetrics, не соответствует объявлению. Ответ удалось найти лишь при просмотре двоичного дампа данных.
824 Глава 15. Текст Второе поле OUTLINETEXTMETRIC содержит структуру TEXTMETRIC длиной 4п + 1 байт. Разработчик этой структуры добавил однобайтовый заполнитель (otmFiller), чтобы следующая структура PANOSE выравнивалась по границе слова. Следует учитывать, что эта структура разрабатывалась для Windows 3.1 Win 16 API, когда в Windows впервые появилась поддержка шрифтов TrueType. Вероятно, при компиляции исходных текстов GDI было задано выравнивание полей структур по границе 4 байт. В результате поле otmFiller оказалось выровненным по границе двойного слова, а перед ним добавились три байта. Структура PANOSE имеет длину 10 байт; следующее поле otmfsSelection должно начинаться с границы двойного слова, поэтому перед ним добавляются еще два байта. Обычно при специальном выравнивании полей структуры в заголовочные файлы Windows включается директива #pragma pack, которая обеспечивает нужный тип выравнивания и отменяет тип выравнивания, заданный в пользовательской программе. Это гарантирует, что приложение будет работать с одними и теми же структурами Win32 API независимо от конфигурации проекта. В файле wingdi.h для структуры OUTLINETEXTMETRIC такая директива отсутствует. На момент написания книги выравнивание по границе DWORD в заголовочном файле имело место лишь в случае определения макроса _МАС. Если в вашем проекте требуется выравнивание полей структур по границе 1 или 2 байт и вы хотите использовать структуру OUTLINETEXTMETRIC, обязательно перейдите на выравнивание по границе двойного слова: #pragma pack(push, 4) #include<windows.h> #pragma pack(pop) Первое поле otmSize определяет размер всей структуры вместе с внедренными строками. За ним следует структура TEXTMETRIC (см. выше), в точности совпадающая с той, которая возвращается при вызове GetTextMetric. Третье поле otmFiller предназначалось для выравнивания следующей за ним структуры PANOSE по границе слова. Похоже, исходные тексты GDI компилировались с выравниванием полей структур по границе 4 или 8 байт, в результате чего после otmTextMetrics и перед otmFiller появились три скрытых байта. В поле otmPanoseNumber хранится метрика PANOSE для физического шрифта. За ним следуют два скрытых байта, обеспечивающих выравнивание следующего поля по границе двойного слова. Поле otmfsSelection описывает начертание шрифта, используя для этого комбинацию 6 флагов. Бит 0 (0x01) устанавливается для курсивного шрифта, бит 1 (0x02) — для подчеркивания, бит 2 (0x04) — для негатива, бит 3 (0x08) — для контурного шрифта, бит 4 (0x10) — для перечеркивания, бит 5 (0x20) — для полужирного и бит 6 (0x40) — для обычного начертания. У шрифта TrueType имеется атрибут с похожим именем, по которому можно определить исходный дизайн физического шрифта. Например, установка битов 5 и 6 означает, что физический шрифт является полужирным (то есть полужирное начертание не синтезировано средствами GDI). Похоже, GDI использует это поле несколько иначе; otmfsSelection представляет характеристики логического, а не физического шрифта, поэтому по значению поля otmfsSelection вы не сможете узнать, является ли физический шрифт полужирным. Надежным источником информации о характеристиках физического шрифта является структура PANOSE; например, по содержимому поля bLetterForm можно определить, является ли шрифт курсивным.
Получение информации о логическом шрифте 825 Поле otmf sType определяет лицензионные права на внедрение шрифта в документы (см. раздел «Установка и внедрение шрифтов» в главе 14). Следующие три поля связаны с выводом текстовой каретки. Для вертикальных шрифтов каретка представляет собой тонкую вертикальную линию, обозначающую позицию ввода следующего символа. В профессиональных текстовых редакторах каретка в курсивном шрифте выводится под углом. Поле otmltalicAngle задает угол наклона шрифта в десятых долях градуса против часовой стрелки от оси у. Для вертикальных шрифтов поле otmltalicAngle равно 0, а для курсивных шрифтов оно обычно содержит отрицательное число. Наклон каретки определяется соотношением полей otmsCharSlopeRise и otmsCharSlopeRun. Для вертикальных шрифтов поле OtmsCharSlopeRise равно 1, а поле OtmsCharSlopeRun равно 0, поэтому каретка выглядит как вертикальная линия. Например, у курсивного шрифта «Times New Roman» поле otmltalicAngle равно -164, поле OtmsCharSlopeRise — 24, а поле OtmsCharSlopeRun — 7. Тангенс 16,4° равен 0,2943, что очень близко к 7/24 (0,2917). Все три характеристики относятся к физическому шрифту; синтез курсивных шрифтов средствами GDI никак не влияет на них. Например, попробуйте поработать с курсивным начертанием шрифта Tahoma, у которого нет физического курсивного шрифта. WordPad выводит вертикальную каретку, а более сообразительный редактор Word — наклонную. Поле otmEMSquare содержит размер em-квадрата физического шрифта. Em-квадратом называется эталонная сетка, по которой конструируются глифы. Все точки в описании глифа представлены целочисленными координатами em-квадрата, поэтому увеличение размера em-квадрата обычно повышает качество глифов. Это поле обычно используется приложениями для определения параметров логической системы координат. За дополнительной информацией об определении глифов TrueType обращайтесь к главе 14. Поле otmAscent определяет типографский надстрочный интервал шрифта, поле otmDescent — типографский подстрочный интервал, а поле otmLineGap — типографский межстрочный интервал. GDI использует собственную интерпретацию надстрочных и подстрочных интервалов, а также внутреннего и внешнего зазора, которая в одних случаях совпадает с типографской интерпретацией, а в других отличается от нее. Еще одно различие состоит в том, что поле otmDescent обычно содержит отрицательную величину, поскольку подстрочный элемент расположен ниже базовой линии, а в Windows всегда используется модуль (абсолютное значение) этой метрики. Группа полей otmMacAscent, otmMacDescent и otmMacLineGap содержит вертикальные метрики шрифта для Macintosh. В документации Microsoft сказано, что поля otmCapEmHeight и otmXHeight не поддерживаются. Вероятно, поле OtmCapEmHeight должно содержать высоту прописной буквы без подстрочного элемента, а поле otmXHeight — высоту строчной буквы «х». Поле otmrcFontBox определяет ограничивающий прямоугольник всех глифов шрифта относительно базовой точки символа. Поле otmrcFontBox.left обычно имеет отрицательное значение, соответствующее минимальной А-метрике, а поле otmrcFontBox.bottom имеет отрицательное значение, соответствующее наибольшему подстрочному элементу. Поле otmusMinimumPPEM определяет минимальный допустимый размер в пикселах, до которого можно уменьшить em-квадрат по рекомендации разработчика
826 Глава 15. Текст шрифта. По значению этого поля можно судить о том, насколько хорошо инструкции привязки подходят для построения при малом размере символов. Обычное значение равно 9 или 12 пикселам. Поля otmptSubscriptSize и otmptSubscriptOffset определяют размер и позицию нижних индексов шрифта от базовой точки символа. Поля otmptSuperscriptSize и otmptSuperscriptOffset содержат аналогичные данные для верхних индексов. Поля otmsStrikeoutSize и otmsStrikeoutPosition определяют толщину горизонтальной черты при перечеркивании символов и ее положение относительно базовой линии. Поля otmsUnderscoreSize и otmsUnderscorePosition определяют толщину и положение относительно базовой линии черты, используемой для подчеркивания. На рис. 15.5 показаны некоторые новые метрики, содержащиеся в структуре OUTLINETEXTMETRIC, — а именно ограничивающий прямоугольник, метрики верхнего/нижнего индексов, подчеркивания, перечеркивания и наклона символов. Пять пунктирных линий обозначают уровни внешнего зазора, надстрочного элемента, внутреннего зазора, базовой линии и подстрочного элемента. Большой контур соответствует ограничивающему прямоугольнику шрифта и кажется слишком большим. Две серые полоски имитируют подчеркивание и перечеркивание. Два прямоугольника справа обозначают базовую точку и размеры верхних/нижних индексов. Наклонная линия представляет угол наклона символов, используемый при выводе каретки. Рис. 15.5. Метрики шрифта в структуре OUTLINETEXTMETRIC Последние четыре поля структуры OUTLINETEXTMETRIC содержат смещения имен семейства, гарнитуры и стиля, а также полного имени физического шрифта относительно начала структуры. Сказанное проще пояснить конкретным примером. Для полужирного курсивного шрифта Times New Roman существует физический шрифт, поэтому четыре последних поля OUTLINETEXTMETRIC содержат смещения строк Times New Roman, Times New Roman Bold Italic, Bold Italic и Monotype Times New Roman Bold Italic Version 2-76 (Microsoft).
Получение информации о логическом шрифте 827 Структура LOGFONT и метрики шрифта Программа Font, прилагаемая к этой главе, поможет вам лучше понять связь между логическими шрифтами, определяемыми структурой LOGFONT, и физическим шрифтом. Эта программа модифицирует стандартное диалоговое окно для выбора шрифта и выводит в нем всю информацию о шрифте. Win32 API содержит функцию ChooseFont для вывода стандартного диалогового окна, в котором пользователь выбирает логический шрифт. Эта функция позволяет приложению переопределить стандартный механизм обработки сообщений в диалоговом окне. Передавая функцию ChooseFont косвенного вызова, мы выводим дополнительную информацию о текущей структуре LOGFONT и метриках текущей реализации физического шрифта. В программе Font на прилагаемом компакт-диске диалоговое окно шрифта расширяется вправо, и в нем выводится иерархическое дерево со всеми атрибутами шрифта. Измененное диалоговое окно выбора шрифта показано на рис. 15.6. В левой части (исходное диалоговое окно выбора шрифта) выбран полужирный шрифт Times New Roman с кеглем 72 пункта. В дочернем иерархическом дереве (Tree- View) выводятся результаты вызовов GetTextFace, GetFontLanguagelnfo, GetTextCharset, GetTextCharset Info, GetTextMetrics и GetOutlineTextMetrics для структуры LOGFONT. На рис. 15.6 структура OUTLINETEXTMETRIC развернута, в ней видны вложенные структуры TEXTMETRIC и PANOSE и несколько начальных полей. Если выделить в левой части окна другую строку и щелкнуть на кнопке Apply, содержимое иерархического дерева синхронизируется с выбранной строкой. Рис. 15.6. Измененное диалоговое окно выбора шрифта с выводом шрифтовых метрик Точность шрифтовых метрик При создании логического шрифта его размеры определяются полями (или параметрами) ширины/высоты. При подборе физического шрифта его метрики em-квадрата масштабируются по размерам логического шрифта и возвращаются
828 Глава 15. Текст в структуре TEXTMETRIC или OUTLINETEXTMETRIC. Когда логический шрифт выбирается в контексте устройства, его ширина и высота интерпретируются в логических координатах данного контекста, поэтому все метрики TEXTMETRIC и OUTLINETEXTMETRIC задаются в логической системе координат данного контекста устройства. Метрические данные используются при разбиении длинного текста на строки в абзацах и при размещении текста на страницах. Если приложение поддерживает печать документа, очень важно, чтобы разрывы строк и страниц на экране точно соответствовали разрывам строк и страниц при печати документа на разных принтерах. Кроме того, разрывы строк и страниц должны сохраняться при выводе экрана в другом масштабе. Это одно из основных требований концепции WYSIWYG (What You See Is What You Get — «что видите, то и получаете»). Допустим, вы пишете простейший текстовый редактор, в котором весь текст выводится одним шрифтом. Возникает вопрос: как по заданному кеглю и высоте страницы вычислить количество строк, помещающихся на странице? Ниже приведен один из возможных вариантов. int LinesPerPageCHDC hDC, int nPointSize, int nPageHeight) { KLogFont lf(-PointSizetoLogical(hDC, nPointSize), "Times New Roman"); HFONT hFont = lf.CreateFontO; HGDIOBJ hOld = SelectObjectChDC. hFont); TEXTMETRIC tm; GetTextMetncsChDC. & tm); int linespace = tm.tmHeight + tm.tmExternalLeading; SelectObjectChDC. hOld); DeleteObject(hFont); POINT P[2] = { 0. 0, 0, nPageHeight }; // Координаты устройства DPtoLP(hDC, P, 2); // Логические координаты nPageHeight = abs(P[l].y-P[0].y); ejinespace = linespace; e_pageheight = nPageHeight; e_externalleading = tm.tmExternalLeading; return (nPageHeight + tm.tmExternalLeading) / linespace; } Функция LinesPerPage получает манипулятор контекста устройства, кегль шрифта и высоту страницы в системе координат устройства (в пикселах). Она преобразует кегль в логические координаты, создает логический шрифт, выбирает его в контексте устройства и запрашивает вертикальные метрики шрифта. Расстояние между двумя строками вычисляется как сумма высоты и внешнего зазора. После преобразования высоты страницы (за вычетом полей) в логические координаты количество строк на странице вычисляется по формуле (высота страницы + внешний зазор)/расстояние между строками. Внешний зазор прибавляется к высоте страницы, поскольку N строк разделяются всего (N - 1) внешними зазорами.
Получение информации о логическом шрифте 829 Следующий вопрос: насколько точны подобные вычисления? В табл. 15.1 приведены примеры данных для высоты страницы, равной 10 дюймам (11-дюймовый лист формата Letter с полями по 0,5 дюйма сверху и снизу). Таблица 15.1. Разрывы строк Устройство Экран (96 dpi) Экран (120 dpi) Принтер (360 dpi) Принтер (600 dpi) Режим отображения ММ_ТЕХТ MML0ENGLISH MMTWIPS MMJEXT MM_L0ENGLISH MMTWIPS MM TEXT MM TEXT Логическая высота страницы 960 1050 15118 1200 1312 18897 3600 6000 Внешний зазор 1 1 9 1 1 И 2 4 Логический межстрочный интервал 16 17 245 20 22 310 59 98 Строк на страницу 60,0625 (60) 61,8235 (61) 61,74286 (61) 60,05 (60) 59,6818 (59) 60,9935 (60) 61,0508 (61) 61,2653 (61) Как видно из таблицы, в зависимости от логического разрешения экрана, режима отображения и устройства (экран или принтер) по шрифтовым метрикам, возвращаемым в структуре TEXTMETRIC, на простой вопрос о количестве строк в области высотой 10 дюймов можно получить три разных ответа: 59, 60 и 61. Обратите внимание: функция LinesPerPage усекает дробный результат до целой части, поскольку неполные строки не выводятся на экране. Даже если бы мы воспользовались округлением до ближайшего целого, все равно получилось бы три разных ответа: 60, 61 и 62. Также следует учитывать, что даже в одном стандартном режиме отображения (MML0ENGLISH или MMTWIPS) на одном и том же компьютере можно получить разные результаты при переходе от режима мелких шрифтов (96 dpi) к режиму крупных шрифтов (120 dpi). Вся суть проблемы заключается в том, что ошибки появляются при масштабировании метрических данных физического шрифта в логические координаты, используемые в контексте устройства (особенно если учесть, что логические координаты представляются целыми числами, как в Windows GDI). Как говорилось выше, кегль шрифта соответствует метрике «надстрочный интервал + подстрочный интервал - внутренний зазор». Для физических шрифтов TrueType эта характеристика совпадает с размером em-квадрата. Таким образом, координаты в описании глифа масштабируются по заданному кеглю по очень простой формуле. Для объекта логического шрифта, созданного функцией CreateFontIndirect, с высотой (надстрочный интервал + подстрочный интервал - внутренний зазор) height и шириной width точка (х,у) в исходном описании глифа масштабируется в точку с координатами (х * width/emsquaresize, у * height/emsquaresize)
830 Глава 15. Текст Подобным образом масштабируются не только точки в описании глифа, но и другие шрифтовые метрики — надстрочные и подстрочные интервалы, толщина перечеркивания и т. д. Дробные результаты преобразуются в целые посредством округления. Например, шрифт Times New Roman определяется в em-квадрате размера 2048, надстрочный интервал равен 1825, подстрочный интервал — 443, а внешний зазор — 87. Для шрифта с кеглем 10 пунктов на экране с разрешением 96 dpi поле высоты в структуре L0GF0NT будет равно -13; функция GetTextMetrics присваивает полю tmAscent значение 12, полю tmDescent — значение 3, а полю tmExternal - Leading — значение 1. Точные значения равны 11 + 1197/2048 (1825 х 13/2048), 2 + 1663/2048 (443 х 13/2048) и 1131/2048 (87 х 13/2048). При округлении до ближайших целых погрешности составляют 0,4155, 0,188 и 0,4478. При большом количестве строк ошибки накапливаются, и иногда это может привести к тому, что на странице вместо 59 строк разместится 60 или даже 61 строка. Хотя погрешность всегда меньше 1, при сравнении с метрическими размерами шрифта относительная погрешность оказывается довольно большой. В приведенном примере целочисленная высота полной строки (tmAscent + tmDescent + tmExternal - Leading) на 6,5 % отличается от ее точного значения. Логическая система координат и точность Существует два возможных пути к повышению точности метрик шрифтов для заданного контекста устройства. Первый способ — определение логической системы координат с высоким логическим разрешением — основан на том, что метрики в структурах TEXTMETRIC и 0UTLINETEXTMETRIC задаются в логических координатах. Например, если переключить экранный контекст с разрешением 96 dpi в режим MM_ANISOTROPIC, задать габариты окна (100,100) и габариты области просмотра (1,1), логическая система координат будет иметь разрешение 96 dpi. Иначе говоря, перемещение на 9600 единиц в логических координатах будет соответствовать 1 логическому дюйму на экране. Казалось бы, такая система координат должна обеспечивать значительно большую точность, чем контексты принтеров с разрешением 600 dpi, получившие столь широкое распространение. Как ни странно, на практике все получается совсем не так. Увеличение разрешения в логической системе координат не приводит к повышению точности шрифтовых метрик. Похоже, графический механизм допускает громадную ошибку, сначала масштабируя метрики в координатах устройства, а затем — в логических координатах. Хотя не исключено, что результаты масштабирования на первом этапе сохраняются в формате с фиксированной точкой, при масштабировании в логическую систему координат с высоким разрешением особых улучшений не наблюдается. Ниже приведена небольшая функция, которая проверяет, как разрешение логической системы координат влияет на точность текстовых метрик. void Test_LC(void) { HDC hDC - GetDC(NULL); SetMapMode(hDC. MM_ANISOTROPIC); SetViewportExtEx(hDC, 1, 1. NULL); TCHAR mess[MAX_PATH];
Получение информации о логическом шрифте 831 mess[0] = 0; for (int i-1: i<=64; i*=2) { SetWindowExtEx(hDC. i. i. NULL); KLogFont lf(-PointSizetoLogical(hDC. 24). "Times New Roman"); HFONT hFont = lf.CreateFontO; SelectObjectChDC. hFont); TEXTMETRIC tm; GetTextMetricsChDC, & tm); wsprintf(mess + _tcslen(mess). "%6:l lfHeight=£d. tmHeight=$d\n". i, If.mjf.IfHeight. tm.tmHeight); SelectObjectChDC. GetStockObject(ANSI_VAR_FONT)); DeleteObjectChFont); } ReleaseDCCNULL. hDC): MessageBoxCNULL. mess. "LCS vs. TEXTMETRIC". MB_0K); } При каждой итерации функция последовательно увеличивает логическое разрешение, создает шрифт с кеглем 24 пункта, выбирает его в контексте устройства и запрашивает высоту шрифта. На экране с логическим разрешением 96 dpi поле IfHeight принимает значения -32, -64 и т. д. до -2048, а поле tmHeight изменяется от 36, 72 до 2304. Значение tmHeight тоже каждый раз удваивается. Из чего же следует, что этот результат неверен? Попробуйте создать шрифт с кеглем 24 х 64 = 1536 пунктов в измененном диалоговом окне выбора шрифта, показанном на рис. 15.6. Поле IfHeight сохраняет то же значение 2048, но поле tmHeight равно 2268, а не 2304. Итак, увеличение разрешения логической системы координат не повышает точности шрифтовых метрик — по крайней мере, в текущей реализации GDI. Кегль и точность Второй способ увеличения логического размера шрифта для повышения точности шрифтовых метрик предельно прост — нужно увеличить кегль шрифта. Ниже приведена аналогичная функция для проверки связи между кеглем и точностью шрифтовых метрик. void Test_Point(void) { HDC hDC = GetDC(NULL); TCHAR mess[MAX_PATH*2]; mess[0] = 0; for (int i-1: i<=64; i*-2) { KLogFont lf(-PointSizetoLogical(hDC. 24*i). "Times New Roman"); HFONT hFont - lf.CreateFontO: SelectObjectChDC. hFont);
832 Глава 15. Текст TEXTMETRIC tm; GetTextMetrics(hDC, & tm); wsprintf(mess + _tcslen(mess), "%6 point lfHeight=%d. tmHeight=Ud\n", 24*i . If.mJf.lfHeight. tm.tmHeight); SelectObject(hDC, GetStockObject(ANSI_VAR_FONT)); DeleteObject(hFont); } ReleaseDC(NULL, hDC); MessageBox(NULL, mess, "Point Size vs. TEXTMETRIC", MB_0K); } При увеличении кегля до 1536 пунктов поле If Height равно -2048, а в поле tmHeight возвращается 2268. Кстати говоря, 2048 — это размер em-квадрата шрифта Times New Roman, a 2268 — фактическая высота шрифта, хранящаяся в таблице метрик физического шрифта TrueType. Мы приходим к неприятному заключению: для получения наиболее точных шрифтовых метрик необходимо создать логический шрифт, высота которого равна размеру em-квадрата (с обратным знаком). В базовых шрифтах Windows размер em-квадрата равен 2048; также часто встречается значение 4096. В соответствии со спецификацией шрифтов TrueType максимальный размер em-квадрата равен 16 384. Следующая функция создает эталонный шрифт для существующего логического шрифта. При создании эталонного шрифта указывается высота, равная размеру em-квадрата физического шрифта, что позволяет получить наиболее точные значения шрифтовых метрик. HFONT CreateReferenceFont(HFONT hFont, int & emsquare) { L0GF0NT If; OUTLINETEXTMETRIC otm[3]; // С учетом строк HDC hDC = GetDC(NULL); HGDIOBJ hOld = SelectObject(hDC, hFont): int size = GetOutlineTextMetrics(hDC, sizeof(otm), otm); SelectObject(hDC, hOld); ReleaseDC(NULL, hDC); if ( size ) // TrueType { GetObject(hFont, sizeof(lf), & If); emsquare = otm[0].otmEMSquare; // Получить размер ЕМ-квадрата If.IfHeight = - emsquare; // Соответствие 1:1 If.lfWidth =0; // Исходные пропорции return CreateFontIndirect(&lf); } else return NULL; }
Простой вывод текста 833 Помимо функций, упоминавшихся в этом разделе, существуют и другие функции получения метрических данных шрифтов. Они будут рассмотрены ниже, при обсуждении вывода и форматирования текста средствами GDI. Простой вывод текста Контекст устройства обладает рядом атрибутов, используемых всеми функциями вывода текста. К числу этих атрибутов относится цвет текста и цвет фона, режим заполнения фона, тип выравнивания текста и т. д. COLORREF SetTextColor(HDC hDC, COLORREF crColor); COLORREF GetTextColor(HDC hDC); COLORREF SetBkColor(HDC hDC, COLORREF crColor); COLORREF GetBkColorCHDC hDC); int SetBkModeCHDC hDC. int iBkMode); int GetBkMode(HDC hDC); Функция SetTextCol or задает цветовую ссылку (COLORREF), которая используется для вывода основных пикселов текстовой строки. Основными считаются пикселы, которые образуют внутренние области глифов в строке. Функция SetTextCol or возвращает предыдущий цвет текста для заданного контекста устройства. На всякий случай напоминаем, что цветовые ссылки задаются тремя способами: RGBUpacHbM, зеленый, синий), PALETTEINDEX(iiHfleKC) и PALETTERGBCкрасный, зеленый, синий). Функция GetTextColor возвращает текущий цвет текста. В прямоугольнике, определяемом начальной точкой вывода и шириной/высотой строки, пикселы, не относящиеся к числу основных, называются фоновыми пикселами. Функция SetBkColor задает цветовую ссылку, используемую при выводе фоновых пикселов, и возвращает предыдущий цвет фона. Функция GetBkCol or возвращает текущий цвет фона. Иногда применение фонового цвета при выводе текста оказывается нежелательным. Например, если вы накладываете текстовую строку на фотографию и цвет текста достаточно сильно контрастирует с фоновым изображением, возможно, вы предпочтете не выводить фоновые пикселы. Функция SetBkMode задает для контекста устройства специальный атрибут — режим заполнения фона; этот атрибут управляет прорисовкой фоновых пикселов. В GDI определены два режима заполнения фона: в режиме OPAQUE фон заполняется фоновым цветом, а в режиме TRANSPARENT он остается без изменений. Функция GetBkMode возвращает текущий режим заполнения фона для контекста устройства. Выравнивание текста Наконец-то мы добрались до простейшей функции вывода текстовой строки в контексте устройства. Заодно будут рассмотрены две функции, управляющие выравниванием выводимого текста: BOOL TextOutCHDC hDC, int nXStart. int nYStart, LPCTSTR IpString, int cbString); UINT SetTextAlign(HDC hDC. UINT fMode); UINT GetTextAlignCHDC hDC);
834 Глава 15. Текст Функция TextOut выводит текстовую строку в заданной позиции, используя текущие значения управляющих атрибутов — шрифт, выбранный в контексте устройства, цвета текста и фона, режим заполнения фона и т. д. Выводимая строка задается указателем на первый символ и количеством символов. Таким образом, выводимый текст не обязательно завершать нуль-символом. Символы строки должны входить в набор символов текущего шрифта. Например, при использовании набора ANSI все управляющие символы выводятся глифом по умолчанию (глифом отсутствующего символа). Точная интерпретация параметров nXStart и nYStart определяется специальным атрибутом контекста устройства — типом выравнивания текста. Тип выравнивания задается в виде комбинации нескольких флагов (табл. 15.2). Таблица 15.2. Выравнивание текста Группа Флаг Описание Верхний край (надстрочная линия) текста совмещается с nYStart Базовая линия текста совмещается с nYStart Нижний край (подстрочная линия) текста совмещается с nYStart Левый край текста совмещается с nXStart Горизонтальный центр текста совмещается с nXStart Правый край текста совмещается с nXStart Использовать nXStart, nYStart; текущая позиция не обновляется при выводе текста Игнорировать nXStart, nYStart; использовать текущую позицию. Текущая позиция обновляется при каждом выводе текста Текст выводится справа налево. В Windows 2000 этот порядок возможен лишь при реализованной поддержке арабского языка или иврита. Ранее этот флаг поддерживался лишь в версиях ОС для арабского языка и иврита Флаги выравнивания текста делятся на четыре группы и управляют выравниванием по вертикали и горизонтали, обновлением текущей позиции и возможностью вывода текста справа налево в иврите/арабском языке. Флаги разных групп объединяются логической операцией OR. По умолчанию используется значение TA_T0P | TA_LEFT | TAJ0UPDATECP. При установке флага TAJJPDATECP GDI игнорирует начальную позицию, заданную координатами (nXStart, nYStart). Текст выводится с текущей позиции контекста устройства, причем каждая операция вывода обновляет горизонтальную координату текущей позиции. По вертикали ТА_Т0Р TABASELINE ТА_В0ТТ0М По горизонтали TA_LEFT TA_CENTER TA_RIGHT Обновление TA_N0UPDATECP ТА UPDATECP Справа налево TA_RTLREADING
Простой вывод текста 835 В следующем фрагменте демонстрируются некоторые интересные комбинации флагов выравнивания текста. SetTextColor(hDC, RGB(0, 0. 0)); // Черный SetBkColor(hDC. RGB(0xD0. OxDO, OxDO)); // Серый SetBkMode(hDC, OPAQUE); // Непрозрачный int x = 50; int у = 110; const TCHAR * mess = "Align"; for (int i=0: i<3; i++. x+=250) { const UINT Align[] = { TAJOP | TA_LEFT, TAJASELINE | TA_CENTER. TA_B0TT0M | TA_RIGHT }; SetTextAlign(hDC, Align[i] | TAJJPDATECP); MoveToEx(hDC, x, y, NULL); // Установка текущей позиции TextOut(hDC, x. у, mess. _tcslen(mess)); POINT cp; MoveToEx(hDC, 0, 0. & cp); // Получение текущей позиции Line(hDC, cp.x-5. cp.y+5, cp.x+5, cp.y-5); // Пометка текущей позиции Line(hDC, cp.x-5. cp.y-5. cp.x+5. cp.y+5); Line(hDC. x. y-75. x. y+75); // Вертикальный ориентир SIZE size; GetTextExtentPoint32(hDC. mess. _tcslen(mess). & size); Box(hDC. x. y, x + size.ex. у + size.су); } x - 250 * 3; Line(hDC. x-20. у. х+520. у); // Горизонтальный ориентир В этом фрагменте назначается черный цвет текста и светло-серый цвет фона при непрозрачном режиме заполнения фона; текст выводится в светло-сером прямоугольнике, обозначающем границы области вывода. Затем программа трижды выполняет тело цикла, демонстрируя разные комбинации горизонтального и вертикального выравнивания. Начальная точка каждого вызова отмечена перекрестием, а конечная точка обозначается наклонным крестиком. Пример приведен на рис. 15.7. При установке флагов ТАТОР | TALEFT с начальной точкой совмещается левый верхний угол текстовой области. Если установлен флаг TAJJPDATECP, начальная точка находится в текущей позиции контекста и обновляется координатами правого верхнего угла текстовой области. При установке флагов TABASELINE | TA_CENTER с начальной точкой совмещается точка пересечения базовой линии и горизонтального центра текстовой области. Если установлен флаг TAJJPDATECP, начальная точка находится в текущей позиции контекста, которая при выводе не обновляется.
836 Глава 15. Текст ТА_ТОР | TAJ.EFT TA_BASELINE | TA_CENTER TA_BOTTOM | TA_RIGHT № Allffn Alien Рис. 15.7. Выравнивание текста При установке флагов ТАВОТТОМ | TARIGHT с начальной точкой совмещается правый нижний угол текстовой области. Если установлен флаг TAJJPDATECP, начальная точка находится в текущей позиции контекста и обновляется координатами левого нижнего угла текстовой области. Вывод текста справа налево Мы привыкли, что текст выводится слева направо, а страница заполняется горизонтальными строками сверху вниз. Однако это лишь одна из многих систем письма, существующих в мире. В арабском языке и иврите большая часть текста пишется справа налево, хотя страница также заполняется горизонтальными строками сверху вниз. В традиционной японской и китайской письменности иероглифы пишутся сверху вниз, а вертикальные столбцы текста заполняют страницу справа налево. И в наши дни традиционная письменность используется во многих печатных изданиях — например, в газетах, журналах, художественной литературе. А в монгольском языке символы также записываются в вертикальные столбцы, но страница заполняется слева направо. Направление письма, стандартное для латиницы и кириллицы, хорошо поддерживается в GDI на уровне базовых средств вывода текста. Как будет показано ниже в этой главе, вертикальную письменность можно имитировать путем поворота и при помощи вертикальных шрифтов. С поддержкой вывода справа налево дело обстоит сложнее. Не существует специализированных версий Windows 2000 для других стран; для всего мира используется один и тот же двоичный код, а это означает, что в системе должна присутствовать встроенная поддержка других языков, включая языки с письменностью справа налево. При разработке Windows 2000 обеспечивалась поддержка чтения и создания документов на разных языках. Впрочем, поддержка других языков относится к числу дополнительных возможностей и реализуется отдельно с помощью панели управления (рис. 15.8). После установки системы поддержки других языков, включающей шрифты, файлы преобразования кодировок, методы ввода и т. д., Windows 2000 позволит читать и создавать документы на арабском и армянском языке, на языках стран Центральной Европы и кириллице, на грузинском, греческом, иврите, санскрите, китайском (в упрощенной и традиционной письменности), на тайском, ту-
Простой вывод текста 837 рецком, вьетнамском, на языках Западной Европы и американском диалекте английского. Шш& j Number | tuirem^ | Many редев* mw&l **&№ $«№&, and date& Set fa&hse j English (United States) t'^y** 1Ш Г $^рЪ№№&М*№Ш№ и|ШШШ«1 El 10001 (MAC - Japanese) El 10002 (MAC - Traditional Chinese Big5) El Ю003(MAC-Korean) El Ю004 (MAC-Arabic) El Ю005 (MAC-Hebrew) □ 10006 (MAC -Greek I) OK С&Ы Your дадо**здгё&**й & m& Ш wl* ttommto fo mtifa languages. EI Hebrew El Indic El Japanese El Korean El Simplified Chinese j $0tdefatdL. OK twee) Рис. 15.8. Установка системы поддержки других языков На уровне приложения при создании окна функцией CreateWindowEx флаг WS_EX_RTLREADING указывает, что текст должен выводиться справа налево. Флаг WSEXRIGHT присваивает окну общий набор атрибутов выравнивания по правому краю. В Windows 2000 появился новый флаг WS_EX_LAY0UTRTL, при котором базовая точка окна перемещается к правому краю, а горизонтальные координаты увеличиваются справа налево. На уровне GDI в Windows 98 и Windows 2000 появился новый атрибут контекста устройства — раскладка (layout), для работы с которым используются две функции: DWORD SetLayoutCHDC hDC, DWORD dwLayout); DWORD GetLayout(HDC hDC); Для атрибута раскладки определены всего два флага. Флаг LAY0UT_BITMAP- 0RIENTATI0NPRESERVED запрещает зеркальное отражение растров, выводимых функциями BitBlt, StretchBlt и т. д.; флаг LAY0UTRTL задает общее направление горизонтальной раскладки справа налево. В тернарные растровые операции был добавлен новый бит NOMIRRORBITMAP (0x80000000), запрещающий горизонтальное отражение растров. При выводе текста флаг TARTLREADING сообщает, что GDI следует расположить текст в соответствии с правилами чтения справа налево. Практическая реализа-
838 Глава 15. Текст ция вывода справа налево в Windows 2000 сосредоточена в новом компоненте GDI — UniScribe, API которого позволяет точно задать основные характеристики текста при выводе. Рассмотрим простой пример использования флагов LAY0UT_RTL и TA_RTLREADING. void Demo_RTL(HDC hDC, const RECT * rcPaint) { KLogFont lf(-PointSizetoLogical(hDC. 36). "Lucida Sans Unicode"); lf.mjf.IfCharSet - ARABIC_CHARSET; lf.mjf .IfQuality - ANTIALIASED_QUALITY; KGDIObject font (hDC. If .CreateFontO); TEXTMETRIC tm: GetTextMetrics(hDC. & tm); int linespace = tm.tmHeight + tm.tmExternalLeading; const TCHAR * mess - "1-360-212-0000 \xD0\xDl\xD2": for (int i=0; i<4; i++) { if ( i & 1 ) SetTextAlign(hDC. TAJOP | TA_LEFT | TA_RTLREADING); else SetTextAlign(hDC. TAJOP | TA_LEFT); if ( i & 2 ) SetLayout(hDC. LAYOUT_RTL); else SetLayout(hDC. 0); Text0ut(hDC. 10. 10 + linespace * i. mess. Jxslen(mess)); } } Функция Demo_RTL создает логический шрифт для арабского набора символов, используя гарнитуру Lucida Sans Unicode. На экран выводятся четыре строки с одним и тем же текстом, но с разными комбинациями флагов. Результаты показаны на рис. 15.9. 1-360-212-0000 j> j> 0000-212-360-1 jjb 0000-212-360-1 1-360-212-0000 j> Рис. 15.9. RTLJ.AYOUT и TAJOLREADING Первая строка выводится слева направо и выравнивается по левому краю — ничего необычного. Вторая строка выводится справа налево со стандартной ле-
Простой вывод текста 839 восторонней раскладкой (флаг TARTLREADING). Обратите внимание: GDI при помощи UniScribe разбивает текстовую строку на слова и располагает их в порядке, соответствующем чтению справа налево. Строка выводится в той же позиции, но с обратным порядком следования символов. Третья и четвертая строки выглядят похоже, но они выводятся после установки флага RTL_LAYOUT в раскладке контекста устройства. Без флага TA_RTLREADING текст выравнивается по правому краю клиентской области и выводится справа налево. При выравнивании с флагом TARTLRADING текст возвращается к стандартному порядку вывода. Таким образом, флаг TARTLREADING меняет направление чтения на противоположное. Дополнительные интервалы Функция TextOut обеспечивает выравнивание текста по левому/правому краю и по центру, но не поддерживает выравнивание по ширине (выключку). Выравнивание по ширине обычно означает вывод текста в горизонтальной области таким образом, что левый край текста выравнивается по левой стороне области, а правый край — по правой стороне. В процессе выравнивания по ширине пробелы в строке могут увеличиваться, обеспечивая совмещение правого края с правой стороной области. В GDI выравнивание по ширине состоит из нескольких шагов. Сначала GDI вычисляет точную ширину текстовой строки и сравнивает ее с шириной области вывода, чтобы узнать, сколько места необходимо компенсировать. Затем под- считывается количество пробелов в строке, передаваемое при вызове функции SetTextJustification GDI. На последнем шаге функция TextOut выводит строку, выровненную по ширине. У контекста устройства имеется специальный атрибут, управляющий расстоянием между символами, — дополнительный межсимвольный интервал (character extra). Дополнительный межсимвольный интервал определяет целочисленную величину в логической системе координат — размер дополнительного промежутка, добавляемого после каждого символа при выводе текста. Ниже перечислены функции GDI, предназначенные для вычисления размеров текста, настройки межсимвольных интервалов и выравнивания. int SetTextCharacterExtra(HDC hDC, int nCharExtra); int GetTextCharacterExtra(HDC hDC); BOOL GetTextExtentPoint32(HDC hDC. LPCTSTR IpString. int cbString, LPSIZE IpSize); BOOL SetTextJustificationCHDC hDC, int nBreakExtra, int nBreakCount); По умолчанию дополнительный межсимвольный интервал в контексте устройства равен 0. Функция SetTextCharacterExtra присваивает ему новое целочисленное значение в логических координатах, возвращая предыдущее значение. Функция GetTextCharacterExtra просто возвращает текущее значение межсимвольного интервала. Межсимвольные интервалы могут использоваться как для разрядки, так и для уплотнения текста. Функция GetTextExtentPoint32 возвращает размеры символьной строки в логической системе координат. Высота равна высоте текущего шрифта, а ширина
840 Глава 15. Текст определяется шириной отдельных символов, межсимвольными интервалами и параметрами выравнивания по ширине. Функция SetTextJustification задает величину дополнительного интервала, распределяемого между N ограничителями слов. Обычно ограничителем слова является пробел, но любой шрифт может переопределить этот символ. Ограничитель слова хранится в поле tmBreakChar структуры TEXTMETRIC. Ниже приведен небольшой пример использования функций SetTextCharac- terExtra и GetTextExtentPoint32. const TCHAR * mess = "Extra"; SetTextAlign(hDC, TA_LEFT | TAJOP); for (int i=0: i<3; i++) { SetTextCharacterExtraChDC, 1*10-10); TextOut(hDC, x. y. mess. _tcslen(mess)); SIZE size; GetTextExtentPoint32(hDC. mess. _tcslen(mess). & size); Box(hDC. x. y. x + size.ex. у + size.су): у += size.су + 10; } SetTextCharacterExtra(hDC. 0); // Сбросить межсимвольный интервал В этом фрагменте одна и та же строка выводится три раза с межсимвольными интервалами -10, 0 и 10. Функция GetTextExtentPoint32 возвращает размеры текстовой области, которая слева на рис. 15.10 обведена рамкой. Из рисунка видно, что GDI поддерживает как положительные, так и отрицательные межсимвольные интервалы. Межсимвольный интервал применяется после вывода символа. Если межсимвольный интервал отрицателен, между значением ширины текста, возвращаемым функцией GetTextExtentPoint32, и фактическим размером ограничивающего текст прямоугольника возникает расхождение в размере одного отрицательного интервала. The The quick The quick brown The quick brown fox The quick brown fox jumps The quick brown fox jumps over The quick brown fox jumps over the Thequickbrownfoxjumpsoverthelazy Tbequickbrownfoxjumpsoverthelazydog, The quick brown fox jumps over the lazy dog. Рис. 15.10. Дополнительные межсимвольные интервалы и расширение промежутков между словами Ниже все перечисленные этапы выравнивания текста по ширине объединены в одну удобную функцию TextOutJust. Функция вычисляет размеры текста, под-
Простой вывод текста 841 считывает количество символов-ограничителей, настраивает выравнивание текста по ширине в контексте устройства, после чего выводит выровненную строку. BOOL TextOutJust(HDC hDC, int left, int right, int y. LPCTSTR IpStr. int nCount. bool bAllowNegative, TCHAR cBreakChar) { SIZE size; SetTextJustification(hDC. 0, 0); GetTextExtentPoint32(hDC. IpStr. nCount. & size): int nBreak = 0; for (int i=0; i<nCount; i++) if ( lpStr[i]==cBreakChar ) nBreak ++; int breakextra = right - left - size.ex; if ( (breakextraO) && ! bAllowNegative ) breakextra =0; SetTextJustification(hDC, breakextra. nBreak); return TextOut(hDC. left. y. IpStr. nCount); } Правая часть рис. 15.10 иллюстрирует пример использования функции Text- OutJust. По ширине выравниваются части предложения — сначала одно слово, потом два, три слова и т. д. до полного текста. Как видно из рисунка, при выводе одного слова символы-ограничители в строке отсутствуют. При выводе двух слов расширяется только промежуток между словами, чтобы второе слово выровнялось по правой границе блока. С увеличением количества слов промежутки увеличиваются в равной степени. При некотором количестве слов промежутки между словами начинают сокращаться. Когда величина этих промежутков уменьшается до 0, текст начинает «перетекать» через правую границу, и тогда строку приходится разбивать на абзацы. Для сравнения последняя строка выведена со стандартными промежутками между словами и символами. Ширина символа При использовании крупного шрифта можно заметить, что «левый край» текстовой области, совмещаемый с параметром nXStart функции TextOut при установке флага TALEFT, в действительности несколько отходит от левого края глифа. Точное расположение символов по горизонтали определяется их шириной и метриками ABC шрифтов TrueType/Open Type. Ниже перечислены функции GDI, возвращающие информацию о ширине символов и метриках ABC шрифта, выбранного в контексте устройства. typedef struct _ABC { int abcA; UINT abcB; int abcC; } ABC; typedef struct _ABCFL0AT {
842 Глава 15. Текст FLOAT abcfA; FLOAT abcfB; FLOAT abcfC; } ABC; BOOL GetCharABCWidths(HDC hDC. UINT uFirstChat. UINT uLastChar. LPABC); BOOL GetCharABCWidthsFloatCHDC hDC. UINT uFirstChat. UINT uLastChar, LPABCFLOAT lpABCF); BOOL GetCharWidth32(HDC hDC. UINT iFirstChar. UINT ILastChar. LPINT lpBuffer): BOOL GetCharWidthFloatCHDC hDC. UINT iFirstChar. UINT iLastChar. PFLOAT pxBuffer); Функция GetCharABCWidths заполняет массив структурами ABC для всех символов в заданном интервале. Структура ABC определяет ширину символа в виде трех составляющих. Метрика А (левый отступ) определяет смещение начала глифа от текущей позиции курсора. Метрика В (ширина глифа) определяет ширину самого глифа. Метрика С (правый отступ) определяет смещение от конца глифа до следующей позиции курсора. Метрика В является целым без знака, поэтому ее значение должно быть положительным. Метрики А и С относятся к знаковому целому типу и могут принимать отрицательные значения. Функция GetChar- ABCWidthsFloat аналогична GetCharABCWidths за одним исключением: в возвращаемой ею структуре ABCFL0AT вместо целых чисел используются вещественные числа одинарной точности. Значения, возвращаемые GetCharABCWidths и GetCharWidthsFloat, задаются в логической системе координат. Как ни печально, структура ABCFL0AT не обеспечивает повышения точности по сравнению со структурой ABC, кроме случаев, когда отображение из системы координат устройства в логическую систему координат осуществляется с дробными коэффициентами. Иначе говоря, обе функции берут значения ширины из внутренней таблицы, содержимое которой масштабируется по размерам текущего шрифта в системе координат устройства; для структуры ABC — по целым, а для структуры ABCFL0AT — по вещественным числам в логической системе координат. Например, в режиме отображения MMJTEXT обе структуры будут содержать одинаковые значения в разных форматах. Функция GetCharABCWidths работает только со шрифтами ТшеТуре/ОрепТуре, а функция GetCharABCWidthsFloat также поддерживает растровые и векторные шрифты. Для растровых и векторных шрифтов, глифы которых не имеют метрик А и С, функция GetCharABCWidthsFloat просто заполняет соответствующие поля нулями. Для любого шрифта, поддерживаемого системой Windows, всегда можно вызвать функцию GetCharWidth32 и заполнить массив значениями полной ширины символов из заданного интервала. Для шрифтов ТшеТуре/ОрепТуре полная ширина равна сумме метрик А, В и С, а для растровых и векторных шрифтов она равна ширине символа. Функция GetCharWi dthFl oat представляет собой вещественную версию GetCharWi dth32. Похоже, реализация GetCharABCWidthsFloat в Windows 2000 содержит ошибку — возвращаемые значения составляют 1/16 от фактических. Впрочем, приложения все равно не используют эту функцию.
Простой вывод текста 843 Роль метрик ABC при выводе текста, а также их связь с размерами текстовой области, возвращаемыми функцией GetTextExtentPoint32, иллюстрирует рис. 15.11. Т(0х66):-34 129-32 V(0x6f): б 91 б V(0x6e):7 101 5 'Г(0x74): 9 63 -5 ABC widths sum: 346 GetTextExtent346 218 GetTextABCExtent-34 385 -5 Рис 15.11. Метрики ABC при выводе текста На рисунке слово «font» выведено курсивным шрифтом с кеглем 144 пункта. Курсивное начертание выбрано из-за того, что в нем глифы обладают более заметными отрицательными метриками А и С, особенно для букв «f», «j», «t» и т. д. Длинная полоса в верхней части рисунка обозначает начальную точку вывода текста и его горизонтальный размер, возвращаемый функцией GetTextExtent- Point32. Справа приведены метрики ABC для каждого символа, их сумма и размеры текста. Длинные вертикальные линии обозначают начальную и конечную точку каждого символа. Расстояние между двумя соседними линиями равно полной ширине символа (сумме метрик ABC). Как видите, ширина символьной строки равна сумме полных значений ширины всех символов, возможно — с добавлением дополнительных межсимвольных интервалов и промежутков между словами. Отрезки, расположенные над символами, обозначают метрики А каждого символа; затушеванный прямоугольник соответствует отрицательному значению. Отрезки, расположенные под символами, обозначают метрики С. Для первой буквы «f», обладающей значительной отрицательной метрикой А, левый край глифа смещается на 34 пиксела влево. Хотя метрика В символа «f» достаточно велика, отрицательная метрика С заметно приближает начальную точку буквы «о». Буквы «о» и «п» обладают положительными метриками А и С. У буквы «t» метрика А положительна, а метрика С отрицательна. К счастью, при выводе строки средствами GDI значения метрик ABC учитываются автоматически и обеспечивают правильное позиционирование символов в строке, не требуя дополнительных усилий со стороны приложения. Впрочем, не обошлось и без проблем: если используемый шрифт имеет отрицательные метрики А или С, текстовая строка не начинается с точки, заданной приложением, и не завершается в позиции, возвращаемой функцией GetTextExtentPoint32.
844 Глава 15. Текст- Метрика А первого символа и метрика С последнего символа строки могут выходить за пределы области, в которой выводиться текстовая строка. Погрешности при обработке отрицательных метрик А и С вызывают ряд проблем. Прежде всего, это может привести к случайному отсечению частей глифов. Запустите WordPad, выберите курсивный шрифт Times New Roman с кеглем 72 пункта и введите букву «f» — ее часть, соответствующая отрицательной метрике А, отсекается. Ограничивающий прямоугольник строки вычисляется неверно. Подобное отсечение часто встречается и в профессиональных приложениях. Ширину строки, как и ширину одного символа шрифта TrueType, можно разделить на три метрики А, В и С. Метрика А строки соответствует метрике А первого символа, метрика С соответствует метрике С последнего символа, а метрика В равна сумме всех остальных метрик строки. Следующая функция вычисляет метрики ABC для целой строки. // ( АО, ВО, СО ) + ( А1. В1, С1 ) « ( АО. В0+С0+А1+В1. С1 } BOOL GetTextABCExtent(HDC hDC. LPCTSTR IpString, int cbString. long * pHeight, ABC * pABC) { SIZE size; if ( ! GetTextExtentPoint32(hDC, IpString, cbString. & size) ) return FALSE; * pHeight = size.cy; pABC->abcB = size.ex; ABC abe; GetCharABCWidths(hDC, lpString[0]. lpString[0]. & abc); // Первый символ pABC->abcB -= abc.abcA; pABC->abcA = abc.abcA; GetCharABCWidths(hDC. lpString[cbString-l]. lpString[cbString-l], & abc); // Последний символ pABC->abcB -= abc.abcC; pABC->abcC - abc.abcC; return TRUE; } Для строки, показанной на рис. 15.11, GetTextABCExtent возвращает структуру ABC {-34,385,-5}; это означает, что фактическая длина строки равна 385 единицам, причем строка смещена на -34 единицы от начальной точки. Когда функция TextOut выравнивает строку в соответствии с атрибутами выравнивания текста, метрики А и С не учитываются. Если метрика А первого символа отрицательна, часть глифа может исчезнуть. Если метрика А положительна, текст неточно выравнивается по правому краю (особенно при выравнивании текста, оформленного разными шрифтами или одним шрифтом с разным кеглем). В следующем фрагменте показано, как точно выровнять текст на уровне пикселов при помощи функции GetTextABCExtent.
Простой вывод текста 845 BOOL PreciseTextOut(HDC hDC. ( long height ABC abe; int x, int y. LPCTSTR IpString, int cbString) if ( GetTextABCExtent(hDC, IpString, cbString. & height, & abc) ) switch ( GetTextAlign(hDC) & (TA_LEFT | TA_RIGHT | TA_CENTER) ) 1 case case case ТА LEFT : ТА RIGHT : ТА CENTER: X X X -= abc.abcA; break; +» abc.abcC; break; -= (abc.abcA-abc.abcC)/2; break; return TextOut(hDC. x. y. IpString, cbString); } Функция PreciseTextOut вычисляет метрики ABC для всей строки и изменяет координату х вызова TextOut в зависимости от текущего флага горизонтального выравнивания текста. Рис. 15.12 наглядно показывает различия между стандартной реализацией выравнивания в GDI и корректировкой, вносимой функцией PreciseTextOut. В первом столбце приведены результаты обычного вызова TextOut для выравнивания строки по левому краю, по центру и по правому краю. Части глифов, выходящие за пределы двух пограничных линий, обычно отсекаются — как, например, в ячейках таблиц Word или Excel. Во втором столбце те же строки выводятся с небольшой поправкой, вычисленной функцией PreciseTextOut; выравнивание обеспечивает точность на уровне пикселов. fluff fluff fluffi [fluff fluff JLUJJ\ Рис. 15.12. Выравнивание текста: TextOut и PreciseTextOut Во внутренних операциях графического механизма используется система координат устройства, из которой и берутся все масштабированные текстовые
846 Глава 15. Текст метрики. Если отображение из системы координат устройства в логическую систему координат не сводится к масштабированию с целым коэффициентом, получение метрик функцией GetTextABCWidths может привести к возникновению погрешности и последующему накоплению ошибок при вычислениях. Функция GetTextABCWidthsFloat помогает избавиться от погрешности, возникающей при преобразовании координат. Если ваше приложение выводит текст как на экран, так и на принтер, необходимо специально позаботиться о том, чтобы экранные данные совпадали с печатными. Например, для получения точных текстовых метрик можно воспользоваться эталонным логическим шрифтом (см. раздел «Получение информации о логическом шрифте»). Нетривиальный вывод текста Функция TextOut обладает простейшими возможностями и предоставляет удобный интерфейс к средствам вывода текста GDI. При использовании этой функции приложение задает значения нескольких атрибутов контекста устройства и передает строку. Функция ограничивается простейшим выводом и полностью маскирует от приложения все сложные операции, выполняемые GDI при выводе текста. За удобство и простоту приходится расплачиваться тем, что приложение не может управлять преобразованием символов в глифы, упорядочением глифов, лигатурами и кернингом, позициями отдельных глифов и т. д. Для решения нетривиальных задач вывода текста в GDI предусмотрены специальные функции, используемые в современных текстовых редакторах и других графических пакетах. Преобразование символов в глифы В шрифте TrueType центральное место занимает набор описаний глифов, масштабируемых для любого разрешения и преобразуемых в глифы. Символы разных кодировок обычно сначала преобразуются в Unicode, а затем — в индексы глифов по таблице «стар», хранящейся в шрифте TrueType. Некоторые возможности обработки текстов, не поддерживаемые GDI напрямую, легко реализуются на уровне глифов. В GDI Windows 2000 появилась новая функция GetGlyphIndices, позволяющая приложению получить массив индексов глифов для символов строки. В предыдущих версиях Windows это преобразование выполнялось при помощи функции GetCharacterPlacement, описанной ниже. В GDI Windows 2000 также поддерживаются функции для получения информации о метриках глифов: DWORD GetGlyphlndicesCHDC hDC, LPCTSTR lpstr. int c. LPW0RD pgi. DWORD f1); BOOL GetCharWidth(HDC hDC. UINT giFirst, UINT cgi. LPW0RD pgi, LPINT lpBuffer); BOOL GetCharABCWidthsKHDC hDC. UINT giFirst. UINT cgi. LPW0RD pgi. LPABC Ipabc); BOOL GetTextExtentPointKHDC hDC. LPW0RD pgiln. int cpi. LPSIZE IpSize);
Нетривиальный вывод текста 847 Индексы глифов хранятся в виде 16-разрядных целых чисел (WORD). Символы Unicode тоже хранятся в виде 16-разрядных целых чисел, поэтому индексы глифов позволяют представить весь интервал Unicode. Для получения информации об интервалах Unicode, поддерживаемых шрифтом, используется функция Get- FontUnicodeRanges. Функция GetGlyphlndices отображает текстовую строку на массив индексов глифов. Параметр pgi указывает на массив WORD, размеры которого достаточны для хранения всех индексов. Последний параметр fl сообщает GDI, как следует поступать с отсутствующими символами. Если он равен CGI_MASK_NONEXISTING_ GLYPHS, отсутствующие символы заменяются маркером OxFFFF. По умолчанию отсутствующие глифы в шрифтах TrueType представляются первым глифом шрифта. Функции получения текстовых метрик GetCharWidthI, GetCharABCWidthsI и Get- TextExtentPointI очень похожи на аналогичные функции без суффикса I с одним исключением — при вызове им передаются интервалы или массивы индексов глифов. Функции API уровня глифов позволяют выполнять специфические операции, не поддерживаемые непосредственно в GDI. Если приложение хочет реализовать лигатуры или контекстную замену глифов, оно может получить соответствующую таблицу шрифта TrueType функцией GetFontData и произвести поиск в таблице. Внутреннее строение шрифтов TrueType подробно рассматривается в главе 14. Кернинг При простом выводе текста функцией TextOut символы позиционируются в строке только по межсимвольным расстояниям, хранящимся в шрифте TrueType, а именно по метрикам ABC глифов. Дополнительные межсимвольные интервалы просто применяются к каждому выводимому символу без учета их специфики. Шрифты TrueType обычно содержат данные кернинга, обеспечивающие контекстную регулировку расстояний. Данные кернинга кодируются в таблице кернинга, каждый элемент которой (пара кернинга) определяет параметры регулировки расстояния для двух конкретных символов, расположенных по соседству. Для получения пар кернинга приложение использует функцию GetKerning- Pairs: typedef struct tagKERNINGPAIR { WORD wFirst; WORD wSecond; int iKernAmount; } KERNINGPAIR; DWORD GetKerningPairs(HDC hDC, DWORD nNumPairs. LPKERNINGPAIR Ipkrnpair); Каждая пара содержит коды двух символов, wFirst и wSecond, и величину кернинга. Фактически она означает следующее: если за символом wFirst следует символ wSecond, относящийся к тому же шрифту, расстояние между этими двумя символами корректируется на величину i KernAmount. Обычно в парах кернинга задается отрицательное расстояние, чтобы символы приближались друг к другу,
848 Глава 15. Текст однако расстояние может быть и положительным. Величина кернинга, возвращаемая функцией GetKerningPairs, задается в логической системе координат. Шрифт TrueType может содержать сотни пар кернинга. Чтобы получить информацию обо всех парах, следует сначала вызвать функцию GetKerningPairs для получения общего числа пар. После выделения блока памяти достаточного размера функция вызывается повторно для получения данных кернинга. Ниже приведено объявление простого класса для работы с парами кернинга (полная реализация находится на прилагаемом компакт-диске). class KKerningPair { public: KERNINGPAIR * mj)KerningPairs; int mjiPairs; KKerningPair(HDC hDC); -KKerningPair(void); int GetKerning(TCHAR first. TCHAR second) }: Класс KKerningPair содержит две переменные. Переменная m_pKerningPairs указывает на динамически выделенный массив структур KERNINGPAIR, а в переменной mjiPairs хранится количество пар кернинга для текущего шрифта. Конструктор класса запрашивает количество пар кернинга, а деструктор освобождает выделенные ресурсы. Дополнительный метод GetKerning возвращает величину кернинга по кодам двух символов. Примеры кернинга показаны на рис. 15.13. В верхнем ряду текст выводится без кернинга. На левом верхнем рисунке изображены четыре пары символов, чрезмерно удаленных друг от друга, а на правом верхнем — три пары символов, расположенных слишком близко. В результате кернинга символы на левом рисунке сближаются (отрицательная корректировка), а на правом рисунке они удаляются (положительная корректировка). ,)Та г. MTf} F,) Та г. n f ] f} Рис. 15.13. Примеры пар кернинга Расположение символов Непосредственно работать с индексами глифов и данными кернинга в приложении достаточно трудно. В GDI существует удобная функция GetCharacterPl acement,
Нетривиальный вывод текста 849 возвращающая информацию о расположении символов в строке. Приложение может проанализировать полученные данные, изменить их или воспользоваться ими для других целей. Соответствующие определения выглядят так: typedef struct tabGCP_RESULTS { DWORD IStructSize; LPTSTR IpOutString; UINT * lpOrder; INT * IpDx; INT * IpCaretPos; LPTSTR IpClass; LPWSTR * lpGlyphs; UINT nGlyphs; UINT mMaxFit; } GCPJESULTS; DWORD GetCharacterPlacement(HDC hDC, LPCTSTR IpString, int nCount, int nMaxExtent, LPGCP_RESULTS lpResults, DWORD dwFlags); Функция GetCharacterPlacement получает манипулятор контекста устройства, указатель на текстовую строку и ее длину, необязательную ширину текстовой области и набор флагов. На выходе она заполняет структуру GCP_RESULT сведениями о расположении символов в строке: порядке следования символов, расстояниях между ними, позиции каретки, классификации символов, индексах глифов и количестве символов, помещающихся в заданной области. Сама структура GCP_RESULT не содержит всей информации, поскольку эти данные представляются массивами переменного размера; в структуре хранятся указатели на массивы. Приложение должно соответствующим образом подготовить GCP_RESULT перед вызовом GetCharacterPlacement. Если приложение запрашивает некоторую информацию, оно устанавливает требуемый флаг в последнем параметре, а соответствующее поле GCP_RESULTS должно содержать действительный указатель; в противном случае значение поля может быть равно NULL. Функция GetCharacterPlacement обладает очень широкими возможностями, проектировавшимися в расчете на поддержку разных аспектов обработки текста — выравнивания по ширине, кернинга, диакритических знаков, упорядочения глифов, лигатур и т. д. Конкретные возможности зависят от шрифта и текущей конфигурации системы. В частности, не все шрифты TrueType содержат таблицы кернинга и поддерживают лигатуры. Возможности конкретного шрифта можно проверить при помощи функции GetFontLanguagelnfo. Полное описание возможностей GetCharacterPlacement займет слишком много места. За подробностями обращайтесь к MSDN. Здесь же будут рассмотрены некоторые простые случаи — использование флагов GCPJJSERKING, GCPJ1AXENTENT и GCP_JUSTIFY. В структуре GCP RESULTS поле lpOutputString содержит указатель на выходную строку, которая будет выведена для заданной входной строки. Как правило, выходная строка совпадает с входной, однако строки могут отличаться — например, при установке флагов GCPREORDER (изменение порядка следования символов) и GCPMAXEXTENT (превышение предельной длины входной строки). Поле 1 pOrder содержит указатель на массив, заполняемый данными отображения входной строки на выходную. В иврите и в арабском языке текст выводится справа
850 Глава 15. Текст налево, что может привести к изменению порядка следования символов входной строки. Поле IpDx содержит указатель на массив, заполняемый сведениями о ширине каждого символа в строке (то есть разности расстояний между позициями текущего и следующего символа в строке). Это расстояние определяется полной шириной символа со всеми поправками — дополнительными межсимвольными интервалами, увеличенными промежутками между словами и кернингом. Порядок следования элементов в массиве IpDx соответствует порядку следования символов в выходной строке. Поле lpCaretPos указывает на массив, заполняемый позициями каретки для всех символов в порядке их следования во входной строке. Данные могут использоваться текстовым редактором для перемещения каретки в процессе работы. Информация об угле наклона символов хранится в структуре OUTLINETEXTMETRIC. Поле IpClass содержит массив классификационных признаков для всех символов строки. Например, флаг GCPCLASS_ARABIC обозначает арабский символ. Поле IpGlyphs содержит указатель на массив, заполняемый индексами глифов всех символов строки. При помощи этого массива можно получить индексы глифов без помощи функции GetGlyphlndices, поддерживаемой только в Windows 2000. Если одна текстовая строка используется при нескольких вызовах функций, следует получить индексы один раз и задействовать их повторно — это сэкономит время на многократные преобразования. Поле nGlyphs изначально содержит максимальное количество элементов в разных массивах структуры GCP_RESULTS. При выходе из GetCharacterPlacement в него записывается количество фактически используемых элементов в массивах. Поле nMaxFit содержит количество символов, укладывающихся в области, размеры которой задаются параметром GetCharacterPlacement. Обратите внимание: в поле nMaxFit хранится количество символов, в отличие от поля nGlyph, содержащего количество глифов. На компакт-диске находится простой класс КР1 acement, предназначенный для работы с функцией GetCharacterPlacement. Функция ExtTextOut Получение индексов глифов, данных кернинга и сведений о расположении символов — не более чем подготовка к выводу текста. Чтобы применить полученную информацию при выводе текста, следует воспользоваться функцией ExtTextOut. BOOL ExtTextOut(HDC hDC. int x, int ym UINT fuOptions. CONST RECT * lprc, LPCTSTR IpString, UINT cbCount. CONST INT * IpDx); Функция ExtTextOut представляет собой расширенную версию TextOut. Вызов TextOut можно заменить эквивалентным вызовом ExtTextOut: ExtTextOut(hDC. x, у. О, NULL, IpString. cbCount. NULL); Остается лишь разобраться с тремя новыми параметрами. Параметр fuOptions содержит набор флагов, управляющий интерпретацией других параметров. Необязательный параметр 1 pre указывает на прямоугольник, который может определять границы непрозрачной области, использоваться для отсечения или совмещать эти функции. Необязательный параметр IpDx содержит указатель на массив расстояний. В табл. 15.3 перечислены допустимые значения параметра fuOptions.
Нетривиальный вывод текста 851 Таблица 15.3. Флаги функции ExtTextOut Значение Описание ET0_0PAQUE (0x0012) Перед выводом текста прямоугольник, заданный параметром 1ргс, закрашивается цветом фона ET0_CLIPPED (0x0004) Текст отсекается по прямоугольнику, заданному параметром 1ргс ET0_GLYPH_INDEX (0x0080) Параметр lpStMng указывает на массив индексов глифов (вместо кодов символов). Индексы глифов всегда являются 16-разрядными величинами ET0_RTLREADING (0x0080) То же, что и флаг TA__RTLREADING при выравнивании текста. В шрифтах арабского языка и иврита текст выводится справа налево ET0__NUMERICSLOCAL (0x0400) Числа выводятся символами национальных алфавитов ET0JIUMERICSLATIN (0x0800) Числа выводятся стандартными европейскими цифрами ET0_IGN0RELANGUAGE (0x1000) He выполнять дополнительную языковую обработку текста ET0__PDY (0x2000) Параметр lpDx указывает на массив пар, в которых первое число определяет горизонтальное расстояние, а второе — вертикальное Параметр 1 pre функции TextOut не влияет на обычную прорисовку фона; скорее он упрощает вывод текста в ограниченной области — например, в ячейке таблицы. Если параметр 1ргс отличен от NULL, он интерпретируется как указатель на прямоугольник в логической системе координат. При установленном флаге ET0_0PAQUE прямоугольник закрашивается текущим цветом фона вместе со стандартным фоном текста. При установленном флаге ET0_CLIPPED прямоугольник задает дополнительный уровень отсечения в логической системе координат (не в координатах устройства!). Чтобы вывести текстовую строку в ячейке таблицы, приложение может передать прямоугольник ячейки ExtTextOut и установить оба флага, ET0_0PAQUE и ET0_CLIPPED. При этом текущим цветом фона закрашивается весь прямоугольник ячейки, а не только текстовая область, и текст заведомо не нарушит границ ячейки. Параметр lpDx позволяет приложению точно определять позицию каждого глифа, не полагаясь на помощь GDI. При такой архитектуре приложение может дополнительно обработать структуру расположения символов, сгенерированную функцией GetCharacterPlacement. Вспомните: текстовые метрики, возвращаемые GDI приложению, задаются в логической системе координат, а вывод текста происходит в системе координат устройства. При печати документа, созданного на экране монитора, на принтере с высоким разрешением, обладающим существенно более точными данными метрик, раскладка текста не будет точно соответствовать экранной. Для решения этих двух проблем несоответствия (между логическими координатами/координатами устройства и экраном/принтером) приложение может получить точные данные метрик шрифта по эталонному логическому шрифту, размер которого совпадает с размером em-квадрата физиче-
852 Глава 15. Текст ского шрифта. Все позиционные вычисления производятся по точным данным em-квадрата и масштабируются в логической системе координат, сохраняются в массиве и передаются ExtTextOut. Функция ExtTextOut также может использоваться для вывода текстовой строки по индексам глифов, полученным при помощи функции GetGlyphlndices или GetCharacterPlacement. Следующий метод выводит текстовую строку по содержимому структуры GCP_RESULTS, возвращаемой функцией GetCharacterPlacement. BOOL KPlacement::GlyphTextOut(HDC hDC. int x, int y) { return ExtTextOut(hDC, x. y. ETO_GLYPH_INDEX, NULL. (LPCTSTR) m_glyphs, m_gcp.nGlyphs. m_dx): } Следующий фрагмент иллюстрирует пример использования индексов глифов и кернинга при работе с функциями GetCharacterPlacement и ExtTextOut. void Test_Kerning(HDC hDC. int x. int y, const TCHAR * mess) { TextOut(hDC. x. y, mess. Jxslen(mess)); KPlacement<MAX_PATH> placement; TEXTMETRIC tm: GetTextMetrics(hDC, & tm); int linespace - tm.tmHeight + tm.tmExternalLeading; KKerningPair kerning(hDC); SIZE size; GetTextExtentPoint32(hDC. mess. _tcslen(mess). & size); for (int test-0: test<3; test++) { у += linespace: int opt; switch ( test ) { case 0: opt s 0; break; case 1: opt - GCPJJSEKERNING; break; case 2: opt - GCPJJSEKERNING | GCP_JUSTIFY; break; } placement.GetPlacement(hDC. mess, opt | GCP_MAXEXTENT, size.cx*ll/10); placement.GlyphTextOut(hDC. x. y); } } В программе, находящейся на компакт-диске, расстояние между глифами отмечается линиями; также выводятся индексы глифов и интервалы кернинга. Пример приведен на рис. 15.14.
Нетривиальный вывод текста 853 AVOWAL ШошШ gi('A')* 36, gi('V')- 57, gi('0')= 50, gi('¥')= 58, gi('A')= 36, gi('L')= 47, extent 346, gi('A')= 36, gi('V')= 57, gi('0')= 50, gi('W')= 58, gi('A')= 36, gi('L')= 47, extent 346, gi('A')= 36, gi('V')= 57, gi('0')= 50, gi('W')= 58, gi('A')= 36, gi('L')= 47, extent 346, dx[ 0]= 49 dx[ 1]= 49 dx[ 2]= 58 dx[ 3]= 66 dx[ 4]= 49 dx[ 5]= 44 sum dx=315 dx[ 0]= 45, dx[ 1]= 47, dx[ 2]« 58, dx[ 3]= 60, dx[ 4]= 49, dx[ 5]= 44 sum dx=303 dx[ 0]= 54 dx[ 1]= 56 dx[ 2]= 67 dx[ 3]= 68 dx[ 4]= 57 dx[ 5]= 44 sum dxe346 kern( kern( kern( kern( kern( A' V 0' W A' 'V '0 'W 'A 'L ) = ) = ) = ) = ) = -4 -2 0 -6 0 Рис. 15.14. Пример ExtTextOut: индексы глифов и кернинг Первая строка выведена обычной функцией TextOut. Вторая строка выведена функцией ExtTextOut по индексам глифов и расстояниям, сгенерированным функцией GetCharacterPlacement, но без установки флага GCPUSEKERNING. Результат выглядит точно так же, как и в первом случае. Третья строка выведена функцией ExtTextOut для данных, возвращенных функцией GetCharacterPlacement при установленном флаге GCPUSEKERN I NG. Наконец, нижняя строка демонстрирует результат выравнивания по ширине с флагом GCPJUSTIFY. Справа выводятся индексы глифов, расстояния между символами и пары кернинга. Видно, что различия в положении символов второй и третьей строк обусловлены применением кернинга, в результате чего ширина текстовой области сократилась на 12 единиц. Различия между третьей и четвертой строками обусловлены выравниванием по ширине: 43 единицы дополнительного пространства почти равномерно распределяются между 5 парами символов (9,9,9,8,8). Если при выравнивании текста установлен флаг TARTLREADING и при вызове функции GetCharacterPlacement был передан флаг GCP_RE0RDER, GDI записывает глифы в соответствии с направлением чтения и правилами замены глифов, если они поддерживаются текущим шрифтом. Пример: KLogFont If(-PointSizetoLogical(hDC. 48). "Andalus"); lf.mJf.lfCharSet - ARABIC_CHARSET; lf.mJf.lfQuality - ANTIALIASED_QUALITY; KGDIObject font (hDC. lf.CreateFontO): assert ( GetFontLanguagelnfo(hDC) & GCP_RE0RDER ); KPlacement<MAX_PATH> placement; const TCHAR * mess = "abc \xC7\xC8\xC9\xCA": SetTextAlign(hDC. TA_LEFT);
854 Глава 15. Текст placement.GetPlacement(hDC. mess, 0); placement.GlyphTextOut(hDC, x, yO); SetTextAlign(hDC. TA_LEFT | TA_RTLREADING); placement.GetPlacement(hDC. mess, GCP_REORDER): placement.GlyphTextOut(hDC, x, yl); На рис. 15.15 показан очень интересный результат. order[0]=0, order[l]-l, order[2]=2, order[3]=3, order[ 4 ] = 4, order[5]=5, order[6]=6, order[7]s 7, order[0]- 5, order[1]■6, order[2] = 7, order[3]■4, order[4]■3, order[5]■2, order[6]■1, order[7]=0, gi(0x61)= gi(0x62)= gi(0x63)= gi(0x20)= gi(0xc7)= gi(0xc8)= gi(0xc9)= gi(0xca)= gi(0xca)a gi(0xc9)= gi(0xc8)= gi(0xc7)= gi(0x20)= gi(0x61)= gi(0x62)= gi(0x63)= = 68, - 69, ■• 70, • 3, = 346, '349, = 352, = 356, = 353, = 352, = 349, = 345, • 3, - 68, - 69, •■ 70, dx[0]= dx[l]= dx[2]= dx[3]= dx[4]= dx[5]- dx[6]= dx[7]= dx[0]= dx[l]= dx[2]= dx[3]= dx[4]= dx[5]- dx[6]= dx[7]= 30 33 29 16 13 18 23 18 30 33 29 16 19 18 23 48 Рис. 15.15. Изменение порядка следования и замена глифов Сравните две строки, верхнюю и нижнюю: слова поменялись местами, порядок следования символов изменился, а сами символы отображаются на разные глифы. В первой строке символы выводятся в стандартном порядке — слева направо, от первого до восьмого. Во второй строке изменился порядок следования как слов, так и арабских символов. Арабские символы отображаются на разные глифы в зависимости от их относительной позиции в слове. Скажем, буква «алеф» (0хС7) отображается на глиф 346 в первой строке и на глиф 345 во второй строке. Uniscribe В Windows 2000 появился компонент Uniscribe — новый интерфейс API, обеспечивающий высокую степень контроля над обработкой сложных текстов. Под «сложным текстом» понимается любой текст, использующий двунаправленный вывод, контекстную замену глифов, лигатуры, особые правила разбивки на слова и выравнивания по ширине или фильтрацию недопустимых комбинаций символов. К сложным текстам относятся тексты на иврите, арабском, тайском и санскрите. Интерфейс Uniscribe API отличается повышенной сложностью, в нем задей- ствуется свыше 30 новых функций и 10 новых структур. Uniscribe использует заголовочный файл usplO.h, библиотечный файл usplO.lib и библиотеку uspl0.dll. А если принять во внимание, что по своим размерам uspl0.dll превосходит даже gdi32.dll, вы поймете, почему в этой книге не найдется места для рассмотрения Uniscribe. Начиная с Windows 2000, стандартные функции GDI для вывода текста (такие, как TextOut и ExtTextOut) были расширены для поддержки сложных текстов. abc UU iil abc
Нетривиальный вывод текста 855 Впрочем, фактическое использование этих возможностей зависит от того, поддерживаются ли они на уровне шрифтов и текущих настроек системы. При пошаговом выполнении кода текстовых функций GDI вы увидите, что GDI загружает внешнюю библиотеку lpk.dll, где LPK означает «Language Pack», то есть «пакет языковой поддержки», lpk.dll экспортирует десятки функций с именами LpkDrawTextEx, LpkExtTextOut и LpkTabbedTextOut и импортирует ряд функций из uspl0.dll. Правосторонняя раскладка и порядок следования символов, замена глифов — в Windows 2000 все эти возможности базируются на использовании Uniscribe. Обработка сложных текстов всегда была слабым местом Windows GDI API, особенно по сравнению с QuickDraw GX компании Apple. До появления Uniscribe приложению, обеспечивающему нетривиальные возможности вывода текста, приходилось работать на уровне внутренних таблиц шрифтов TrueType. Применение Uniscribe значительно упрощает обработку сложных текстов в приложениях. Доступ к данным глифов Как говорилось выше, глифы в шрифтах TrueType представляются квадратичными кривыми Безье. При выводе текста контур глифа преобразуется в растровое изображение с заданными размерами и углом наклона. Полученные растры выводятся на поверхности устройства в соответствии с запросами приложений. Впрочем, возможности вывода текста в GDI остаются ограниченными. Например, GDI не разрешает приложению использовать для прорисовки текста кисть или растр; допускаются только однородные цвета. Для нетривиальных приложений, предусматривающих специальную обработку глифов перед выводом, в GDI существует низкоуровневая функция GetGlyphOutline. При помощи этой функции приложение запрашивает данные глифов в виде набора метрик, растра или описания контура. Ниже приведены соответствующие определения. typedef struct _GLYPHMETRICS { UINT gmBlackBoxX; UINT gmBlackBoxY; POINT gmptGlyphOrigin; short gmCelllncX: short gmCelllncY; } GLYPHMETRICS; typedef struct JIXED { WORD fract; short value; } FIXED; typedef struct _MAT2 { FIXED eMll; FIXED eM12; FIXED eM21: FIXED eM22; } MAT2; DWORD GetGlyphOutlineCHDC hDC, UINT uChar, UINT uFormat.
856 Глава 15. Текст LPGLYPHMETRICS lpgm, DWORD cbBuffer. LPVOID IpvBuffer. CONST MAT2 *lpmat2); Функция GetGlyphOutline за один вызов может вернуть для символа один из трех типов данных: метрики глифа, растр глифа или контур глифа. Первый параметр определяет контекст устройства с выбранным шрифтом TrueType/Open- Type. Параметр uChar определяет код символа в однобайтовом формате или в кодировке Unicode (в зависимости от того, используется ли Unicode-версия этой функции). Параметр uFormat в основном управляет форматом данных, запрашиваемых приложением; его основные значения перечислены в табл. 15.4. Следующий параметр, lpgm, указывает на структуру GLYPHMETRICS, заполняемую метриками глифа. Чтобы получить растр или контур глифа, приложение должно передать функции GetGlyphOutline указатель на буфер IpvBuffer; размер буфера задается параметром cbBuffer. Последний параметр, lpmat2, указывает на матрицу аффинного преобразования в формате с фиксированной точкой. Таблица 15.4. Формат результата GetGlyphOutline Значение Описание GGOMETRICS Заполнить только структуру GLYPHMETRICS. Вернуть 0 в случае успеха, GDIERR0R при неудаче GGOBITMAP Заполнить GLYPHMETRICS и растр в формате 1 бит/пиксел GGONATIVE Заполнить GLYPHMETRICS и исходное описание глифа из шрифта TrueType GGOBEZIER Заполнить GLYPHMETRICS и описание глифа в виде кубических кривых Безье GG0_GRAY2_BITMAP Заполнить GLYPHMETRICS и растр в формате 8 бит/пиксел с 5 уровнями серого GG0_GRAY4_BITMAP Заполнить GLYPHMETRICS и растр в формате 8 бит/пиксел с 17 уровнями серого GG0_GRAY8_BITMAP Заполнить GLYPHMETRICS и растр в формате 8 бит/пиксел с 65 уровнями серого GGOGLYPHINDEX Параметр uChar вместо кода символа содержит индекс глифа GGOUNHINTED Запретить обработку инструкций (хинтов) для контуров глифов (GGONATIVE или GGO_BEZIER). Поддерживается только в Windows 2000 Метрики глифа возвращаются в структуре GLYPHMETRICS, которая описывает отдельный глиф в логической системе координат текущего контекста устройства. Поля gmBlackBoxX и gmBlackBoxY определяют ширину и высоту ограничивающего прямоугольника глифа (а также ширину и высоту возвращаемого растра). Следует учитывать, что этот прямоугольник обычно меньше прямоугольника ячейки символа. Поле gmptGlyphOrigin содержит структуру POINT, которая задает координаты левого верхнего угла ограничивающего прямоугольника глифа относительно эта-
Нетривиальный вывод текста 857 лонной точки. Помните, что при описании глифа TrueType в координатах em- квадрата вертикальная ось направлена снизу вверх, противоположно направлению вертикальной оси в системе координат устройства или логической системе координат в режиме ММ_ТЕХТ. Поля gmCelllncX и gmCelllncY определяют смещение эталонной точки. Растр глифа Функция GetGlyphOutline может вернуть растр глифа в одном из четырех форматов. Формат GGO_BITMAP предназначен для простейших монохромных растров, в которых 0 соответствует фоновым пикселам, а 1 — основным пикселам. В трех других форматах растр возвращается в формате 8 бит/пиксел с разным количеством оттенков серого. Эти растры используются GDI для вывода сглаженных символов (вместо обычных резких переходов на границах). Чтобы вывести текст со сглаженными символами, достаточно задать качество ANTIALIASEDQUALITY при создании логического шрифта. Три растровых формата в оттенках серого, GG0_ GRAY2_BITMAP, GG0_GRAY4_BITMAP и GG0_GRAY8_BITMAP, используют 4, 17 и 65 уровней серого соответственно. Вероятно, формат GGOGRA Y8BITM АР логичнее было бы назвать GG0_GRAY6_BITMAP. Растры глифов либо имеют монохромный формат, либо формат 8 бит/пиксел. Каждая строка развертки всегда выравнивается по границе двойного слова, причем в буфере, возвращаемом GDI, строки развертки следуют в стандартном порядке (от верхней к нижней). Таким образом, формат растра глифа точно совпадает с форматом массива пикселов 1- или 8-разрядного DIB-растра с прямым порядком следования строк. Растр глифа имеет переменный размер, поэтому приложение обычно сначала вызывает функцию GetGlyphOutline для получения размера растра, выделяет блок памяти достаточного объема и вызывает функцию вторично для получения данных растра. Структура МАТ2 определяет ограниченное аффинное преобразование на плоскости. Матрица преобразования содержит числа с фиксированной точкой в формате 16.16. Полное аффинное преобразование описывается структурой XF0RM, содержащей шесть вещественных полей: еМП, еМ21, eDx, eM21, еМ22 и eDy, и позволяет выполнять смещение, масштабирование, зеркальное отражение, поворот, сдвиг и их произвольные комбинации. Структура МАТ2 удаляет eDx и eDy из структуры XF0RM и преобразует оставшиеся поля в формат с фиксированной точкой. Таким образом, структура МАТ2 позволяет описывать масштабирование, повороты, сдвиги и отражения, но не смещения. Учитывая, что смещение легко реализуется при выводе растра глифа, функция GetGlyphOutline фактически поддерживает полные аффинные преобразования. Обратите внимание: параметр МАТ2 является обязательным. Даже если преобразование является тождественным, вы должны передать правильно заполненную структуру МАТ2. Получив растр глифа, вы можете преобразовать его в аппаратно-зависимый или аппаратно-независимый растр и воспользоваться растровыми функциями GDI для его вывода. Вариант с DIB предпочтителен, поскольку он не требует создания новых объектов GDI и упрощает управление цветовой таблицей для сглаженных глифов. Функция GetGlyphOutline позволяет приложению самостоятельно имитировать вывод текста, поэтому перед приложением открывается
858 Глава 15. Текст множество интересных возможностей. Впрочем, получение растров глифов и их вывод — задача не из простых. В листинге 15.4 приведено объявление класса KGIyph для работы с растрами глифов, инкапсулирующего GetGlyphOutline и имитирующего вывод отдельного символа средствами GDI. Полная реализация класса KGIyph находится на компакт-диске. Листинг 15.4. Класс KGIyph: работа с растрами глифов class KGIyph { public: GLYPHMETRICS mjnetrics: BYTE * m_pPixels; DWORD m_nAl1ocSize, mjiDataSize; int mjjFormat; KGlyphO; -KGlyph(void); DWORD GetGlyphCHDC hDC. UINT uChar. UINT uFormat, const MAT2 * pMat2=NULL); BOOL DrawGlyphROP(HDC HDC. int x. int у. DWORD гор. COLORREF crBack. COLORREF crFore); BOOL DrawGlyph(HDC HDC. int x. int y. int & dx. int & dy); }: Класс KGIyph содержит четыре основные переменные: структуру GLYPHMETRICS, буфер растра глифа, размер буфера и флаг формата. Конструктор устроен достаточно просто; деструктор освобождает всю выделенную память. Метод GetGlyph является оболочкой для вызова функции GetGlyphOutline. По сравнению с GetGlyphOutline ему не передается структура с метриками глифа и буфер, поскольку эти данные находятся под управлением класса, а параметр МАТ2 не обязателен, поскольку тождественная матрица легко строится в приложении. KGIyph::GetGlyph создает матрицу по умолчанию, запрашивает размер данных, выделяет память и запрашивает данные глифа. Одна функция используется для получения метрик, растра и контура глифа. Метод DrawGlyphROP выводит растр глифа, возвращенный методом GetGlyphOutline, с заданными цветами (основным и фоновым) и растровой операцией. Основной и фоновый цвет имитируют атрибуты контекста устройства GDI. Растровая операция имитирует режим заполнения фона (прозрачный или непрозрачный) или любой другой экзотический режим вывода на ваше усмотрение. Функция DrawGlyphROP проверяет формат растра, определяя формат (бит/пиксел) и количество уровней серого цвета. На основании полученных данных строится цветовая таблица, содержащая только основной и фоновый цвета или оттенки серого, расположенные между ними и вычисленные методом линейной интерполяции. В стеке создается структура BITMAPINFO для DIB с прямым порядком строк развертки, после чего растр глифа выводится функцией StretchDIBits с заданной растровой операцией. Учтите, что поле высоты в структуре BITMAPINFO- HEADER имеет обратный знак по отношению к высоте ограничивающего прямо-
Нетривиальный вывод текста 859 угольника глифа; тем самым мы сообщаем GDI, что строки развертки растра следуют в прямом порядке (вместо традиционного обратного порядка). Метод DrawGlyph, основанный на DrawGlyphROP, имитирует вспомогательные операции при выводе растра. Предполагается, что при вызове функции используется режим выравнивания TA_LEFT | TABASELINE. Метод проверяет, не был ли в контексте устройства выбран непрозрачный режим заполнения фона. В этом случае область, в которой выводится глиф, закрашивается цветом фона. После создания кисти, цвет которой определяется текущим цветом текста, растр глифа выводится в прозрачном режиме с использованием тернарной растровой операции 0хЕ20746. Вспомните, что означает код безымянной растровой операции 0хЕ20746: если пиксел источника равен 1, использовать цвет кисти; в противном случае приемник остается без изменений. В данном случае растровая операция выводит основные пикселы текущим цветом текста (при помощи кисти) и не изменяет фоновых пикселов. Поскольку функция DrawGlyph должна быть как можно более универсальной, для вывода отдельных глифов нельзя было воспользоваться простой операцией SRCCOPY — если эта функция последовательно вызывается несколько раз при выводе строки, ограничивающий прямоугольник глифа может перекрываться с ограничивающим прямоугольником предыдущего глифа. Из-за этого функции DrawGlyph приходится задействовать прозрачную растровую операцию при выводе растра глифа. При вызове DrawGlyph не рекомендуется использовать непрозрачный режим заполнения фона, если функция выводит больше одного символа. Фон текста приходится выводить на уровне строки перед выводом самого первого глифа. Функция регулирует экранные координаты в соответствии с координатами базовой точки глифа в структуре GLYPHMETRICS и выводит растр методом DrawGlyphROP. Использовать класс KGlyph для получения информации и вывода растров глифов легко и удобно. В приведенном ниже простом примере строка, выведенная средствами GDI, сравнивается со строками, состоящими из глифов в разных растровых форматах. void Demo_GlyphOutline(HDC hDC) { KLogFont lf(-PointSizetoLogical(hDC. 96), "Times New Roman"); If.mjf.lfltalic = TRUE; lf.mJf.lfQuality - ANTIALIASED_QUALITY; KGDIObject font (hDC. lf.CreateFontO); int x = 20: int у = 160; int dx, dy; SetTextAlign(hDC. TA_BASELINE | TA_LEFT); SetBkColor(hDC. RGB(0xFF. OxFF. 0)); // желтый SetTextColor(hDC. RGB(0. 0. OxFF)); // голубой // SetBkMode(hDC, TRANSPARENT); KGlyph glyph;
860 Глава 15. Текст TextOut(hDC. x. у, "1248". 4); у+= 150; glyph.GetGlyph(hDC, Т. GGO_BITMAP); glyph.DrawGlyph(hDC. x. y. dx, dy);x+=dx; glyph.GetGlyph(hDC. '2'. GG0_GRAY2_BITMAP); glyph.DrawGlyph(hDC, x, y. dx. dy); x+=dx; glyph.GetGlyph(hDC. '4'. GG0_GRAY4_BITMAP): glyph.DrawGlyph(hDC, x, y. dx. dy); x+=dx; glyph.GetGlyph(hDC. '8*. GG0_GRAY8_BITMAP); glyph.DrawGlyph(hDC. x. y. dx. dy); x+=dx; } Функция создает сглаженный логический шрифт, выводит строку «1248» функцией TextOut GDI, а затем выводит четыре отдельных глифа «1», «2», «4» и «8» в форматах GGO_BITMAP, GG0_GRAY2_BITMAP, GG0_GRAY4_BITMAP и GG0_GRAY8_BITMAP. Результат показан на рис. 15.16. Рис. 15.16. Вывод растров глифов, сгенерированных функцией GetGlyphOutline Наверху слева изображена строка, выведенная средствами GDI. Похоже, во внутренней работе GDI использует формат GG0GRAY4BITMAP с 17 уровнями серого цвета. Слева внизу показан результат, выведенный функцией KGlyph. Хорошо видны «зазубрины» цифры «1», выведенной в формате GG0BITMAP, но три других формата практически не отличаются друг от друга. Справа показаны фрагменты растров глифов с 17 и 65 уровнями серого. Внимательный анализ цветного варианта рисунка показывает, что для вычисления промежуточных оттенков GDI не ограничивается линейной интерполяцией в цветовом пространстве RGB. Цвета, используемые GDI, обеспечивают более приятный и красочный результат по сравнению с реализованным в листинге 15.4.
Нетривиальный вывод текста 861 Контур глифа Функция GetGlyphOutline также может вернуть описание контура глифа в виде комбинации прямых и кривых Безье, соответствующих исходному описанию глифа в шрифте TrueType. У приложения появляются новые низкоуровневые возможности для работы с данными, очень близкими к физическому описанию шрифта TrueType. Использование контуров вместо растров находит немало интересных применений. Три флага параметра uFormat определяют формат контура глифа. Общий формат представляет собой последовательность так называемых многоугольников TrueType. Многоугольник TrueType начинается со структуры TTPOLYGONHEADER, за которой следует серия структур TTPOLYCURVE. Если указан формат GGONATIVE, многоугольники TrueType состоят только из прямых линий и квадратичных кривых Безье. Квадратичная кривая Безье определяется тремя точками — двумя конечными и одной контрольной, тогда как кубическая кривая Безье определяется четырьмя точками. Как было показано в главе 14, контур глифа в физических шрифтах TrueType описывается закодированным набором линий и квадратичных кривых Безье с инструкциями для подгонки по сетке. Таким образом, было бы неправильно утверждать, что формат GGONATIVE полностью соответствует описанию глифа TrueType; тем не менее работать с ним в приложениях гораздо удобнее, чем с физическими таблицами глифов. Если указан выходной формат GGOBEZIER, все квадратичные кривые Безье в многоугольниках TrueType преобразуются в кубические. По умолчанию полученный контур подвергается дополнительной обработке — к нему применяются специальные инструкции, улучшающие внешний вид глифа и обеспечивающие постоянство графического стиля при малых размерах шрифтов. Но если флаг GGONATIVE или GGOBEZIER задан в сочетании с GGOUNHINTED, инструкции не применяются. Контур глифа, возвращенный GetGlyphOutline, масштабируется по текущему размеру шрифта с применением матрицы преобразования. Что бы ни говорилось в документации, контур глифа не возвращается в единицах, использованных при его конструировании, и матрица преобразования не игнорируется. Координаты точек в контурах глифов возвращаются в виде 32-разрядных чисел повышенной точности с фиксированной точкой (16-разрядная целая часть со знаком и 16- разрядная дробная часть). К счастью, эти реальные координаты генерируются непосредственно по описанию глифа в шрифте TrueType и не приводятся к системе координат устройства. К ним даже можно самостоятельно применять преобразования, не беспокоясь о потере точности. Ниже приведены определения многоугольников TrueType. typedef struct tagPOINTFX { FIXED x; FIXED y; } POINTFX. FAR* LPPOINTFX; typedef struct tagTTPOLYCURVE { WORD wType; WORD cpfx; POINTFX apfx[l];
862 Глава 15. Текст } TTPOLYCURVE, FAR* LPTTPOLYCURVE; typedef struct tagTTPOLYGONHEADER { DWORD cb; DWORD dwType; POINTFX pfxStart; } TTPOLYGONHEADER, FAR* LPTTPOLYGONHEADER; Контур глифа возвращается в виде блока данных, заполненного последовательностью многоугольников TrueType. Количество многоугольников нигде не указывается явно, хотя размер блока данных известен. Каждый многоугольник TrueType соответствует одному замкнутому контуру в описании глифа. Структура данных имеет переменный размер и начинается со структуры TTPOLYHEADER, за которой следует серия структур TTPOLYCURVE. Поле cb структуры TTPOLYGONHEADER содержит размер многоугольника TrueType, в поле dwType хранится его тип (единственное допустимое значение — TT_P0LYG0N_TYPE), а поле pfxStart определяет начальную/конечную точку многоугольника. Поле pfxStart можно рассматривать как своего рода аналог функции MoveTo GDI. Структура TTPOLYCURVE имеет переменный размер и содержит информацию о cpfx точках. Она может относиться к одному из трех типов (поле wType). Если поле wType равно TT_PRIM_LINE, структура описывает ломаную; значение TT_PRIM_QSPLINE соответствует квадратичной кривой Безье, а значение TT_PRIM_CSPLINE — кубической кривой Безье. Ломаную можно рассматривать как последовательность команд LineTo GDI. Кубическая кривая Безье всегда состоит из N х 3 точек, в GDI ее аналогом является команда Poly- BezierTo. В простейшем случае квадратичная кривая Безье определяется двумя точками; вместе с последней точкой многоугольника они образуют сегмент кривой. Вообще говоря, все точки, за исключением последней, в кривых TT_PRIM_ QSPLINE интерпретируются как контрольные. Если в определении кривой несколько контрольных точек следуют подряд, между каждой парой вставляются дополнительные конечные точки. Впрочем, эта тема обсуждалась в главе 14 при описании формата глифов TrueType. Основная проблема с расшифровкой многоугольника TrueType — перебор сегментов и их преобразование в линии или квадратичные кривые Безье, поддерживаемые GDI. В GDI существует функция PolyDraw, которая выводит серию отрезков и кубических кривых Безье, представленных двумя массивами. В массиве POINT хранятся координаты, а в массиве BYTE — флаги. Если бы нам удалось декодировать контур глифа в подобную структуру, то приложение могло бы вывести его одним вызовом функции GDI. В листинге 15.5 приведено объявление класса KGlyphOutline, предназначенного для расшифровки и вывода контуров глифов. Полная реализация класса находится на прилагаемом компакт-диске. Листинг 15.5. Класс KGlyphOutline: работа с контурами глифов template <int MAX_POINTS> class KGlyphOutline { public: POINT m_Point[MAX_POINTS]; BYTE mjlag [MAXJOINTS]:
Нетривиальный вывод текста 863 int mjiPoints; private: void AddPoint(int x. int y. BYTE flag); void AddQSplineCint xl. int yl, int x2. int y2); void AddCSpline(int xl. int yl, int x2. int y2. int x3. int y3); void MarkLast(BYTE flag); void Transform(int dx. int dy); public: int DecodeTTPolygonCconst TTPOLYGONHEADER * IpHeader, int size); BOOL Draw(HDC hDC. int x, int y); int DecodeOutline(KGlyph & glyph) }: Переменные класса KGlyphOutline соответствуют параметрам функции Poly- Draw — это массив POINT, массив BYTE и количество точек. Метод AddPoint добавляет новую точку с флагом, определяющим ее тип. Метод AddCSpline добавляет кубическую кривую Безье с тремя точками. Метод AddQSpline преобразует квадратичную кривую Безье в кубическую и вызывает AddCSpline. Метод MarkLast используется только для пометки последней точки, замыкающей фигуру. Координаты KGlyphOutline, заданные сначала в виде чисел с фиксированной точкой, сохраняются как 32-разрядные целые, поскольку с исходной структурой FIXED неудобно работать. Метод Transform преобразует число с фиксированной точкой в целое и добавляет начальное смещение. Вы можете легко реализовать дополнительные преобразования — например, для масштабирования или поворота всех точек. Метод DecodeTTPolygon управляет расшифровкой данных, полученных функцией GetGlyphOutline. Он перебирает содержимое структур, вставляет неявные контрольные точки для квадратичных кривых Безье и вызывает три вспомогательные функции для построения кривых. Каждый многоугольник TrueType помечается как замкнутый флагом PTCLOSEFIGURE. Это гарантирует нормальное завершение линий при использовании утолщенного геометрического пера. Листинг 15.5 выглядит проще кода расшифровки данных TrueType, описанного в главе 14, поскольку самая сложная часть преобразования — расшифровка низкоуровневых данных TrueType, преобразование и подгонка по сетке — выполняется шрифтовыми драйверами, драйверами графических устройств и GDI. В следующем фрагменте текстовая строка выводится в виде контура с использованием класса KGlyphOutline. Результаты вызовов OutlineTextOut и функции TextOut GDI показаны на рис. 15.17. BOOL OutlineTextOut(HDC hDC, int x. int y. const TCHAR * str. int count) { if ( count<0 ) count = Jxslen(str); KGlyph glyph; KGlyph0utline<512> outline; while ( count>0 ) {
864 Глава 15. Текст if ( glyph.GetGlyph(hDC. * str. GGO_NATIVE)>0 ) if ( outline.DecodeOutline(glyph) ) outline.Draw(hDC, x. y); x += glyph.m_metrics.gmCellIncX; У += glyph.mjmetrics.gmCelllncY: str ++; count --; } return TRUE; } Outline Рис. 15.17. Вывод контура текста с использованием GetGlyphOutline Форматирование текста В этой главе мы рассмотрели простейший вывод текста (функция TextOut), более сложный вывод на уровне индексов глифов и позиционированием отдельных символов (функция ExtTextOut) и даже низкоуровневые операции с растрами и контурами глифов с применением функции GetGlyphOutline. Короче, мы рассмотрели практически все, что необходимо знать о выводе текста в GDI. Пришло время посмотреть, как эти возможности применяются на практике (если, конечно, вы не предпочитаете работать на уровне таблиц TrueType — но об этом уже говорилось в главе 14). Этот раздел посвящен всевозможным проблемам, связанным с форматированием текста, то есть размещением символов в соответствии с заданными требованиями. Вывод текста с табуляцией Табуляция широко используется в простейших текстовых редакторах для выравнивания текста по столбцам, облегчающего восприятие данных. Впрочем, та-
Форматирование текста 865 булированный вывод текста применяется и во многих современных пакетах. GDI содержит специальные функции для получения метрик и вывода текстовых строк, содержащих внутренние символы табуляции. LONG TabbedTextOut(HDC hDC. int x, int у. LPCTSTR IpString. int nCount, int nTabPosition. LPINT IpnTabStopPositions, int nTabOrigin); DWORD GetTabbedTextExtent(HDC hDC. LPCTSTR IpString. int nCount. int nTabPosition. LPINT IpnTabStopPositions); По сравнению с TextOut функция TabbedTextOut получает три новых параметра. В массиве, заданном параметрами IpnTabStopPositions и nCount, хранятся последовательные горизонтальные координаты позиций табуляции. Параметр nTabOrigin содержит смещение, прибавляемое ко всем позициям табуляции. Если в массиве хранятся относительные координаты позиций, nTabOrigin задает начальную точку для отсчета позиций табуляции, благодаря чему массив перестает зависеть от конкретной позиции вывода. Если выводимая строка содержит символы табуляции (\t), GDI выводит начало строки, пока не обнаружит символ табуляции. Для этого GDI просматривает таблицу позиций табуляции, находит в ней ближайшую позицию и продолжает вывод текста с этой позиции. Это повторяется до тех пор, пока не будет выведена вся строка. Если количество символов табуляции в строке превышает количество элементов в таблице, GDI вычисляет дополнительные позиции табуляции на основании последней заданной. Другими словами, если вы хотите использовать равноудаленные позиции табуляции, достаточно передать массив из одного элемента. Обратите внимание: функция не гарантирует, что символы после п-то символа табуляции будут выводиться в п-й позиции табуляции. Вместо этого GDI ищет в таблице следующую позицию табуляции, ближайшую к текущей позиции в тексте. Позиции табуляции могут быть отрицательными; в этом случае GDI выравнивает текст по правому краю перед заданной позицией, вместо выравнивания по левому краю после нее. Функция TabbedTextOut возвращает 32-разрядное число, старшее слово которого содержит высоту, а младшее — ширину строки. Оба значения задаются в логических координатах. Функция GetTabbedTextExtents возвращает размеры табулированного текста, не выводя его. Простой пример использования TabbedTextOut для вывода текста в столбцах с помощью табуляций. int tabstop[] = { -120. 125. 250 }; const TCHAR * lines[] - { "Group" "\t" "Result" "\t" "Function" "\t" "Parameters". "Font" "\t" "DWORD" "\t" "GetFontData" "\t" "(HDC hDC. ...)". "Text" "\t" "BOOL" "\t" "TextOut" "\t" "(HDC hDC. ...)" }: int x=50. y=50; for (int i=0: i<3; i++) у +- HIWORD(TabbedTextOut(hDC. x. у lines[i]. _tcs1en(lines[i]). sizeof(tabstop)/sizeof(tabstop[0]), tabstop, x));
866 Глава 15. Текст Программа выводит три строки текста в четыре столбца в позициях х, х + 120, х + 125 и х + 250, причем в позиции х + 120 текст выравнивается по правому краю. Обратите внимание: начальная координата х передается функции GetTabbed- TextOut в последнем параметре, поэтому позиции в массиве задаются относительно начала текста. Вы должны проследить за тем, чтобы позиции табуляции были достаточно удалены друг от друга, а текст выводился аккуратно упорядоченным по столбцам. Простое абзацное форматирование В пользовательском интерфейсе Windows часто требуется вывести длинный текст в прямоугольнике, способном вместить несколько строк. Примеров множество: вывод текста на кнопках, однострочные и многострочные статические элементы и текстовые поля и т. д. В системе управления окнами Windows (user32.dll) поддерживаются две функции для простейшего форматирования текста, в основном используемые при построении пользовательского интерфейса. int DrawText(HDC hDC. LPCTSTR IpString, int nCount, LPRECT IpRect. UINT uFormat); typedef struct { UINT cbSize; int iTabLength; int iLeftMargin; int iRightMargin; UINT uiLengthDrawn; } DRAWTEXTPARAMS; int DrawTextEx(HDC hDC, LPTSTR IpchText, int cchText. LPRECT IpRect, UINT dwDTFormat. LPDRAWTEXTPARAMS IpDTParams); Функция DrawText выводит текстовую строку в прямоугольной области, заданной параметром IpRect в логических координатах. Последний параметр uFormat содержит до двух десятков флагов, которые определяют интерпретацию управляющих символов, режим расширения символов табуляции и замены частей строки многоточиями и т. д. За подробной информацией об этих флагах обращайтесь к электронной документации. Функция DrawTextEx получает дополнительный параметр — указатель на структуру DRAWTEXTPARAMS, которая определяет расстояние между позициями табуляции, левые и правые поля, а также используется для возвращения длины выведенной строки. Функции DrawText и DrawTextEx рассчитаны на вывод однострочного и многострочного текста. Однострочный текст часто встречается в меню, на панелях инструментов, кнопках, статических полях и т. д. Эти две функции учитывают стандартные требования к этим строкам, включая вертикальное и горизонтальное выравнивание, отсечение, расширение символов табуляции, интерпретацию префиксов (знак & означает подчеркивание следующего символа) и три режима интерпретации многоточий. Многострочные тексты встречаются в многострочных статических и текстовых полях. Функции DrawText и DrawTextEx обеспечивают простое и удобное форматирование абзацев с разбивкой на слова. На рис. 15.18 приведены примеры использования функции DrawText.
Форматирование текста 867 Open с :\Win\system32\gdi32.c Open c:\Wi n\sy ste m 3 2\g d i 3 Э Open c:\Win\syst..\gdi32.dll &Open c:\Win\system32\gdi... Open c:\Win\system32\gdi... IThe DrawText function draws formatted text in the jspecified rectangle. It Ifnrmflts thp. tp.vt pir.nnrdinn tn The DrawText function draws formatted text in the specified rectangle. It fnrmflts thp tp.yt nr.nnrrlinn tn The DrawText function draws formatted text in the specified rectangle. Itl Рис. 15.18. Форматирование текста функциями DrawText/DrawTextEx В левой части рисунка приведены примеры форматирования однострочного текста с приведенными далее комбинациями флагов. В частности, рисунок иллюстрирует вертикальное выравнивание, расширение табуляций, маскировку префикса и разные варианты использования многоточий. Флаг DTMODIFYSTRING даже позволяет изменить исходную строку, привести ее в соответствие с выведенными символами и использовать в другом месте. const TCHAR * mess = "SOpen \tc:\\Win\\system32\\gdi32.dll": RECT rect = { 20. 120. 20+180. 120 + 32 }; int opt[] = { DT_SINGLELINE | DTJOP. DT_SINGLELINE | DTJ/CENTER | DTJXPANDTABS. DT_SINGLELINE | DT_B0TT0M | DTJXPANDTABS | DT_PATH_ELLIPSIS. DT_SINGLELINE | DTJIOPREFIX | DTJXPANDTABS | DT_WORDJLLIPSIS. DTJINGLELINE | DTJIDEPREFIX | DTJXPANDTABS | DTJNDJLLIPSIS. }: Справа на рисунке показано, как DrawText преобразует длинный текст в абзац, состоящий из нескольких строк. В трех приведенных вариантах используются разные флаги горизонтального выравнивания. Хотя функции DrawText/DrawTextEx обладают удобными средствами форматирования многострочного текста, их возможности ограничиваются обслуживанием простых нужд пользовательского интерфейса. Для WYSIWYG этого явно недостаточно. Рис. 15.19 иллюстрирует это утверждение. На рисунке текст, оформленный шрифтом с кеглем 6, 8, 12 и 15 пунктов, выводится в текстовых областях, размер которых пропорционален кеглю (ширина = 42 х кегль, высота = 5х кегль). В идеальном случае абзац должен делиться на строки в одних и тех же местах, но на рисунке видно, что положение разрывов строк изменяется. Для вывода лицензионного соглашения в диалоговом окне сойдет, но в серьезном текстовом редакторе это неприемлемо. Пользователи будут сильно огорчены, если текст по-разному форматируется при разных масштабах изображения или при печати на принтерах с разным разрешением. Конечно, проблема связана с тем, что возвращаемые GDI простые целочис-
868 Глава 15. Текст ленные метрики страдают от накопления погрешности. Чтобы форматирование текста соответствовало принципу WYSIWYG, необходимо принять особые меры. IT he DrawTexl function draws formatted text in the specified rectangle. It formats I the text according to the specified method (expanding tabs, justifying characters, breaking lines, and so forth). |The DrawText function draws formatted text in the specified rectangle. I It formats the text according to the specified method (expanding tabs, [justifying characters, breaking lines, and so forth). | [The DrawText function draws formatted text in the specified rectangle. It I ormats the text according to the specified method (expanding tabs, ustifying characters, breaking lines, and so forth). | Рис. 15.19. Неточности форматирования текста при использовании функции DrawText Зависимость DrawText/DrawTextEx от конкретного разрешения отчасти объясняет, почему диалоговые окна, предназначенные для экрана с разрешением 96 dpi, плохо выглядят на экране с разрешением 120 dpi. При смене разрешения изменяется высота стандартных шрифтов. Из-за погрешностей округления связь между логическим разрешением, высотой шрифта и шириной шрифта не является строго линейной. Следовательно, текст, выводимый в 5 строк на экране 96 dpi, при 120 dpi может превратиться в 4 строки или, что еще хуже — в 6 строк. Аппаратно-независимое форматирование текста При форматировании многострочного абзаца аппаратно-независимый алгоритм должен генерировать одну и ту же раскладку текста при любом разрешении графического устройства или настройке системы координат. Если нам удастся решить эту задачу, содержимое экрана будет точно совпадать с результатами, напечатанными на принтере, изображение будет одинаковым при разных настройках экрана, а раскладка текста сохранится при изменении масштаба. Алгоритм аппаратно-независимого форматирования текста основан на получении точных метрик текста и их использовании для вычисления разрывов строк и управления выводом на экран. Мы рассматривали возможность создания эталонного логического шрифта, размер которого совпадает с размером em- квадрата шрифта TrueType (сетки, в которой определяются глифы). Текстовые метрики, полученные на основании эталонного шрифта, обладают необходимой точностью. Располагая точными текстовыми метриками, можно вычислить метрики для шрифта с заданным кеглем в виде вещественных чисел, также обладающих высокой точностью. При наличии такой информации функции GetTextExtentPoint32, ExtTextOut и даже DrawText заменяются более точными реализациями.
Форматирование текста 869 В листинге 15.6 приведены объявления двух классов, реализующих аппарат- но-независимое форматирование текста. Полные реализации находятся на компакт-диске. Листинг 15.6. Классы аппаратно-независимого форматирования текста class KTextFormator { typedef enum { MaxCharNo = 256 }; float m_fCharWidth[MaxCharNo]; float m_fHeight; public: BOOL SetupPixeKHDC hDC. HFONT hFont. float pixelsize): BOOL SetupCHDC hDC. HFONT hFont. float pointsize); BOOL GetTextExtent(HDC hdc. LPCTSTR pString. int cbString. float & width, float & height); BOOL TextOut(HDC hDC. int x. int у. LPCTSTR pString. int nCount): DWORD DrawTextCHDC hDC. LPCTSTR pString. int nCount. const RECT * pRect. UINT uFormat): class KLineBreaker { LPCTSTR m_pText; i nt mjlength; int m_nPos: BOOL SkipWhite(void); // Пропуск пробелов void GetWord(void); // Чтение следующего слова BOOL Breakable(int pos); // Попытка разбиения слова public- float textwidth. textheight; KLineBreakerCLPCTSTR pText. int nCount); BOOL GetLineCKTextFormator & formator, HDC hDC. int width, int & begin, int & end); }: Класс KTextFormator реализует аппаратно-независимые версии трех функций GDI. В переменных этого класса, инициализируемых методом Setup, хранятся данные о ширине символов и высоте текста в формате с плавающей точкой. Метод KTextFormator: -.GetTextExtent является аналогом функции GDI GetTextExtentPoint32, но возвращает числа с плавающей точкой. Два других метода являются аналогами функций TextOut и DrawText GDI. Метод Setup создает эталонный шрифт с размером em-квадрата и запрашивает ширину 256 символов текущего набора (по предположению — однобайтового). Расширение класса для поддержки Unicode и двухбайтовых наборов потребует дополнительных усилий. Наконец, метод масштабирует значения ширины символов на основании текущего кегля и разрешения устройства. Обратите
870 Глава 15. Текст внимание: кегль передается методу Setup в числе параметров вместо того, чтобы получать информацию по манипулятору текущего шрифта. Если запросить высоту текста по манипулятору и вычислить по ней кегль, результат может оказаться неточным. Предполагается, что в кегле уже была учтена настройка текущей системы координат. Реализация методов GetTextExtent и TextOut весьма проста. Метод GetTextExtent просто суммирует значения ширины символов в строке. В аппаратно-незави- симой версии TextOut нельзя использовать исходную функцию TextOut GDI, поскольку GDI задействует данные о ширине символов в системе координат устройства. К счастью, в GDI имеется функция ExtTextOut, получающая массив расстояний между символами. Следовательно, нам остается лишь заполнить массив вещественными значениями ширины и вызвать ExtTextOut. Программа накапливает суммарную ширину символов, для каждого символа преобразует ее в целое число и вычисляет расстояние по полученной величине. Это гарантирует, что отклонение для каждого символа не превысит половины пиксела. Основные сложности в реализации DrawText связаны с разбиением текста на строки по значениям левого и правого поля. Задача решается при помощи другого класса KLineBreaker. Главный метод этого класса, KLineBreaker: :GetLine, определяет, сколько символов разместится по заданной ширине. GetLine добавляет слова до тех пор, пока длина строки не превысит максимально допустимую, а затем пытается найти такое разбиение последнего слова, чтобы оставшиеся символы помещались в заданной области. Простейший способ разбиения слов реализуется методом Breakable. Текущая реализация KTextFormator:: DrawText последовательно получает строки, вызывая метод KLineBreaker::GetLine, и выводит их методом TextOut. Следующая функция помогает сравнить функцию DrawText GDI с аппаратно- независимыми средствами класса KTextFormator. void Demo_Paragraph(HDC hDC. bool bPrecise) { const TCHAR * mess = "The DrawText function draws formatted text in the specified " "rectangle. It formats the text according to the specified " "method (expanding tabs, justifying characters, breaking "lines, and so forth)."; int x = 20; int у - 20; SetBkMode(hDC, TRANSPARENT); for (int size=6; size<=21; size+=3) // 6, 9, 12, 15. 18, 21 { int width = size * 42; int height = size * 5; KLogFont lf(-PointSizetoLogical(hDC. size), "MS Shell Dig"); lf.mjf.lfQuality - ANTIALIASED_QUALITY; KGDIObject font (hDC. If .CreateFontO); RECT rect = { x. y. x+width. y+height };
Эффекты при выводе текста 871 if ( bPrecise ) { KTextFormator format; format.Setup(hDC, (HFONT) font.mJiObj, size); format.DrawText(hDC. mess, _tcslen(mess). & rect, DT_WORDBREAK | DT_LEFT); } else DrawText(hDC, mess, _tcslen(mess), & rect. DT_WORDBREAK | DT_LEFT); Box(hDC, rect.left-1, rect.top-1, rect.right+1, rect.bottom+1); у = rect.bottom + 10; } } Функция Demo_Paragraph получает логический параметр bPrecise. Если этот параметр равен TRUE, для вывода многострочного текста используется класс KTextFormator; в противном случае используется функция DrawText GDI. Результаты применения стандартной реализации GDI вы видели на рис. 15.19. WYSIWYG- версия, реализованная методом KTextFormator::DrawText, изображена на рис. 15.20. ГТЙй OsirtfTft*1 bt*ViS.tt-: <.! ?«№':: $.№:«:#;&*•; :W.?5.4« #№ tttSCfA&P.il .r^K'AWsyNf. I I?: b:WK& K# Vtfi ::*tt.V:*::::y Jft И'!* фяйй&йЗ fitfUwfi ?<J%iWUi::* Vj itfji. I |The DrawTexHunclion draws formatted text in Ihe specified rectangle. I It formats the text according to the specified method (expanding tabs, justifying characters, breaking lines, and so forth). [The DrawText function draws formatted text in the specified rectangle. It formats the text according to the specified method (expanding tabs, pustitying characters, breaking lines, and so forth). [The DrawText function draws formatted text in the specified rectangle. It formats the text according to the specified method (expanding tabs, Justifying characters, breaking lines, and so forth). Рис. 15.20. Форматирование текста с использованием класса KTextFormator Рисунок наглядно показывает, что при использовании вещественных метрик смена разрешения устройства и масштаба никак не сказывается на форматировании абзацев и выводе текста. Эффекты при выводе текста В предыдущем разделе было показано, как управлять различными аспектами вывода текста на уровне GDI. Следующий вопрос — как воспользоваться этими возможностями для создания эффектов при выводе текста?
872 Глава 15. Текст В простейших текстовых редакторах текст выглядит тривиально, черные буквы на белом фоне. Вам остается лишь рассчитать, как правильно отформатировать этот текст. Впрочем, существуют многочисленные эффекты, позволяющие оформлять заголовки или выделять фрагменты текста. В этом разделе рассматривается изменение цвета и формы текста, а также использование текста в виде растров и кривых. Цвет текста В контекстах устройств GDI предусмотрены атрибуты, определяющие цвет текста, цвет фона и режим заполнения фона при выводе текста. Например, чтобы текст выводился синим цветом, достаточно вызвать функцию SetTextCo1or(hDC, RGB(0xFF,0,0)). В GDI также предусмотрена возможность вывода сглаженного текста с использованием промежуточных цветов между цветами текста и фона, устраняющих неровности на границах глифов. Чтобы вывести сглаженный текст, при создании логического шрифта следует указать параметр качества ANTIALIASED_ QUALITY. В GDI цвета текста и фона могут быть только однородными. В режиме с 256 цветами GDI перед выводом всегда заменяет указанный текст однородным цветом из палитры. Кроме того, в GDI не предусмотрена возможность закраски текста произвольной кистью. Конечно, это вызывает определенные проблемы при выводе текста в пользовательском интерфейсе, поэтому была предусмотрена специальная функция для вывода «затушеванных» текстовых строк. Функция GrayString, реализованная системой управления окнами (user32.dll), позволяет раскрашивать текст кистями и удалять из глифов некоторые пикселы (предполагается, что затушеванный текст будет выводиться на недоступных элементах). Поскольку GDI не поддерживает закраски текста кистью, функция GrayString создает совместимый контекст устройства, преобразует текст в растр и работает с полученным растром. Как и другие графические функции, не относящиеся к GDI, функция GrayString обладает достаточно простыми возможностями и предназначается в основном для вывода текста на экран. В частности, GrayString не поддерживает отрицательные значения метрик А и С. Несмотря на отсутствие прямой поддержки, цветной текст можно вывести и другими средствами GDI. В одном из простых решений используется растровая операция, а раскраска выполняется в три этапа. Если вы хотите вывести текст кистью цвета Р, выполните следующие действия. 1. Закрасьте нужную область кистью Р с растровой операцией PATINVERT. Приемник переходит в состояние DAP. 2. Выведите текстовую строку в прозрачном режиме с черным цветом текста. Фон сохраняет цвет DAP, а текст окрашен в черный цвет (0). 3. Снова воспользуйтесь кистью Р с растровой операцией PATINVERT. Фон восстанавливает цвет D, а текст окрашивается в цвет Р. Аналогичный способ применяется для вывода непрозрачного текста с применением кистей для закраски фона и текста, а также для заполнения текста растровыми изображениями или градиентными заливками. Главные трудности связаны
Эффекты при выводе текста 873 с вычислением ограничивающего прямоугольника, поскольку сколько-нибудь общее решение должно учитывать отрицательные значения метрик А и С. В листинге 15.7 приведена одна из возможных реализаций этой идеи. Функция GetOpaqueBox вычисляет ограничивающий прямоугольник выводимой строки. Функция ColorText показывает, как закрасить текст кистью. Аналогичная функция для заполнения текста растровым изображением в книге не приводится. Листинг 15.7. Закраска текста кистью BOOL GetOpaqueBoxCHDC hDC. LPCTSTR lpString, int cbString. RECT * pRect, int x, int y) { long height; ABC abc; if ( ! GetTextABCExtent(hDC, lpString, cbString. & height. & abc) ) return FALSE; switch ( GetTextAlign(hDC) & (TA_LEFT | TA_RIGHT | TA_CENTER) ) case TA_LEFT case TA_RIGHT case ТА CENTER break; x -= abc.abcB; break; x -= abc.abcB/2; break; default: assert(false); switch ( GetTextAlign(hDC) & (TA_T0P | TA_BASELINE | TAJOTTOM) ) { case TA_T0P case TA_B0TT0M case ТА BASELINE break; у = - height; break; TEXTMETRIC tm: GetTextMetrics(hDC. & tm); у = - tm.tmAscent; } break; default: assert(false); pRect->left = x + min(abc.abcA. 0); pRect->right = x + abc.abcA + abc.abcB + max(abc.abcC. 0); pRect->top = y; pRect->bottom = у + height; return TRUE; BOOL ColorText(HDC hDC. int x. int y. LPCTSTR pString. int nCount. HBRUSH hFore) { HGDIOBJ hOld - SelectObject(hDC, hFore); RECT rect; GetOpaqueBox(hDC. pString. nCount, & rect. x. y); Продолжение &
874 Глава 15. Текст Листинг 15.7. Продолжение PatBlt(hDC. rect.left. rect.top, rect.right-rect.left, rect.bottom - rect.top, PATINVERT); int oldBk = SetBkModeChDC. TRANSPARENT); COLORREF oldColor = SetTextColorChDC, RGB(0, 0, 0)); TextOut(hDC. x, y. pString, nCount); SetBkModeChDC, oldBk); SetTextColor(hDC. oldColor); BOOL rslt = PatBltChDC. rect.left. rect.top. rect.right-rect.left. rect.bottom - rect.top. PATINVERT); SelectObject(hDC. hOld); return rslt; } Функция GetOpaqueBox проверяет метрику А первого символа и метрику С последнего символа и смотрит, не отрицательны ли они. Для проверки используется функция GetTextABCExtent, описанная в этой главе. Кроме того, мы учитываем разные комбинации флагов вертикального и горизонтального выравнивания и вносим соответствующие поправки в параметры прямоугольника. Функция ColorText дважды закрашивает прямоугольник при помощи функции PatBlt с растровой операцией PATINVERT. Перед выводом текста необходимо правильно задать режим заполнения фона и цвет текста и восстановить исходные значения после его завершения. На рис. 15.21 приведены примеры использования функций GrayString, ColorText и BitmapText. Рис. 15.21. Закраска текста функциями GrayString, ColorText и BitmapText В функциях ColorText и BitmapText задействованы три операции графического вывода, и при непосредственном выводе в экранный контекст устройства возникает неприятное мерцание. Проблема решается кэшированием вывода в промежуточном контексте устройства или использованием других приемов, не требующих многократной прорисовки. Учтите, что вследствие применения рас-
Эффекты при выводе текста 875 тровых операций сглаживание шрифтов не рекомендуется, поскольку на рисунке появятся пикселы довольно странных цветов. Начертания При создании логического шрифта приложение может выбрать различные варианты начертания (насыщенность, курсив, сглаживание, подчеркивание и перечеркивание) при помощи атрибутов структуры L0GF0NT. Семейство шрифтов TrueType обычно состоит из четырех физических файлов для поддержки четырех начертаний: обычного, полужирного, курсивного и полужирного курсивного. Система сопоставляет требования пользователя с атрибутами установленных шрифтов и находит оптимальное соответствие. Если шрифт с указанной насыщенностью недоступен, GDI пытается синтезировать его простейшим способом (только если доступный шрифт имеет обычную насыщенность, а запрашиваемый является полужирным). Имитация настолько проста, что различия заметны лишь при малом размере шрифта — GDI просто выводит строку дважды с горизонтальным смещением в один пиксел. Если у вас имеется только полужирный шрифт, GDI не сможет синтезировать по нему шрифт с обычным начертанием. Курсивные шрифты синтезируются гораздо проще. Как говорилось выше, последний параметр функции GetGI yphOutl i ne определяет матрицу преобразования 2x2, что позволяет подвергнуть глиф преобразованию сдвига. Имитация курсивного начертания сводится к небольшому сдвигу с учетом изменения в метриках шрифта. При описании функции GetGI yphOutl i ne упоминалось и о сглаживании, поддерживаемом шрифтовыми драйверами. В GDI для сглаживания текста применяются растры глифов с 17 уровнями серого. Чтобы запросить сглаживание для шрифта TrueType, передайте флаг ANTIALIASEDQUALITY в поле качества; контекст устройства при этом должен находиться в режиме High Color или True Color. Подчеркивание и перечеркивание реализуются GDI на основании данных, содержащихся в структуре OUTLINETEXTMETRIС шрифта TrueType. В некоторых приложениях поддерживаются разные стили подчеркивания и перечеркивания, но все они синтезируются по одним и тем же данным. Кроме эффектов, поддерживаемых на уровне логического шрифта, в приложениях часто реализуются и другие текстовые эффекты — негативный вывод, тени, рельеф (приподнятый и утопленный), обводка контуров и т. д. Негативный вывод реализуется легко — достаточно поменять местами цвет текста с цветом фона и вывести текст в непрозрачном режиме. Для точного воспроизведения эффектов теней и рельефа приходится работать на уровне растров и моделировать источники света. В текстовых редакторах обычно используется упрощенный подход — одна и та же строка выводится несколько раз с разными смещениями и цветами. Функция OffsetTextOut выводит текстовую строку до трех раз. Первые пять параметров аналогичны параметрам функции TextOut. Следующие две группы из трех параметров задают смещение и одет строки при повторном выводе. Сначала функция выводит первую смещенную строку с параметрами (x + dxl,y + dyl,crtl), затем вторую смещенную строку с параметрами (х + dx2,y + dy2,crt2), после чего
876 Глава 15. Текст выводит исходную строку от точки (х,у) с исходным цветом текста. Программа рисует увеличенный прямоугольник, а две смещенные строки рисуются в прозрачном режиме. BOOL OffsetTextOut(HOC hDC, int x. int у. LPCTSTR pStr. int nCount. int dxl, int dyl, COLORREF crl, int dx2, int dy2. COLORREF cr2) { COLORREF cr = GetTextColor(hDC); int bk = GetBkMode(hDC); if ( bk==0PAQUE ) { RECT rect; GetOpaqueBoxChDC. pStr, nCount. & rect. x, y); rect.left += min(min(dxl, dx2), 0) rect.right += max(max(dxl. dx2). 0) rect.top += min(min(dyl. dy2). 0) rect.bottom+= max(max(dyl. dy2). 0) ExtTextOutChDC. x. y. ET0_0PAQUE, & rect, NULL. 0. NULL); } SetBkMode(hDC. TRANSPARENT); if ( (dxl!=0) || (dyl!=0) ) { SetTextColor(hDC. crl); TextOut(hDC. x + dxl. у + dyl. pStr. nCount); if ( (dxl!=0) || (dyl!=0) ) { SetTextColor(hDC. cr2); TextOut(hDC. x + dx2. у + dy2. pStr. nCount); } SetTextColor(hDC. cr); BOOL rslt = TextOut(hDC. x. y. pStr. nCount); SetBkMode(hDC. bk); return rslt; } В следующем фрагменте показано, как при помощи функции OffsetTextOut создаются эффекты тени, приподнятого и утопленного рельефа. // Тень SetBkColor(hDC. RGB(0xFF. OxFF. 0)); // Желтый фон SetTextColorChDC. RGB(0. 0. OxFF)); // Синий текст OffsetTextOut(hDC. x. у. "Shadow". 6. 4. 4. GetSysColor(C0L0R_3DSHAD0W). // Тень 0. 0. 0);
Эффекты при выводе текста 877 // Приподнятый рельеф SetBkColor(hDC. RGB(0xD0. OxDO. 0)); // Темно-желтый фон SetTextColor(hDC, RGBCOxFF. OxFF, 0)); // Желтый текст OffsetTextOut(hDC. х, у. "Emboss", 6, -1, -1, GetSysColor(COLOR_3DLIGHT), 1.1. GetSysColor(COLORJDDKSHADOW)); // Углубленный рельеф SetBkColorChDC. RGBCOxFF. OxFF. 0)); // Желтый фон SetTextColor(hDC. RGB(0xD0. OxDO. 0)); // Темно-желтый текст OffsetTextOutChDC. x. y. "Engrave". 7. -1. -1. GetSysColor(C0L0R_3DDKSHAD0W). 1. 1. GetSysColor(C0L0R_3DLIGHT)): Тень имитируется предварительным выводом серого текста со смещением (4,4). Для создания эффекта приподнятого рельефа сначала выводится более светлый текст со смещением (-1, -1), а затем — более темный текст со смещением (1,1). Эффект утопленного рельефа имитируется аналогично, просто цвета меняются местами. Смещения, использованные в этом примере, подходят только для обычного вывода на экран. При выводе с увеличением или печати на принтере в них необходимо внести соответствующие изменения. На рис. 15.22 изображены различные варианты стилевого оформления текста: обычный, полужирный, сглаженный, курсив, полужирный курсив, подчеркнутый, перечеркнутый, негативный, тень, приподнятый и утопленный рельеф. Style Style Shadow Style Style Style Style Рис. 15.22. Начертания текста Геометрические эффекты До настоящего момента мы рассматривали только пропорциональный текст, выводимый вертикально. Настало время познакомиться с выводом текста с разной ориентацией и углом поворота символов, с искажением исходных пропорций и т. д.
878 Глава 15. Текст- Структура LOGFONT содержит два атрибута, связанных с углом вывода текста. В поле 1 fEscapement задается угол наклона базовой линии всей строки, а в поле 1 fomentation — угол наклона базовой линии отдельных символов. В архитектуре GDI эти углы могут различаться. Например, строка может выводиться горизонтально (IfEscapement = 0), но каждый символ в ней может быть повернут на 10°. Впрочем, независимое определение углов поддерживается только в расширенном графическом режиме и поэтому доступно только в Windows NT/2000. В совместимом графическом режиме поле 1 fEscapement определяет оба угла. Углы задаются целыми числами в десятых долях градуса. Для большинства приложений такой точности вполне достаточно. Нужные значения углов заносятся в структуру LOGFONT перед созданием логического шрифта. Сделать это нетрудно, но при частом изменении углов в функции вывода такое решение оказывается хлопотным и неудобным. Возможен другой подход — оставить тот же логический шрифт и определить другое мировое преобразование с поворотом логической системы координат. Одним из самых интересных применений смены наклона текста является размещение символов вдоль кривой (такая возможность поддерживается во многих графических пакетах). В GDI любую кривую можно преобразовать в траекторию GDI, заключив графические команды между вызовами BeginPath и EndPath. Полученная траектория преобразуется в ломаную функцией FlattenPath. После этого можно воспользоваться функцией GetPath для получения всех точек, определяющих траекторию (операции с линиями и кривыми подробно описаны в главе 8). Располагая массивом с данными траектории, можно получить смещение отдельного символа и вычислить координаты соответствующего отрезка ломаной. По координатам отрезка (х0,у0) - (х^) вычисляется точка вывода и угол наклона символа. В листинге 15.8 приведена группа функций для размещения текста вдоль кривой, определяемой текущей траекторией в контексте устройства. Листинг 15.8. Размещение текста вдоль траектории double dis(double xO, double yO, double xl, double yl) { xl -= xO; У1 -= yO; return sqrt( xl * xl + yl * yl ); } const double pi = 3.141592654; BOOL DrawChar(HDC hDC. double xO, double yO, double xl. double yl, TCHAR ch) { xl -= xO; yl -= yO; int escapement = 0; if ( (xKO.Ol) && (xl>-0.01) ) if ( yl>0 ) escapement = 2700;
Эффекты при выводе текста 879 else escapement = 900; else { double angle = atan(-yl/xl); escapement = (int) ( angle * 180 / pi * 10 + 0.5); } LOGFONT If; GetObject(GetCurrentObject(hDC, OBJJONT), sizeof(lf), &lf); if ( If.IfEscapement != escapement ) { If.IfEscapement = escapement; HFONT hFont = CreateFontIndirect(&lf); if ( hFont—NULL ) return FALSE; DeleteObject(SelectObject(hDC. hFont)); } TextOut(hDC. (int)xO, (int)yO. &ch. 1); return TRUE; } void PathTextOut(HDC hDC. LPCTSTR pString. POINT point[]. int no) { double xO = point[0].x; double yO = point[0].y; for (int i=l; i<no; i++) { double xl = point[i].x; double yl = point[i].y; double curlen = dis(x0. yO. xl. yl); while ( true ) { int length; GetCharWidth(hDC. * pString. * pString. & length); if ( curlen < length ) break; double xOO = xO; double yOO = yO; xO += (xl-xO) * length / curlen: yO += (yl-yO) * length / curlen; DrawChar(hDC. xOO. yOO. xO. yO. * pString): curlen -= length; Продолжение^
880 Глава 15. Текст Листинг 15.8. Продолжение pString ++; if ( * pString==0 ) { i = no; break; Основные операции со шрифтом в листинге 15.8 сосредоточены в функции DrawChar. При вызове функции передается манипулятор контекста устройства, две точки, определяющие отрезок, и код символа. По координатам точек функция вычисляет угол наклона, создает логический шрифт и при необходимости выбирает его вместо старого логического шрифта. После того как нужный шрифт выбран в контексте устройства, вывод одного символа сводится к простому вызову TextOut. В первой версии PathTextOut кривая, вдоль которой размещаются символы, определяется простым перебором точек массива. Вторая версия PathTextOut (на компакт-диске) предполагает, что текст размещается вдоль текущего объекта траектории в заданном контексте устройства. Перед тем как вызвать первую версию PathTextOut, она при помощи функций GDI преобразует траекторию и получает ее данные. На рис. 15.23 продемонстрировано изменение угла наклона всей строки и отдельных символов, применение функции PathTextOut, а также вертикальное азиатское письмо и шрифты с искаженными пропорциями. Тех,0 м $ fc!i Sj а _ о., -I- * ад 8 § & # оЪ Ч Я Я- 75/oW *ФЛ#\ $ т ш юо% w <V . % * 111 125% W 20 <%,„ l0^deg ^е 006 deg Рис. 15.23. Геометрические эффекты Слева внизу десять строк выводятся под углами от 0 до 90°. В диапазоне от 0 до 40° текст выводится с нулевым наклоном символов и с изменяющимся на-
Эффекты при выводе текста 881 клоном базовой линии строки. Все символы расположены вертикально, но после каждого символа позиция вывода смещается вправо и вверх в соответствии с заданным углом наклона базовой линии. Также обратите внимание на увеличивающийся прямоугольник фона. При различающихся углах наклона строки и отдельных символов текст не рекомендуется выводить в непрозрачном режиме. В диапазоне от 50 до 90° строки выводятся с одинаковыми углами наклона. Кривая, вдоль которой размещаются символы длинной строки в центре рисунка, демонстрирует работу функции PathTextOut. Фоновые прямоугольники показывают, что при отсутствии крутых изгибов текст достаточно плавно размещается вдоль кривой. Текст, выводимый под углом 270°, направлен сверху вниз, как в традиционной китайской и японской письменности. Впрочем, каждый символ дополнительно разворачивается на 90° против часовой стрелки. Для шрифтов, поддерживающих двухбайтовые кодировки (в частности, китайскую и японскую), предусмотрены специальные имена, при которых символы разворачиваются на 90° и принимают вертикальное положение. Все, что для этого требуется, — поставить символ «@» перед именем гарнитуры. Например, вместо «SimSun» используется имя «©SimSun». На рис. 15.23 приведены две строки из стихотворения времен династии Тан в китайской традиционной письменности (символы следуют сверху вниз, строки заполняют лист справа налево). Код следующего фрагмента выводит вертикально ориентированный текст. KLogFont 1f(-PointSizetoLogica1(hDC. 24), "@SimSun"); lf.mJf.lfQuality = ANTIALIASED_QUALITY; lf.mjf .lfCharSet = GB2312_CHARSET; If.mjf. If Escapement = 2700; lf.mjf.lfOrientation = 2700; KGDIObject font (hDC. If .CreateFontO); SetBkColor(hDC, RGB(0xFF. OxFF. 0)); WCHAR linel[] = { 0x59Dl. 0x82CF, 0x57CE. 0x5916. 0x5BD2. 0x5C71. 0x5BFA }; WCHAR line2[] = { 0x591C. 0x534A. 0x949F. 0x58F0. 0x5230, 0x5BA2. 0x8239 }; Text0utW(hDC. xO. yO. linel. 7): xO -= 45; TextOutWChDC, xO. yO, line2, 7); xO -= 50; TextOut (hDC. xO. yO. "270 degree". 10): При создании логического шрифта поле IfWidth структуры L0GF0NT обычно равно 0; это означает, что GDI следует подобрать шрифт с таким же аспектным отношением, как у графического устройства. Аспектным отношением называется отношение ширины пиксела к его высоте. Аспектное отношение текущего контекста устройства можно получить при помощи функции GetAspectRatioFilterEx. Практически все современные графические устройства обладают аспектным отношением 1:1, поэтому шрифт, созданный с нулевым полем IfWidth, обладает правильным соотношением ширины и высоты. При передаче ненулевой величины в поле IfWidth GDI сопоставляет ее со средней шириной шрифта и имитирует шрифт с искажением пропорций. Чтобы созданный шрифт был шире или уже исходного, следует перед заполнением поля IfWidth запросить среднюю ширину шрифта, хранящуюся в поле tmAveCharWidth структуры TEXTMETRIC. В еле-
882 Глава 15. Текст дующем фрагменте создается логический шрифт, ширина которого составляет заданный процент от ширины текущего шрифта. HFONT ScaleFontCHDC hDC. int percent) { LOGFONT If; Get0bject(6etCurrent0bject(hDC, OBJJONT). sizeof(lf), & If); TEXTMETRIC tm; GetTextMetrics(hDC, & tm); lf.lfWidth = (tm.tmAveCharWidth * percent + 50)/100; return CreateFontlndirectC&lf); } В правой части рис. 15.23 приведен текст, оформленный шрифтами, ширина которых составляет от 25 до 125 % от нормальной. В совместимом графическом режиме настройка анизотропной логической системы координат не обеспечивает масштабирования шрифтов — вам придется самостоятельно создать шрифт с нужным аспектным отношением. В расширенном графическом режиме вывод текста подчиняется настройке логической системы координат, как и все остальные графические элементы. При точном форматировании текста вычисление ширины может сопровождаться ошибками округления; для получения более точных данных воспользуйтесь вещественными метриками (см. раздел «Форматирование текста»). Работа с текстом в растровом формате Средства вывода текста в GDI подчиняются ограничениям, затрудняющим реализацию некоторых эффектов на «чисто текстовом» уровне. Например, если задать в совместимом графическом режиме логическую систему координат с противоположным направлением осей, все линии и растры выводятся справа налево и снизу вверх, но текстовые строки все равно будут выводиться сверху вниз и слева направо. Это весьма неприятно, особенно если вы хотите реализовать эффект зеркального отражения фрагмента с текстом. Существуют и другие ограничения — текст нельзя закрашивать кистью (см. предыдущий раздел), к нему нельзя применять растровые операции и альфа-наложение. Подобные проблемы решаются преобразованием текста в растровое изображение и выполнением операций на уровне растров. Текст преобразуется в растры двумя способами. Первый способ — получение растров отдельных глифов функцией GetGlyphOutline и имитация вывода текста посредством вывода растров. Второй способ — преобразование всей строки в один растр. Вывод текста с использованием растров глифов Класс KGlyph, разработанный в этой главе, позволяет легко написать функцию вывода текстовой строки по растрам глифов. Ниже приведена функция Bitmap- TextOutROP, выводящая растры глифов с применением тернарной растровой операции. На компакт-диске имеется упрощенная версия BitmapTextOut, которая выводит растры глифов в прозрачном режиме при помощи метода Kglyph: :DrawGlyph. BOOL BitmapTextOutROP(HDC hDC, int x. int y, const TCHAR * str, int count, DWORD гор)
Эффекты при выводе текста 883 { if ( count<0 ) count = Jxslen(str); KGlyph glyph; COLORREF crBack = GetBkColor(hDC); COLORREF crFore = GetTextColor(hDC); while ( count>0 ) { if ( glyph.GetGlyph(hDC. * str. GGO_BITMAP)>0 ) glyph.DrawGlyphROP(hDC, x + glyph.m_metrics.gmptGlyphOrigin.x. у - glyph.m_metrics.gmptGlyphOrigin.y, гор. crBack, crFore); x += glyph.mjnetrics.gmCelllncX: У +* glyph.m_metrics.gmCellIncY; str ++; count --; } return TRUE; } Функции BitmapTextOut и BitmapTextOutROP переводят задачу из текстовой области в область работы с растровыми изображениями. Тем самым решаются проблемы, связанные с зеркальным отражением в логической системе координат, и появляется возможность применения растровых операций. Впрочем, при использовании растровых операций при выводе растров глифов необходимо действовать осторожно, поскольку при выводе строки фоновые пикселы разных глифов могут перекрываться. Функция BitmapTextOutROP выбирает цвет, на который должны отображаться фоновые пикселы, в зависимости от цвета фона контекста устройства. Например, если вы хотите использовать операцию SRCAND, выберите белый цвет фона (RGB(OxFF.OxFF.OxFF)); в этом случае фоновые пикселы не будут влиять на вывод. Следующий фрагмент убеждает в том, что средства GDI не позволяют выполнить зеркальное отражение текста, а также иллюстрирует методику зеркального отражения текста с использованием функции BitmapTextOut и применение растровых операций при выводе текста. // Зеркальное отражение текста { SaveDC(hDC); SetMapMode(hDC. MM_ANIS0TR0PIC); SetWindowExtEx(hDC. 1.1, NULL); SetViewportExtEx(hDC. -1. -1. NULL); SetViewportOrgEx(hDC, 300. 100. NULL); ShowAxes(hDC. 600. 180); int x= 0. у = 0; const TCHAR * mess = "Reflection":
884 Глава 15. Текст SetTextAligrUhDC, TA_LEFT | TA_BASELINE); SetTextColorChDC, RGB(0. 0. OxFF)); // Синий (темный) BitmapTextOut(hDC. x, y. mess. Jxslen(mess). GG0_GRAY4_BITMAP); SetTextColor(hDC. RGB(0xFF. OxFF. 0)); // Желтый (светлый) TextOut(hDC. x, y. mess. _tcslen(mess)); RestoreDC(hDC. -1); // Растровые операции при выводе текста int x = 10; int у = 300; KLogFont 1f(-PointSizetoLogica1(hDC, 48). "Times New Roman"); If.mjf. If Weight = FW_B0LD; lf.m_lf.lfQuality= ANTIALIASED_QUALITY; KGDIObject font (hDC, If .CreateFontO); const TCHAR * mess = "Raster"; SetBkColor(hDC, RGB(0xFF. OxFF. OxFF)); SetTextColor(hDC. RGB(0xFF. 0. 0)); BitmapTextOutROP(hDC. x. y. mess. _tcslen(mess). SRCAND); SetBkColor(hDC. RGB(0. 0. 0)); SetTextColor(hDC. RGB(0. OxFF. 0)); BitmapTextOutROP(hDC. x+5. y+5. mess. _tcslen(mess). SRCINVERT); Фрагмент начинается с настройки анизотропного режима отображения, в котором ось х направлена справа налево, а ось у — снизу вверх. Сначала мы выводим синий (темный) текст функцией BitmapTextOut, а затем та же строка выводится в желтом (светлом) цвете функцией TextOut GDI. Строки выводятся в одинаковых логических координатах, но как видно из рис. 15.24, на экране они появляются в разных местах и с разной ориентацией. .лот?., чет. 49** 4*PP г*чл^ ч№* ^ЯЯЯР^ Л». I иорээфщ * ^шлиш_ #11 г-ж **w if ж i i *ш гж % * Soft-Shadow Рис. 15.24. Эффекты с использованием растровых изображений глифов fuzzy
Эффекты при выводе текста 885 Код второй половины фрагмента выводит красную строку, используя растровую операцию SRCAND, а затем повторяет тот же текст в зеленом цвете со смещением (5,5) и растровой операцией SRCINVERT. Чтобы фоновые пикселы не влияли на вывод, при операции SRCAND используется белый цвет фона, а при операции SRCINVERT — черный цвет фона. Преобразование текста в растр Если приложение хочет обработать растровые данные перед выводом в контексте устройства или сохранить их для последующего использования, вместо операций с отдельными глифами лучше преобразовать в растровый формат сразу всю строку. К полученному растру можно применить всевозможные графические алгоритмы — например, описанные в главах 10-13 этой книги. В листинге 15.9 приведено объявление класса KTextBitmap, преобразующего текстовую строку в DIB-секцию, с простым фильтром размытия. В классе KTextBitmap объединяются различные приемы работы с растровыми изображениями и текстом, рассмотренные в книге. Полная реализация имеется на прилагаемом компакт-диске. Листинг 15.9. Класс KTextBitmap: применение растровых эффектов к тексту // Преобразование текстовой строки в растровое изображение class KTextBitmap { public: HBITMAP HDC HGDIOBJ int int int int BYTE * m hBitmap; m hMemDC; mJiOldBmp: m width; mjieight; m dx; m dy; m_pBits; BOOL Convert(HDC hDC. LPCTSTR pString, int nCount, int extra); void ReleaseBitmap(void); KTextBitmapO; -KTextBitmapO; void Blur(void); BOOL Draw(HDC hDC, int x. int y, int rop=SRCC0PY); }: Вся основная работа выполняется классом KTextBitmap::Convert. Класс получает манипулятор контекста устройства, строку, количество символов и количество дополнительных пикселов, добавляемых с четырех краев сгенерированного растра. Дополнительное место используется при увеличении растра в результате применения графических алгоритмов. Функция вычисляет размеры растра по размерам фонового прямоугольника текста, создает 32-разрядную DIB-секцию, создает совместимый контекст устройства и копирует атрибуты из текущего контекста устройства в совместимый контекст. Местонахождение текста в растре регулируется в соответствии со значением метрики А первого символа, чтобы предотвратить возможное отсечение части глифа. После завершения под-
886 Глава 15. Текст готовки строка выводится в растре простым вызовом TextOut. Метод KTextBitmap: : Convert ограничивается простейшим преобразованием — он работает только с контекстами устройств в режиме отображения ММ_ТЕХТ. Чтобы продемонстрировать возможности по обработке текста уже после его преобразования к растровому формату, в класс KTextBitmap был добавлен метод Blur, который при помощи шаблона Average применяет усредняющий фильтр 3 х 3 к каналам RGB 32-разрядной DIB-секции. В нижней части рис. 15.24 иллюстрируется преобразование текста в растр и результат размытия. Слева находится исходная строка. Средняя строка прошла двукратную процедуру размытия, а правая строка была обработана фильтром четыре раза. В нижней части рисунка показан эффект размытой, нечеткой тени, полученный при помощи класса KTextBitmap, — для этого растр проходит 8-кратную процедуру размытия. KTextBitmap bmp; SetBkMode(hDC, OPAQUE); SetBkColor(hDC. RGB(0xFFp OxFF. OxFF)); // Белый SetTextColor(hDC, RGB(0x80. 0x80. 0x80)); // Серый const TCHAR * mess = "Soft-Shadow"; bmp.Convert(hDC. mess, _tcslen(mess), 7); for (int i=0; i<8; i++) bmp.BlurO; bmp.Draw(hDC, x, y); SetBkMode(hDC. TRANSPARENT); SetTextColor(hDC. RGB(0. 0. OxFF)); // Синий TextOut(hDC. x-5, y-5. mess, _tcslen(mess)); После того как KBitmapText сгенерирует DIB-секцию, текстовая задача переходит в чисто растровую область. К полученному растру можно применить графические алгоритмы, описанные в главе 12, создать альфа-каналы и даже вывести на поверхность DirectDraw. Эффекты рельефа на фоновых растрах Как упоминалось при описании эффектов рельефа в этом разделе, в стандартных операциях вывода текста применяется только однородный цвет. При выводе текста на фоновом растре часть изображения будет неизбежно закрыта. В таких случаях часто используются эффекты рельефа (приподнятый и утопленный) — на рисунке выделяются только светлые и темные края символов, а их внутренняя область остается заполненной фоном рисунка. Используя класс KTextBitmap в сочетании с растровыми операциями, можно сгенерировать изображение, состоящее только из пикселов светлых и темных краев, и вывести его в контексте устройства. В листинге 15.10 приведена функция TransparentEmboss, предназначенная для создания как приподнятого, так и утопленного рельефа.
Эффекты при выводе текста 887 Листинг 15.10. Создание приподнятого и утопленного рельефа void TransparentEmboss(HDC hDC, const TCHAR * pString. int nCount, COLORREF crTL, COLORREF crBR. int offset, int x. int y) { KTextBitmap bmp; // Сгенерировать маску с левым верхним и правым нижнем краем SetBkModeChDC. OPAQUE); SetBkColor(hDC. RGB(OxFF. OxFF. OxFF)); // Белый фон SetTextColor(hDC, RGB(0, 0. 0)); bmp.Convert(hDC, pString, nCount, offset*2); // Черный край // (левый верхний) SetBkModeChDC. TRANSPARENT); bmp.RenderText(hDC, offset*2. offset*2. pString, nCount); // Черный край // (правый нижний) SetTextColor(hDC. RGBCOxFF. OxFF, OxFF)); // Белый основной текст bmp.RenderText(hDC. offset, offset. pString, nCount); // Применить маску с левым верхним и правым нижним краем bmp.Draw(hDC. x, у, SRCAND); // Создать цветной растр с левым верхним и правым нижним краем SetBkColorChDC. RGB(0, 0. 0)); // Черный фон SetTextColorChOC. crTL); bmp.Convert(hDC, pString. nCount. offset); // Левый верхний край SetBkMode(hDC. TRANSPARENT); SetTextColor(hDC. crBR); bmp.RenderText(hDC. offset*2. offset*2. pString. nCount); // Правый // нижний край SetTextColor(hDC. RGB(0. 0. 0)); bmp.RenderText(hDC, offset, offset, pString, nCount); // Черный // основной текст // Вывести цветные края (левый верхний и правый нижний) bmp.Draw(hDC. x, у, SRCPAINT); } Функция TransparentEmboss работает по тому же принципу, который используется при выводе курсоров мыши и значков. Обычно при создании рельефного оформления текстовая строка выводится трижды — сначала в позиции (х - dx, у - dy) цветом левого верхнего края, затем в позиции (х + dx,y + dy) цветом правого нижнего края и, наконец, в позиции (х,у) основным цветом текста. При создании прозрачного рельефа достаточно вывести только два края, левый верхний и правый нижний, не перекрывающиеся с основным текстом. Сначала функция строит маску из черных пикселов на белом фоне. Маска выводится растровой операцией SRCAND на основном изображении и удаляет из него пикселы, расположенные на краях. Затем на черном фоне строится другая маска, в которой пикселы краев окрашены в соответствующие цвета, обеспечивающие создание эффекта рельефа. Маска объединяется с основным изображением растровой операцией SRCPAINT. На рис. 15.25 показан результат применения функции TransparentEmbossing.
888 Глава 15. Текст Рис. 15.25. Создание прозрачного рельефа (приподнятого и утопленного) Текст как совокупность кривых Некоторые задачи, связанные с выводом текста, не удается нормально решить ни в текстовом, ни в растровом формате. К числу таких задач относится прорисовка контура глифа, применение не аффинных преобразований при выводе или имитация объема. Подобные задачи лучше всего решаются преобразованием текста в совокупность отрезков и кривых. Существует три способа преобразования текстовой строки в отрезки и кривые. Первый способ — непосредственная работа с данными шрифта TrueType — рассматривался в главе 14. Второй способ — получение контуров глифов функцией GetGlyphOutline — описан в разделе «Нетривиальный вывод текста». Оба способа дают чрезвычайно точные описания контуров, к которым легко применить преобразования или специальные эффекты, не беспокоясь о потере точности. Применение траекторий GDI при выводе текста Третий способ преобразования текстовой строки в совокупность отрезков и кривых гораздо проще — выводимый текст преобразуется в объект траектории GDI. Если заключить функцию вывода текста TrueType/OpenType между функциями BeginPath/EndPath, то контуры глифов (с фоновым прямоугольником, если он присутствует) вместо вывода в контексте устройства будут включены в объект траектории GDI. Завершив построение траектории, приложение может воспользоваться функциями StrokePath, Fill Path и StrokeAndFillPath для прорисовки контуров и/или заполнения внутренней области глифов. Если данные траектории потребуются для преобразования, переведите внутреннее представление траектории в массив POINT с массивом флагов при помощи функции GetPath. Преобразованный контур можно вывести функцией PolyDraw.
Эффекты при выводе текста 889 Текст TrueType легко преобразуется в траекторию, поскольку эта возможность поддерживается на уровне GDI. Приведенный ниже простой пример ограничивается простым выводом контура. BeginPath(hDC); // Начать построение траектории TextOutChDC. x. у, mess. _tcslen(mess)); // Преобразовать один вызов EndPath(hDC); StrokePath(hDC); // Прорисовать контур текста текущим пером // (по умолчанию - черным) Преобразование текста в совокупность отрезков и кривых, представленную траекторией GDI, дает возможность для применения множества специальных эффектов. На рис. 15.26 представлены девять разных вариантов вывода текста. В примере 1 использована функция StrokePath со стандартным черным пером, хорошо подходящим для прорисовки контуров. В примере 2 использована функция Fill Path; результат очень похож на обычный текст, хотя и с некоторой утратой точности и отсутствием сглаживания. В примере 3 функция StrokeAndFillPath прорисовывает контур и заполняет внутреннюю область символов. В примере 4 контур прорисован пунктирным геометрическим пером, вследствие чего очертания глифа состоят из точек среднего размера. Примеры 5 и 6 демонстрируют разные атрибуты геометрических перьев (закругленные и заостренные соединения). В примере 7 контур сначала обводится толстым черным пером, а затем по толстому контуру рисуется тонкая белая линия, создающая эффект двойной прорисовки. Рис. 15.26. Вывод текста, преобразованного в траекторию Примеры 8 и 9 очень похожи. В обоих случаях функция StrokePath рисует серию контуров, начиная темными и толстыми и завершая светлыми и тонкими. В результате возникает более реалистичный объемный эффект. В примере 9 поверх полученного рисунка выводится исходный текст, создавая иллюзию углубления.
890 Глава 15. Текст Преобразование данных траекторий И все же возможности работы с траекториями средствами GDI ограничены. Например, объект траектории создается в системе координат устройства; после того как он создан, смена отображения логической системы координат в систему координат устройства не влияет на вывод траектории. Вам не удастся сместить траекторию даже на один пиксел. К счастью, в GDI предусмотрена функция GetPath- Data для получения данных, определяющих траекторию. В главе 8 мы создали простой класс KPathData для работы с данными траектории. Один из методов этого класса, MapPoints, применял двумерное преобразование координат ко всем точкам траектории. Данные, полученные в результате преобразования, передаются функции PolyDraw GDI для вывода. Метод MapPoints применяет преобразование только к контрольным точкам траектории, что подходит только для аффинных преобразований, сохраняющих линии и кривые Бе- зье. В результате произвольного двумерного преобразования прямая может превратиться в кривую. Но если мы ограничиваемся преобразованием контрольных точек, то при соединении преобразованных точек все равно получится прямая, а не кривая. Для выполнения произвольных преобразований линии и кривые следует разделить на достаточно мелкие сегменты и добавлять дополнительные точки, обеспечивающие более точное воспроизведение формы преобразованной кривой. В листинге 15.11 приведено определение класса KTransCurve, выполняющего общие двумерные преобразования, а также новый метод KPathData:: Draw. Полная реализация находится на компакт-диске. Листинг 15.11. Родовой класс преобразования траектории class KTransCurve { int m_orgx; // Первая точка фигуры int m_orgy; float xO; // Текущая последняя точка float yO; float m_dstx; float m_dsty; int m_seglen; // Длина сегмента virtual MapCfloat x, float y, float & rx, float & ry); virtual BOOL DrvLineTo(HDC hDC. int x. int y); virtual BOOL DrvMoveTo(HDC hDC. int x, int y); virtual BOOL DrvBezierTo(HDC hDC, POINT p[]); BOOL BezierTo(HDC hDC. float xl. float yl. float x2. float y2. float x3. float y3): public: KTransCurveCint seglen); BOOL MoveTo(HDC hDC. int x. int y); BOOL BezierTo(HDC hDC. int xl. int yl. int x2. int y2. int x3. int y3):
Эффекты при выводе текста 891 BOOL CloseFigureCHDC hDC); BOOL LineTo(HDC hDC, int x3. int y3): J.BOOL KPathData::Draw(HDC hDC. KTransCurve & trans, bool bPath) { if ( m_nCount==0 ) return FALSE: if ( bPath ) BeginPath(hDC): for (int i=0; i<m_nCount: i++) { switch ( m_pFlag[i] & - PT_CLOSEFIGURE ) { case PT_M0VET0: trans.MoveTo(hDC. m_pPoint[i].x, m_pPoint[i].y); break: case PTJ.INET0: trans.LineTo(hDC. m_pPoint[i].x. m_pPoint[i].y); break: case PT_BEZIERTO: trans.BezierToChDC. m_pPoint[i ].x. m_pPoint[i ].y. m_pPoint[i+l].x. m_pPoint[i+l].y. m_pPoint[i+2].x. m_pPoint[i+2].y); i+=2; break; default: assert(false): } if ( m_pFlag[i] & PT_CLOSEFIGURE ) trans.CloseFigure(hDC): } if ( bPath ) EndPath(hDC): return TRUE: } Класс KTransCurve решает две задачи: преобразование отдельных точек виртуальным методом Map и вывод, который может изменяться переопределением трех графических примитивов. Метод KPathData: :Draw передает данные траектории, возвращаемые функцией GetPathData, экземпляру класса KTransCurve — как для преобразования, так и для вывода. Ниже приведен простой пример использования классов преобразования траекторий.
892 Глава 15. Текст class KWave : public KTransCurve { int m_dx, m_dy; public: KWave(int seg, int dx. int dy) : KTransCurve(seg) { m_dx = dx; m_dy = dy; } virtual MapCfloat x, float y. float & rx, float & ry) { rx = x + m_dx; ry * у + m_dy + (int) (sin(x/50.0) * 20); // Использование класса KWave для вывода преобразованного контура текста BeginPath(hDC); TextOut(hDC, х. у, mess, _tcslen(mess)); // Построить траекторию EndPath(hDC); KPathData pd; pd.GetPathData(hDC); // Запросить данные траектории StrokeAndFi11Path(hDC); // Вывести исходные данные { KWave wave(8, 360. 0); // Преобразование pd.Draw(hDC, wave, true); // Применить преобразование, // построить новую траекторию StrokeAndFiHPath(hDC); // Вывести новую траекторию } Класс KWave объявляется производным от KTransCurve, и в нем переопределяется ключевой метод Map. Конструктору передаются длины сегмента и смещения, прибавляемые к каждой точке. Метод Map прибавляет заданные смещения, а к вертикальной координате прибавляет дополнительную синусоидальную составляющую с периодом 50 пикселов. Данное преобразование не является аффинным, поскольку оно превращает горизонтальные линии в тригонометрические кривые. На рис. 15.27 показан эффект, созданный классом KWave, а также эффекты других классов, производных от KTransCurve. Исходный контур глифа изображен в левом верхнему углу рисунка. Справа от него показан результат применения синусоидального преобразования класса KWave. Обратите внимание: горизонтальные линии в буквах «V», «U» и «Е» преобразованы в кривые, а не в прямые. В левой нижней части рисунка к каждому кандидату на преобразование применяется небольшое случайное смещение (см. класс KRandom на компакт-диске). Правый нижний рисунок относится к теме следующего подраздела.
Эффекты при выводе текста 893 Рис. 15.27. Преобразование траекторий с использованием класса KTransCurve Трехмерный текст Итак, мы знаем, как получить контур текстовой строки, и у нас имеется класс для преобразования точек и разбиения кривой на сегменты. Все это позволяет легко создавать несложные объемные эффекты при выводе текста. Из всех типов трехмерных поверхностей проще всего создаются экстру зиои- ные поверхности. В общем случае экструзионная поверхность генерируется на основе плоской базовой кривой перемещением в трехмерном пространстве вдоль заданной траектории. Допустим, у вас имеется кривая на плоскости (х,у), расположенной в трехмерном пространстве (x,y,z) при z = 0. Кривая перемещается вдоль оси z к плоскости z = -10. В результате перемещения создается экструзионная поверхность, образованная всеми точками промежуточных кривых в процессе движения. В классе KTransCurve вывод прямых и кривых в конечном счете сводится к функции DrvLineTo, обеспечивающей вывод отдельного отрезка. Результат перемещения отрезка, заданного точками (х0,у0) и (х^), вдоль оси z на расстояние depth представляет собой прямоугольник, определяемый четырьмя углами: (xl.yl.O). (x2.y2.0). (x2.y2.depth), (xl.yl.depth) Экструзионная поверхность представляет собой совокупность всех таких прямоугольников в трехмерном пространстве; нам остается лишь отобразить их на плоскость. Если наблюдатель находится в точке (ex,ey,ez), для отображения точки (px,py,pz) из трехмерного пространства в двумерное можно воспользоваться проекцией перспективы. В листинге 15.12 приведена частичная реализация класса KExtrude, обеспечивающего применение проекции перспективы и простейший вывод экструзион- ных поверхностей. Полный код находится на компакт-диске. Листинг 15.12. Создание экструзионных поверхностей и объемных эффектов при выводе текста class KExtrude : public KTransCurve { int m_dx, m_dy; int m_xO. m_yO; Продолжение #
894 Глава 15. Текст Листинг 15.12. Продолжение int m_depth; int m_eye_x; int m_eye_y; int m_eye_z; public: KExtrude(int seglen. int dx. int dy, int depth, int ex. int ey, int ez) : KTransCurve(seglen); virtual Map(float x, float y, float & rx. float & ry); virtual BOOL DrvBezierTo(HDC hDC, POINT p[]); virtual BOOL DrvMoveToCHDC hDC. int x. int y); void Map3D(long & x. long & y. int z) { x = ( m_eye_z * x - m_eye_x * z) / ( m_eye_z - z); у = ( m_eye_z * у - m_eye_y * z) / ( m_eye_z - z); vi ( rtual BOOL DrvLineTo(HDC hDC. int POINT p[5] « Map3D(p[0].x. Map3D(p[l].x. Map3D(p[2].x. Map3D(p[3].x. Map3D(p[4].x. m_xO = xl; m_yO = yl; { m_xO. mxO.fr p[0].y. p[l] p[2] p[3] p[4] y. y. У. y. return Polygon(hDC P m yO. xl. У0 }: 0); 0); m_depth); m depth); 0); . 4); xl. yi. int yl) xl. yi m_x0. m_y0. Метод KExtrude: :Ma3D выполняет перспективную проекцию из точки наблюдения с координатами (т_еуе_х,т_еуе_у,т_еУе_2)- Метод KExtrude: :DrvLineTo рисует отдельные прямоугольники, образующие поверхность, после отображения трехмерных точек на плоскость. Обратите внимание: класс KExtrude не создает нового объекта траектории; каждый прямоугольник выводится отдельным вызовом Polygon. Дело в том, что режимы заполнения многоугольников GDI не справляются с некоторыми видами экструзионных поверхностей. Как показано на рис. 15.27, класс KExtrude позволяет создавать простейшие объемные эффекты, однако его упрощенная реализация не поддерживает отсечения невидимых поверхностей и вычисления освещенности — для этого лучше воспользоваться каким-нибудь профессиональным пакетом. В книге эта тема не рассматривается. Текст как регион Преобразование текста в траекторию открывает и другие возможности — к вашим услугам богатый набор функций GDI для работы с регионами. Замкнутую
Итоги 895 траекторию в контексте устройства можно преобразовать в объект региона (функция PathToRegion) или воспользоваться ей для отсечения (функция SetClipPath): HRGN PathToRegionCHDC hDC); BOOL SelectClipPath(HDC hDC, int iMode); Функция PathToRegion преобразует текущую траекторию в объект региона, заданный в системе координат устройства. Полученный регион может использоваться для отсечения, проверки принадлежности или для других целей. Второй параметр iMode управляет режимом объединения региона, полученного в результате преобразования, с текущим регионом отсечения. Например, флаг RGNAND указывает на то, что за новый регион отсечения следует принять пересечение траектории с текущим регионом отсечения. Преобразование текста в регион через траекторию упрощает некоторые операции. Например, в простейшем способе заполнения текста растровым изображением строка преобразуется в регион, после чего строка выводится с назначенным регионом отсечения. Ниже приведено другое решение, которое обходится без раздражающего мерцания. BOOL BitmapText2(HDC hDC, int x, int у. LPCTSTR pString. int nCount, HBITMAP hBmp) { RECT rect; GetOpaqueBox(hDC. pString, nCount. & rect, x. y); HDC hMemDC = CreateCompatibleDC(hDC); HGDIOBJ hOld - SelectObjectChMemDC, hBmp); BeginPath(hDC): SetBkModeChDC, TRANSPARENT); TextOut(hDC. x, y, pString, nCount); // Создать траекторию EndPath(hDC); SelectClipPath(hDC. RGN_C0PY); // Преобразовать траекторию в регион BOOL rslt - BitBlt(hDC, rect.left, rect.top, rect.right-rect.left, rect.bottom - rect.top, hMemDC, 0, 0, SRCCOPY); SelectObjectChMemDC, hOld); DeleteObject(hMemDC); return rslt; } Итоги Глава, посвященная выводу текста в Win32 GDI, подошла к концу. Мы подробно рассмотрели множество тем, от создания логических шрифтов, получения метрических данных и простейшего вывода до нетривиального форматирования и применения всевозможных эффектов.
896 Глава 15. Текст В этой главе было убедительно показано, что ограниченные возможности WYSIWYG-форматировании текста в GDI обусловлены целочисленными метриками, используемыми в работе GDI. Чтобы преодолеть эти ограничения, приложение может запросить точные значения метрик по эталонному шрифту, размер которого совпадает с размером em-квадрата. Точные значения метрик обеспечивают форматирование текста, не зависящее от разрешения графических устройств и текущего масштаба. Для создания специальных эффектов текст обычно преобразовывается в растр или в контур. В этой главе были разработаны некоторые классы для решения стандартных задач — получения растров и контуров отдельных глифов средствами GDI, преобразования целых строк в растры и объекты траекторий GDI. Мы рассмотрели родовой класс для применения к траекториям не аффинных преобразований; этот класс даже позволяет создавать простые трехмерные эффекты. С этой главой завершается наше знакомство со всеми основными группами графических примитивов GDI — пикселами, линиями и кривыми, растрами и текстом. В следующей главе мы поговорим о том, как сохранить команды GDI в стандартных и расширенных метафайлах, как происходит обработка и воспроизведение метафайлов. В главе 17 мы вернемся к теме аппаратно-независимого форматирования текста в контексте печати. Глава 18 посвящена интерфейсу DirectDraw. Пример программы К этой главе прилагается демонстрационная программа Text (табл. 15.5). Впрочем, главное — это даже не программа, а набор родовых функций и классов, созданных в этой главе. Таблица 15.5. Программа главы 15 Каталог проекта Описание Samples\Chapt_15\Text В меню File содержатся команды для вызова расширенного диалогового окна выбора шрифта, демонстрации системы подстановки шрифтов PANOSE, диалоговых окон для анализа структуры TEXTMETRIC и — самое важное — демонстрационных окон. Выбрав команду File ► Demo, вы получаете доступ к 20 с лишним окнам, наглядно демонстрирующим множество тем — от использования стандартных шрифтов до создания специальных эффектов посредством преобразования текста в кривые
Глава 16 Метафайлы Приложения часто обмениваются друг с другом графическими данными, для чего графические данные требуется сохранять в файлах. Формат BMP, широко используемый в Windows, подходит лишь для обмена растровыми данными. Для поддержки как растровых, так и векторных графических данных используются специальные графические форматы — 16-разрядные метафайлы Windows и 32- разрядные расширенные метафайлы Windows. Эти форматы широко применяются в библиотеках графических заготовок, при работе с буфером обмена (clipboard), при обмене данных между сервером и клиентом OLE, а также в работе спулера. Настоящая глава посвящена двум форматам метафайлов Windows, различным способам их создания, использования и расшифровки. Общие сведения о метафайлах У любого графического приложения есть свои сильные и слабые стороны. Но когда опытный пользователь правильно подходит к работе, каждое приложение вносит свой вклад в достижение конечного результата. Например, в CorelDraw можно создать векторный рисунок со сложными специальными эффектами, в PhotoShop — отретушировать фотографическое изображение, в Visio — построить диаграмму или блок-схему, а в Word — отредактировать текст. Когда эти приложения работают вместе, им необходим некий общий формат, в котором они могли бы обмениваться графическими данными. Формат BMP годится лишь для растров и фотографий, и то не для всех — он плохо подходит для фотографий высокого разрешения из-за отсутствия качественного сжатия. Универсальный формат обмена графическими данными должен поддерживать все основные графические элементы, в том числе пикселы, линии, кривые, замкнутые фигуры, текст и растры. Формат метафайлов Windows (WMF) был разработан компанией Microsoft для 16-разрядных версий Windows. Метафайл представляет собой последова-
898 Глава 16. Метафайлы тельность записанных команд GDI из всех основных категорий графических примитивов 16-разрядного интерфейса GDI. Возможности метафайлов Windows в значительной мере ограничиваются их зависимостью от устройств и приложений (похожие проблемы существуют и для аппаратно-зависимых растров). Метафайл Windows не располагает информацией о размере изображения, исходном разрешении или состоянии палитры устройства, на котором он записывался. При воспроизведении метафайла на другом устройстве с другим набором цветов и разрешением приложение не сможет масштабировать изображение до нужных размеров и обеспечить правильную цветопередачу. Существуют и другие ограничения, накладываемые GDI. В 32-разрядных версия Windows, начиная с Windows NT 3.51, компания Microsoft использует новый 32-разрядный формат метафайлов, называемый расширенным форматом метафайлов (Enhanced Metafile, EMF). По сравнению с WMF этот формат поддерживает 32-разрядную систему координат и новые 32-разрядные функции GDI, содержит заголовок с геометрическими данными и палитрой и даже обеспечивает некоторую поддержку OpenGL. Хотя WMF продолжает широко использоваться в библиотеках графических заготовок, формат EMF, в меньшей степени зависящий от устройства и поддерживающий новые функции GDI, завоевывает все большую популярность. В этой главе основное внимание уделяется формату EMF, хотя иногда упоминается и WMF. Существует две взаимосвязанных концепции метафайла: метафайл как объект GDI и метафайл как внешний формат файлов. В принципе можно провести аналогию с DIB-секциями как объектами GDI и растровыми файлами в формате BMP, хотя метафайл как объект GDI находится с физическим файлом в более «близких отношениях». Создание расширенного метафайла Расширенный метафайл является таким же объектом GDI, как, например, объект DIB-секции или объект траектории. Объект расширенного метафайла однозначно определяется своим манипулятором объекта GDI, относящимся к типу HENHMETAFILE. Функция GetObjectType возвращает для расширенного метафайла идентификатор типа OB JENHMETAFILE. Расширенный метафайл представляет собой последовательность 32-разрядных команд GDI. Следовательно, основным способом создания расширенных метафайлов является запись серии команд GDI. В GDI предусмотрены две функции, которые начинают и завершают запись расширенного метафайла. HDC CreateEnhMetaFileCHDC hdcRef, LPCTSTR lpFileName, CONST RECT * lpRect. LPCTSTR IpDescription); HENHMETAFILE CloseEnhMEtaFile(HDC hDC); Функция CreateEnhMetaFile создает специальный контекст устройства, используемый при записи расширенного метафайла. Она всего лишь готовит условия для создания расширенного метафайла — по аналогии с тем, как функция BeginPath начинает построение объекта траектории GDI. Первый параметр, hdcRef, ссылается на эталонный контекст устройства, данные которого потребуются при записи EMF. Если параметр hdcRef равен NULL, GDI принимает в качестве эталона
Общие сведения о метафайлах 899 текущий экран. Во втором параметре, IpFileName, может передаваться имя файла на диске или NULL. Если передается имя файла, после завершения записи файловый вариант метафайла сохраняется на диске; если передается NULL, метафайл создается в памяти. Третий параметр определяет размеры расширенного метафайла в единицах 0,01 мм. Заданный прямоугольник (кадр) сохраняется в расширенном метафайле и определяет начало координат и размеры области, в которой воспроизводится EMF. Если вместо прямоугольника передается NULL, GDI вычисляет ограничивающий прямоугольник по всем командам вывода; полученный прямоугольник может и не совпадать с тем, который подразумевался при создании метафайла. Следующая функция преобразует прямоугольник в логических координатах контекста устройства в физические единицы 0,01 мм. // Преобразовать прямоугольник из логических координат // в физические единицы 0.01 мм void MaplOum(HDC hDC, RECT & rect) { int widthmm = GetDeviceCaps(hDC, H0RZSIZE); int heightmm = GetDeviceCaps(hDC, VERTSIZE); int widthpixel = GetDeviceCaps(hDC, H0RZRES); int heightpixel= GetDeviceCaps(hDC. VERTRES); LPtoDP(hDC. (POINT *) & rect. 2); rect.left =( rect.left *widthmm *100+widthpixel/2) / widthpixel; rect.right = ( rect.right *widthmm *100+widthpixel/2) / widthpixel; rect.top = ( rect.top *heightmm*100+heightpixel/2) / heightpixel; rect.bottom = ( rect.bottom*heightmm*100+heightpixel/2) / heightpixel; } Обратите внимание на применение индексов H0RZSIZE, VERTSIZE, H0RZRES и VERTRES функции GetDeviceCaps для преобразования координат в физические единицы, используемые GDI для заполнения полей заголовочной структуры расширенного метафайла. Для экранных устройств разрешение (в пикселах на дюйм) обычно не совпадает с логическим разрешением, возвращаемым для индексов LOGPIXELX и LOGPIXELY. Например, значения LOGPIXELX и LOGPIXELY обычно равны 96 dpi для экранного режима с мелкими шрифтами, а значение H0RZRES всегда равно 320 мм; если H0RZSIZE = 1152 пиксела, то для создания EMF разрешение экрана равно 91,44 dpi. Последний параметр функции CreateEnhMetaFile содержит необязательное текстовое описание, сохраняемое в метафайле. Обычно описание состоит из имен приложения и документа, разделенных нуль-символом. Следовательно, если передается строка, отличная от NULL, ее следует завершить двумя нулями. Если вызов завершается успешно, CreateEnhMetaFile создает манипулятор контекста устройства для расширенного метафайла. Этот манипулятор передается всем функциям GDI, вызываемым в процессе записи. После завершения записи вызовите функцию CloseEnhMetafile, которая закрывает манипулятор контекста и возвращает манипулятор расширенного метафайла. Построение метафайла отчасти напоминает построение объекта траектории GDI. Впрочем, метафайл гораздо сложнее объекта траектории GDI, описываемого массивом точек и массивом флагов. По этой причине GDI использует для
900 Глава 16. Метафайлы построения метафайла специальный контекст устройства (тогда как траектория создается в обычном контексте, переведенном в режим построения траектории). Ниже приведен простой пример создания расширенного метафайла. Функция TestEMFGen принимает за эталонное устройство текущий экран и вычисляет размер кадра по размерам окна рабочего стола. После создания метафайлового контекста устройства в центре поверхности устройства выводится простой прямоугольник. Функция создает объект расширенного метафайла и сохраняет его в файле на диске. При воспроизведении метафайла в масштабе 1:1 в центре области 320 х 240 мм рисуется прямоугольник. HENHMETAFILE TestEMFGen(void) { RECT rect; HDC hdcRef = GetDC(NULL); GetClientRect(GetDesktopWindow(). &rect); MaplOum(hdcRef. rect); HDC hDC - CreateEnhMetaFileChdcRef, "c:\\test.emf\ & rect, MEMF.EXE\OTestEMF\On); ReleaseDC(NULL. hdcRef): if ( hDC ) { GetCIi entRect(GetDesktopWi ndow(). &rect); Rectangle(hDC. rect.right/3, rect.bottom/3. rect.right*2/3. rect.bottom*2/3); return CloseEnhMetaFile(hDC); } return NULL: } Воспроизведение расширенного метафайла Созданный метафайл воспроизводится в контексте устройства по своему манипулятору. Вы также можете открыть расширенный метафайл, хранящийся в файле на диске, и получить манипулятор расширенного метафайла. Ниже перечислены соответствующие функции. HENHMETAFILE GetEnhMetaFileCLPCTSTR IpszMetaFile); BOOL DeleteEnhMetaFileCHENHMETAFILE hemf); BOOL PlayEnhMetaFileCHDC hdc. HENHMETAFILE hemf. CONST RECT * lpRect); Функция GetEnhMetaFi le открывает файл с заданным именем, создает объект расширенного метафайла для работы с данными и возвращает его манипулятор. Аналогичный манипулятор возвращается и при завершении построения расширенного метафайла функцией CloseEnhMetaFile. После вызова CloseEnhMetaFile или GetEnhMetaFi le заданный файл считается используемым GDI и не может быть удален до удаления объекта функцией Del eteEnhMetaFi I e.
Общие сведения о метафайлах 901 Завершив работу с расширенным метафайлом, приложение должно вызвать функцию DeleteEnhMetaFile (по аналогии с функцией DeleteObject, вызываемой для других объектов GDI). Функция DeleteEnhMetaFile удаляет объект расширенного метафайла вместе со всеми ресурсами, выделенными для него GDI. После вызова функции физический файл на диске освобождается, но не удаляется. Чтобы удалить физический файл, следует вызвать функцию DeleteFile файловой системы. Если вместо имени файла при вызове CreateEnhMetaFile передается NULL, внешний файл удалять не нужно. Располагая манипулятором расширенного метафайла, можно воспользоваться функцией PlayEnhMetaFile для воспроизведения любой команды GDI этого метафайла в контексте устройства. Хотя прототип функции PlayEnhMetaFile выглядит просто, внутренний механизм ее работы чрезвычайно сложен. Функция PlayEnhMetaFile получает три параметра: манипулятор приемного контекста устройства, манипулятор исходного расширенного метафайла и прямоугольник, заданный в логических координатах приемного устройства. Прямоугольник соответствует кадру, указанному при создании метафайла функцией CreateEnhMetaFile. Следующий простой пример иллюстрирует связь между построением и воспроизведением EMF. void SampleDraw(HDC hDC, int x. int y) { Ellipse(hDC, x+25, y+25, x+75. y+75); SetTextAlign(hDC. TA_CENTER | TA_BASELINE); const TCHAR * mess = "Default Font"; TextOutChDC. x+50, y+50. "Default Font". _tcslen(mess)); } void DemoJMFScaleCHDC hDC) { // Построить EMF HDC hDCEMF - CreateEnhMetaFile(hDC. NULL. NULL. NULL); SampleDraw(hDCEMF. 0. 0); HENHMETAFILE hSample - CloseEnhMetaFile(hDCEMF); HBRUSH yellow - CreateSolidBrush(RGB(OxFF. OxFF. 0)); // Вывести команды, записанные в EMF { RECT rect = { 10. 10. 10+100. 10+100 }; FillRect(hDC. & rect. yellow); SampleDraw(hDC. 10. 10); // Оригинал } for (int test-0. x=120; test<3; test++) { RECT rect = { x. 10. x+(test/2+l)*100. 10+((test+1)/2+1)*100 };
902 Глава 16. Метафайлы FillRect(hDC. & rect. yellow); PlayEnhMetaFile(hDC. hSample, & rect); x = rect.right + 10; DeleteObject(yellow); DeleteEnhMetaFile(hSample); } Содержимое простейшего метафайла1 генерируется функцией SampleDraw. Предполагается, что эта функция рисует круг 50 х 50 единиц в центре квадрата 100 х 100 и выводит текстовую строку в центре круга шрифтом по умолчанию. Функция Demo_EMFSca1e управляет всем выводом. Сначала она создает EMF в памяти (то есть EMF без файла на диске) при помощи функции SampleDraw. Та же функция Sampl eDraw рисует то, что было сохранено в метафайле, в левом верхнем углу экрана — просто для сравнения. После этого функция в цикле воспроизводит EMF в трех прямоугольниках разных размеров (100 х 100, 100 х 200 и 200 х 200). Для наглядности соответствующие участки экрана закрашиваются желтым фоном. Результат показан на рис. 16.1. Default Font Default Font Default Font D Рис. 16.1. Воспроизведение расширенного метафайла с кадром по умолчанию Слева показан результат выполнения двух исходных команд рисования в EMF — круг с текстовой строкой в центре квадрата 100 х 100. На втором рисунке показан результат воспроизведения EMF в квадрате 100 х 100. Все отступы куда-то исчезли, а текст и круг масштабируются с искажением пропорций. Третий и четвертый рисунки выглядят примерно так же, хотя в них масштабирование выполняется по прямоугольникам других размеров. Все это произошло из-за того, что EMF был сгенерирован GDI без указания прямоугольника кадра; вернее, прямоугольник кадра был вычислен автоматически по ограничивающему прямоугольнику всех графических команд. В нашем примере ограничивающий прямоугольник определяется координатами {11, 25, 1 Здесь и далее под термином «метафайл» подразумевается расширенный метафайл, то есть EMF. — Примеч. перев.
Общие сведения о метафайлах 903 88, 74}, а прямоугольник кадра — {3,06, 6,94, 24,44, 20,56} (в миллиметрах). Обратите внимание: отношение ширины к высоте равно 1,56:1 вместо 1:1, а все отступы от краев были исключены из кадра. При воспроизведении EMF функцией PlayEnhMetaFile GDI отображает прямоугольник кадра на прямоугольник, переданный при вызове PlayEnhMetaFile. Правильная настройка прямоугольника кадра в этом примере выполняется следующим образом: RECT rect = { 0. 0. 100. 100 }; // Логический прямоугольник кадра Mapl0um(hDC, rect); // Перевести в единицы 0.01 мм hDCEMF = CreateEnhMetaFileChDC. NULL. &rect. NULL); // Создать с кадром На рис. 16.2 показаны результаты воспроизведения EMF с правильно заданным прямоугольником кадра. Default Font Default Font Default Font D e fa u It Font Рис. 16.2. Воспроизведение расширенного метафайла с правильно заданным кадром Как видно из рисунка, определение кадра 100 х 100 при построении EMF гарантирует, что при воспроизведении EMF в квадрате будет выдержан масштаб и основные пропорции графических элементов. Во всяком случае, круг на рисунке масштабируется превосходно. Впрочем, текстовая строка явно искажается, хотя каждый символ вроде бы расположен в правильной позиции; это связано с тем, что при построении EMF применялся шрифт, выбранный в контексте устройства по умолчанию. Подробности рассматриваются в разделе «Строение расширенных метафайлов». Получение информации о расширенном метафайле Вы убедились в том, что связь между кадром EMF и прямоугольником, указанным при вызове PlayEnhMetaFile, чрезвычайно важна для правильного размещения и масштабирования расширенного метафайла. Если вы не знаете, как строился метафайл, вам придется каким-то образом получить информацию о нем — например, данные прямоугольника кадра. При построении EMF GDI записывает в него заголовок с основными атрибутами метафайла. Для получения этой информации в GDI определяются специальные функции.
904 Глава 16. Метафайлы typedef struct tagENHMETAHEADER DWORD DWORD RECTL RECTL DWORD DWORD DWORD DWORD WORD WORD DWORD DWORD DWORD SIZEL SIZEL DWORD DWORD DWORD SIZEL iType; nSize; rclBounds; rclFrame; dSignature; nVersion; nBytes; nRecords; nHandles; sReserved; nDescription; offDescription; nPalEntries; szlDevice; szlMillimeters; cbPixelFormat; offPixel Format; bOpenGL; szlMicrometers; ENHMETAHEADER; // // // // // // // // // // // // // // // // // // EMRJEADER Размер в байтах, включая дополнение Границы в единицах устройства // Прямоугольник кадра в единицах 0.01 мм ENHMETAJIGNATURE // Номер версии Размер метафайла в байтах Количество записей в метафайле Количество манипуляторов в таблице Длина строки описания Смещение строки описания Количество элементов в палитре метафайла Размер эталонного устройства в пикселах Размер эталонного устройства в миллиметрах 4.0 Размер РIXELFORMATDESCRIPT0R 4.0 Смещение PIXELF0RMATDESCRIPT0R 4.0 Флаг наличия команд OpenGL 5.0 Размер эталонного устройства в микрометрах UINT GetEnhMetaFileHeaderCHENHMETAFILE hemf. UINT cbBuffer. LPENHMETAFILEHEADER); UINT GetEnhMetaFileDescription(HENHMETAFILE hemf. UINT cchBuffer. LPTSTR IpszDescription); Типичный метафайл всегда начинается со структуры ENHMETAHEADER. Первые два поля ENHMETAHEADER соответствуют общей структуре формата EMF, в которой каждая запись должна начинаться с 32-разрядного идентификатора типа записи и 32-разрядного размера. С каждым типом записи EMF связывается уникальный идентификатор типа в интервале от EMRMIN до EMRMAX. В настоящее время EMR_MIN = 1, a EMR_MAX = 122. В EMF постоянно добавляются новые типы записей для новых возможностей GDI. Например, идентификатор EMRALPHABLEND = 114, соответствующий функции GDI AlphaBlend, не поддерживался в системах, предшествующих Windows 98 и Windows 2000. В поле nSize хранится общее количество байтов в записи EMF, включающее iType, nSize и другие открытые поля вместе с возможными дополнениями. Многие записи EMF имеют переменный размер, поэтому включение поля nSize позволяет GDI переходить от одной записи EMF к другой. Поле rcBounds содержит данные ограничивающего прямоугольника графических команд EMF в системе координат устройства. Для накопления данных ограничивающего прямоугольника в процессе вывода в контексте устройства применяется пара редко используемых функций GDI. Функция SetBoundsRect разрешает/запрещает накопление данных или присваивает/сбрасывает данные прямоугольника; функция GetBoundsRect возвращает накопленные данные. Разумеется, GDI сохраняет данные ограничивающего прямоугольника, накопленные в процессе построения EMF, в заголовке EMF. Используя данные ограничивающего прямоугольника, приложение может удалить белую «рамку» вокруг воспроизведенного метафайла.
Общие сведения о метафайлах 905 Поле rcl Frame содержит прямоугольник кадра, заданный приложением при вызове CreateEnhMetaFile. Если передается значение NULL, GDI автоматически вычисляет его по ограничивающему прямоугольнику. Прямоугольник кадра хранится в единицах 0,01 мм, что эквивалентно устройству с разрешением 2540 dpi. Используя данные кадра, приложение масштабирует EMF по предполагаемым физическим размерам при воспроизведении на другом устройстве. После прямоугольника кадра в заголовке расположены служебные данные. Поле dSignature должно содержать уникальную сигнатуру расширенного метафайла, 0x464d4520 в шестнадцатеричной записи или «EMF» в символьном формате. Поле nVersion содержит используемую версию EMF. Хотя существует несколько второстепенных версий EMF, эксперименты показывают, что поле nVersion всегда равно 0x10000. Например, не все метафайлы содержат три поля, относящихся к внедрению данных OpenGL, а последнее поле szMicrometers появилось только в Windows 98 и 2000. Несмотря на это, во всех расширенных метафайлах используются одинаковые номера версий. Поле nBytes содержит общую длину EMF в байтах. Количество записей в EMF вместе с заголовком, всеми командами GDI и завершающей записью хранится в поле nRecords. Манипуляторы объектов GDI интерпретируются в EMF особым образом. Вспомните, о чем говорилось в главе 3 — манипуляторы относятся к временным объектам GDI и не имеют смысла вне адресного пространства процесса, тем более на другом компьютере в неизвестный момент времени. При записи команд GDI, использующих манипуляторы объектов (например, SelectObject), манипуляторы заменяются индексами внутренней таблицы, существующей только во время воспроизведения EMF. При воспроизведении GDI создает таблицу, в которой хранятся реально используемые манипуляторы, и берет на себя преобразование индексов EMF в манипуляторы GDI. Для стандартных объектов GDI предусмотрено особое обозначение, поэтому в таблице достаточно хранить только манипуляторы нестандартных объектов. При удалении объекта GDI в EMF соответствующий элемент таблицы освобождается и может использоваться заново. Поле nHandles заголовка EMF определяет размер таблицы объектов GDI, которую необходимо создать для воспроизведения метафайла. Следовательно, это поле отражает не общее количество манипуляторов объектов GDI, используемых в EMF, а лишь максимальное количество открытых нестандартных объектов, открытых в EMF в произвольный момент времени. Первый элемент таблицы зарезервирован для хранения стандартного объекта белой кисти, поэтому минимальное значение nHandles равно 1. Следующие два поля относятся к текстовому описанию, передаваемому при вызове CreateEnhMetaFile, которое всегда хранится в EMF в кодировке Unicode. Если строка описания была задана, она хранится после открытых полей заголовка. Поле nDescription содержит количество символов, а поле offDescription — относительное смещение строки от начала заголовка. Если строка описания не передавалась, оба поля равны нулю. Как говорилось выше, существуют по крайней мере три версии структуры ENHMETAHEADER; если поле offDescription отлично от нуля, по нему можно судить о различиях между версиями. Самая старая версия не содержит полей для внедрения данных OpenGL; в ней поле offDescription
906 Глава 16. Метафайлы равно 88. Последняя версия, используемая в Windows 2000, поддерживает OpenGL и поле szMicrometers; в ней поле offDescription равно 108. Поле nPalEntries задает количество элементов в накапливаемой палитре, используемой в метафайле. Цветовая таблица хранится не в заголовке, а в последней записи EMF, поскольку при построении EMF размер таблицы еще не известен GDI. Если палитра в EMF не используется, это поле равно нулю. Следующие два поля содержат информацию об эталонном устройстве. Поле szlDevice определяет размеры поверхности устройства в пикселах, а поле szMil- "limeters — в миллиметрах. Для получения информации о драйвере устройства GDI вызывает функцию GetDeviceCaps с индексами H0RZRES, VERTRES, H0RZSIZE и VERTSIZE. В метафайлах, записанных с использованием экранного контекста, типичные значения szlDevice равны 1024 х 768 или 1152 х 864. Поле szMillimeters всегда равно 320 х 240 (диагональ 400 мм = 15,75 дюйма, даже если у вас установлен 21-дюймовый монитор). Следующие три поля, cbPixelFormat, offPixelFormat и bOpenGL, обеспечивают поддержку OpenGL в формате метафайлов. Если контекст не является контекстом устройства OpenGL, все три поля равны нулю. Последнее поле szMicroMeters появилось только в структуре версии 5.0. В нем задается размер поверхности эталонного устройства в микрометрах, что для экрана равно 320 000 х 240 000. Непонятно, зачем понадобилось это поле, если размеры поверхности устройства в миллиметрах уже известны. Если вы знаете манипулятор EMF, для получения данных заголовка EMF можно воспользоваться функцией GetEnhMetaFileHeader. Из-за включения описания и данных о формате пикселов OpenGL заголовок является структурой переменного размера, поэтому функция GetEnhMetaFileHeader вызывается дважды; в первый раз она возвращает фактический размер, а во второй — запрашиваемые данные. Впрочем, если дополнения вас не интересуют, можно обойтись одним вызовом и получить фиксированные поля структуры. При непосредственном обращении к заголовку описание EMF всегда возвращается в виде строки в кодировке Unicode. Если вы не хотите возиться с Unicode в ANSI-программах, воспользуйтесь функцией GetEnhMetaFileDescription. Эта функция тоже вызывается дважды: сначала для получения количества символов, а потом для получения строки описания. Помните, что описание обычно состоит из названия компании и имени документа, разделенных нуль-символом, поэтому вся строка завершается двумя нуль-символами. При выводе произвольного расширенного метафайла важно сохранить те физические размеры, в которых он был создан. Следующая функция запрашивает информацию из заголовка EMF и вычисляет по ней размеры экранного прямоугольника для текущего контекста устройства. void GetEMFDimension(HDC hDC, HENHMETAFILE hEmf. int & width, int & height) { ENHMETAHEADER emfh[5]: GetEnhMetaFileHeader(hEmf. sizeof(emfh). emfh); // Размеры изображения в единицах 0,01 мм width - emfh[0].rclFrame.right - emfh[0].rclFrame.left; height = emfh[0].rclFrame.bottom - emfh[0].rclFrame.top:
Общие сведения о метафайлах 907 // Преобразовать к пикселам текущего устройства int t = GetDeviceCaps(hDC. HORZSIZE) * 100; width = ( width * GetDeviceCaps(hDC, HORZRES) + t/2 ) / t; t - GetDeviceCaps(hDC, VERTSIZE) * 100; height = ( height * GetDeviceCaps(hDC. VERTRES) + t/2 ) / t; RECT rect = { 0, 0. width, height }; // Преобразовать в логические координаты DPtoLPChDC. (POINT *) & rect. 2); width = abs(rect.right - rect.left); height = abs(rect.bottom - rect.top); } Функция GetEMFDimension получает манипулятор контекста устройства, в котором вы собираетесь воспроизвести EMF. Она запрашивает данные заголовка EMF функцией GetEnhMEtaFileHeader и вычисляет по ним размеры кадра. Ширина и высота кадра сначала преобразуются в систему координат устройства, а затем — в логическую систему координат. Результаты, полученные при вызове GetEMFDimension, позволяют воспроизвести EMF с исходными размерами или в заданном масштабе. Ниже приведена общая функция для вывода EMF в заданном масштабе (для исходных размеров оба масштабных коэффициента равны 100). B00L DisplayEMF(HDC hDC. HENHMETAFILE hEmf. int x. int y. int scalex, int scaley) { int width, height; GetEMFDimension(hDC. hEmf. width, height); RECT rect = { x. y. x + (width * scalex + 50)/100. у + (height * scaley + 50)/100 }; return rslt: } Передача расширенных метафайлов Чтобы передать данные другому приложению или сохранить их для последующего использования, EMF можно сохранить в файле на диске, загрузить из файла, скопировать в буфер, вставить из буфера или присоединить к исполняемому файлу в виде ресурса. Сохранение графики в файле EMF В одном из параметров функции CreateEnhMetaFile можно передать имя файла, в котором сохраняется построенный метафайл. Это позволяет легко сохранять графические операции GDI в EMF. У типичного окна имеется функция вывода, обеспечивающая вывод графики на экран. Чтобы поддержать сохранение EMF в файле, включите в программу код для вызова диалогового окна, в котором
908 Глава 16. Метафайлы пользователь вводит имя файла, задайте размеры прямоугольника кадра, создайте контекст устройства EMF, воспользуйтесь той же функцией вывода и закройте контекст устройства EMF. Следующий фрагмент показывает, как это делается. HDC QuerySaveEMFFile(const TCHAR * desp. const RECT * rcFrame. TCHAR szFileName[]) { KFileDialog fd; if ( fd.GetSaveFileName(NULL. "emf\ "Enhanced Metafiles") ) { if ( szFileName ) _tcscpy(szFileName, fd.m_TitleName); return CreateEnhMetaFileCNULL, fd.m_TitleName. rcFrame, description); } else return NULL; } int KMyView::OnCommand(int and. HWND hWnd) { if (cmd==IDM_FILE_SAVE) { hDC = QuerySaveEMFFileCEMF SampleVO". & rect. NULL); if ( hDC ) { OnDraw(hDC. NULL); // Функция вывода HENHMETAFILE hEmf - CloseEnhMetaFile(hDC); DeleteEnhMetaFile(hEmf); // Манипулятор не нужен } } } В этом фрагменте обрабатывается команда меню IDMFILESAVE. Обработчик вызывает функцию QuerySaveEMFFile, которая запрашивает у пользователя имя создаваемого файла и возвращает метафайловый контекст устройства. Затем вызывается метод OnDraw, выполняющий основной вывод в окне. Программа использует класс для работы с диалоговыми окнами, построенный в одной из предыдущих глав. Зная манипулятор расширенного метафайла, EMF можно сохранить на диске функцией CopyEnhMetaFile: HENHMETAFILE CopyEnhMetaFile(HENHMETAFILE hemfSrc. LPCTSTR IpszFile); Функция CopyEnhMetaFile копирует содержимое EMF в файл на диске, заданный параметром IpszFile, и возвращает манипулятор нового объекта EMF. Если вместо имени файла передается NULL, копия создается в памяти. После завершения работы с копией EMF объект GDI удаляется вызовом DeleteEnhMetaFile, но файл на диске остается до его удаления вызовом Del eteFi 1 е. Объект EMF создается на основе существующего EMF-файла простым вызовом GetEnhMetaFile (см. выше).
Общие сведения о метафайлах 909 Загрузка EMF из ресурса Если EMF присоединяется к исполняемому файлу в виде двоичного ресурса, то при помощи функций FindResource, LoadResource и LockResource можно получить указатель на изображение и создать по нему объект EMF вызовом функции SetEnhMetaFileBits. HENHMETAFILE SetEnhMetaFiIeBits(UINT cbBuffer. CONST BYTE * lpData): Функция SetEnhMetaFileBits получает два простых параметра — размер метафайла и указатель на метафайл, находящийся в памяти. Функции LoadBitmap и Loadlmage Win32 не позволяют загружать EMF из ресурсов, поэтому ниже приведена простая функция для решения этой задачи. // Загрузить EMF, присоединенный в виде ресурса, с типом данных RCDATA HENHMETAFILE LoadEMF(HMODULE hModule, LPCTSTR pName) { HRSRC hRsc = FindResource(hModule, pName. RT_RCDATA); if ( hRsc==NULL ) return NULL; HGLOBAL hResData = LoadResource(hModule. hRsc); LPVOID pEmf = LockResource(hResData); return SetEnhMetaFileBits(SizeofResource(hModule, hRsc). (const BYTE *) pEmf); } Ресурс EMF не принадлежит к числу стандартных типов ресурсов, однако для него можно указать тип ресурса RCDATA (идентификатор типа RT_RCDATA). Функция LoadEMF показывает, как загрузить ресурс EMF и преобразовать его в объект расширенного метафайла GDI. Вывод EMF в статическом элементе управления Объект EMF можно связать со статическим элементом управления, который затем автоматически выводится в диалоговом окне или странице свойств. У вас появляется возможность вывода векторной графики без применения элементов, прорисовка которых выполняется владельцем, и добавления специального кода графического вывода. По сравнению с растрами и значками, часто используемыми при выводе статических элементов управления и кнопок, EMF обеспечивает большую гибкость при масштабировании в разных разрешениях экрана. Чтобы объект EMF отображался в статическом элементе управления, включите в стиль последнего флаг SSENHMETAFILE или присвойте ему в редакторе ресурсов тип «Enhanced Metafile». В процессе инициализации родительского окна элемента управления отправьте ему сообщение STMSETIMAGE с манипулятором EMF. Следующий фрагмент показывает, как это делается в обработчике сообщений диалогового окна. switch (uMsg) { case WMJNITDIALOG: { hEmf = LoadEMF((HMODULE) GetWindowLong(hWnd, GWL HINSTANCE). MAKEINTRESOURCEdDR EMFD);
910 Глава 16. Метафайлы SendDlgltemMessageChWnd. IDCJMF. STM_SETIMAGE, IMAGEJNHMETAFILE, (LPARAM) hEmf): return TRUE; } case WMJICDESTROY: if ( hEmf ) DeleteEnhMetaFile(hEmf); return TRUE; } На рис. 16.3 показано диалоговое окно со статическим элементом управления, в котором выводится объект EMF, использованный в одном из примеров главы 15. Рис. 16.3. Использование ресурсов EMF в статических элементах Вывод EMF в статическом элементе управления открывает перед вами возможности, недоступные для обычных растров. При помощи EMF можно рисовать в статических элементах управления линии, кривые, фигуры и текст. Как видно из рисунка, благодаря EMF значительно упрощается применение прозрачности. Имеется и другое преимущество — в статическом элементе EMF автоматически масштабируется с правильными размерами при переходе из экранного режима с мелкими шрифтами в режим с крупными шрифтами, и наоборот. При выводе растров в статических элементах управления это вызывает массу проблем. Обмен данными через буфер На удивление простой и эффективный способ передачи графических данных в формате EMF основан на использовании буфера обмена (clipboard). Большинство графических приложений поддерживает старый формат метафайлов Windows; некоторые приложения поддерживают расширенные метафайлы. При копировании данных из графического приложения копия сохраняется в буфере в
Строение расширенных метафайлов 911 формате WMF или EMF. Операционная система автоматически преобразует данные WMF в формат EMF, поэтому клиентское приложение всегда должно запрашивать из буфера данные в формате EMF. Работать с буфером обмена просто и удобно. Ниже приведены две функции, предназначенные для копирования и вставки данных EMF. void CopyToClipboard(HWND hWnd. HENHMETAFILE hEmf) { if ( OpenClipboard(hWnd) ) { EmptyClipboardO; SetClipboardData(CF_ENHMETAFILE, hEmf); Closed ipboardO; } } HENHMETAFILE PasteFromClipboard(HWND hWnd) { HENHMETAFILE hEmf = NULL; if ( OpenClipboard(hWnd) ) { hEmf = (HENHMETAFILE) GetClipboardData(CFJNHMETAFILE); if ( hEmf ) hEmf - CopyEnhMetaFile(hEmf, NULL); Closed ipboardO; } return hEmf; } Функция CopyToClipboard копирует EMF в буфер. Она открывает буфер обмена функцией OpenClipboard, удаляет его текущее содержимое функцией Empty- Clipboard, копирует данные функцией SetClipboardData и освобождает буфер функцией Closed ipboard. Функция PasteFromClipboard имеет похожую структуру. Она получает манипулятор EMF из буфера при помощи функции GetClipboardData. Но поскольку владельцем этого манипулятора по-прежнему остается буфер, мы должны создать копию метафайла в памяти. Поддержка копирования и вставки данных EMF открывает много интересных возможностей. Вы можете вставлять в свои приложения диаграммы, построенные в Visio, векторные рисунки Word Art и другие объекты, а также копировать графические данные в буфер и вставлять их в документы Word, чтобы обойтись без сохранения экрана при фиксированном разрешении. Строение расширенных метафайлов В предыдущем разделе были описаны основные операции с метафайлами (создание, отображение, загрузка, сохранение и передача через буфер обмена). Для простых применений EMF этого вполне достаточно. Однако формат EMF игра-
912 Глава 16. Метафайлы ет в GDI очень важную роль, поэтому для того, чтобы досконально понимать метафайлы и в полной мере использовать их возможности, необходимо разобраться в их внутреннем устройстве. В этом разделе рассматривается формат расширенных метафайлов Windows, преобразование команд GDI в EMF, перечисление записей и динамическая модификация EMF. Записи EMF Расширенный метафайл представляет собой простую последовательность записей EMF с одинаковой общей структурой. Каждая запись EMF начинается с двух фиксированных 32-разрядных полей, за которыми следует переменная часть, определяемая типом записи. Структура EMR описывает фиксированные поля следующим образом: typedef struct tagEMR { DWORD iType; // Тип записи EMRJXX DWORD nSize; // Размер записи в байтах } EMR; Первое поле iType определяет тип записи EMF. Каждому типу записи присваивается символическое имя и числовое значение, определяемые в GDI макросами языка С. Ниже приведена небольшая часть этих макросов; полный список приведен в файле WINGDI.H. // Типы записей расширенного метафайла #define EMRJEADER 1 #define EMR_POLYBEZIER 2 #define EMR_P0LYG0N 3 #define EMR_RESERVED120 120 #define EMR_COLORMATCHTOTARGETW 121 #define EMR_CREATECOLORSPACEW 122 #define EMR_MIN 1 #define EMR_MAX 122 Анализ файла WINGDI.H показывает, что во всех новых версиях ОС появляются новые типы записей EMF. Используемые типы записей никогда не изменяются, а список лишь дополняется новыми типами. Например, в Windows NT 3 последним определенным типом записи (EMRMAX) является EMRPOLYTEXTOUTW, в Windows NT 4.0 список завершается типом EMRPIXELFORMAT (104), а в Windows 2000 он расширяется до EMRCREATEC0L0RSPACEW (122). Существуют даже недокументированные типы записей с именами вроде EMRRESERVED120; возможно, они используются спулером при печати. Все незарезервированные типы записей EMF документируются в MSDN, а в файле WINGDI.H для них определяются соответствующие структуры. Структуры отдельных типов можно рассматривать как производные от общей структуры EMR. Ниже приведен пример — структура EMRSETPIXELV для функции SetPixelV. typedef struct tagEMRSETPIXELV { EMR emr;
Строение расширенных метафайлов 913 POINTL ptlPixel: COLORREF crColor; } EMRSETPIXELV, *PEMRSETPIXELV; Запись EMF может содержать дополнения, не входящие в число общих полей, определенных в структуре записи. Например, вместе с записью EMF для функции вывода растров в качестве дополнений передается блок описания растра и массив пикселов. Каждое дополнение обычно описывается двумя полями — смещением данных от начала записи и длиной записи в байтах. Примером служит строка описания в структуре ENHMETAHEADER. Эта простая и универсальная структура значительно упрощает присоединение, чтение и обработку данных переменного размера. Второе поле структуры EMR содержит общий размер записи EMF в байтах, включая два фиксированных поля, остальные открытые поля и все дополнения. Записи EMF всегда выравниваются по границе двойного слова. Минимальный файл EMF состоит из двух записей — заголовка и завершающей записи. Заголовок ENHMETAHEADER был описан в предыдущем разделе; структура завершающей записи приведена ниже. typedef struct tagEMREOF { EMR emr; DWORD nPalEntries; // Количество элементов в палитре DWORD offPal Entries; // Смещение данных палитры DWORD nSizeLast; // Размер последней записи } EMREOF. *PEMR0EF; Запись EMREOF не только сообщает о завершении метафайла, но и содержит накопленные данные об элементах палитры, использованных в EMF. На первый взгляд может показаться странным, что дополнение с данными палитры вставляется после поля off Pal Entries и перед полем nSizeLast (но об этом речь пойдет ниже). Хотите посмотреть, как выглядит реальный метафайл? Ниже приведен двоичный дамп простого метафайла с единственной командой SetPixelV. 00 04 08 18 28 2с 30 34 38 ЗА ЗС 40 44 48 50 58 5С iType nSize rclBounds rclFrame dSignature nVersion nBytes nRecords nHandles sReversed nDescription offDescription nPalEntries szlDevice szlMillimeters cbPixelFormat offPixel Format 1 0x84 { 3, 5. { 0, 0, 1 EMF' 0x10000 OxAC 3 1 0 OxC 0x6C 0 { 0x500, { 0x140, 0 0 3. 5} 0x49BB, 0x2311 } 0x400 } OxFO }
914 Глава 16. Метафайлы 60 bOpenGL 0 64 szlMicrometers { 0х4Е200. 0хЗА980 6С Description L 'EMF Sample\0\0' // EMRSETPIXELV 84 iType 88 nSize 8C ptlPixel 94 crColor // EMREOF 98 iType 9C nSize АО nPalEntries A4 offPal Entries A8 nSizeLast OxF 0x14 { 3. 5 } RGB(0xFF. ( OxOE 0x14 0 0x10 0x14 ). 0) Когда метафайл сохраняется в файле на диске или присоединяется к программе в виде ресурса, он имеет в точности такую структуру — никаких скрытых или дополнительных данных. Классификация типов записей EMF Итак, EMF представляет собой записанную последовательность команд GDI, однако процесс преобразования команд GDI в записи EMF не документирован. В Windows 2000 библиотека GDI32.DLL экспортирует 543 функции. Даже если отбросить некоторые функции, предназначенные только для поддержки драйверов принтеров пользовательского режима, количество экспортируемых функций GDI все равно в 4 раза превышает количество типов записей EMF. Чтобы понять процесс отображения команд GDI в типы записей EMF, прежде всего следует учесть, что все записи EMF делятся на несколько основных категорий. В табл. 16.1 перечислены все 12 категорий. Таблица 16.1. Классификация типов записей EMF Категория Типы записей EMF Объекты GDI EMR_CREATEBRUSHINDIRECT, EMR_CREATEDIBPATTERNBRUSHPT, EMR_CREATEMONOBRUSH, EMR_CREATEPALETTE, EMR_CREATEPEN, EMRJXTCREATEFONTINDIRECTW, EMRJXTCREATEPEN, EMR_DELETEOBJECT, EMR_RESIZEPALETTE, EMRJETPALETTEENTRIES Контексты EMR_MODIFYWORLDTRANSFORM, EMR_REAPLIZEPALETTE, EMR_RESTOREDC, устройств EMR_SAVEDC, EMRJCALEVIEWPORTEXTEX, EMRJCALEWINDOWEXTEX, EMRJELECTOBJECT, EMRJELECTPALETTE, EMRJETARCDIRECTION, EMR_SETBKC0L0R, EMRJETBKMODE, EMR_SETBRUSHORGEX, EMRSETLAYOUT, EMR_SETMAPMODE, EMR_SETMAPPERFLAGS, EMRJETMITERLIMIT, EMR_SETPOLYFILLMODE, EMRJETR0P2, EMRJETSTRETCHBLTMODE, EMR_SETTEXTALIGN, EMRJETTEXTCOLOR, EMRJETVIEWPORTEXTEX, EMRJETVIEWPORTORGEX, EMRJETWINDOWEXTEX, EMRJETWINDOWORGEX, EMRJETWORLDTRANSFORM Отсечение EMRJXCLUDECLIPRECT, EMRJXTSELECTCLIPRGN, EMR_INTERSECTCLIPRECT, EMR OFFSETCLIPRGN, EMR SELECTCLIPPATH, EMRJETMETARGN
Строение расширенных метафайлов 915 Категория Типы записей EMF Траектории ICM Линии и кривые Замкнутые фигуры Растры Текст OpenGL Недокументированные Прочее EMR_ABORTPATH, EMRJEGINPATH, EMR_C LOSE FIGURE, EMRJNDPATH EMR_CREATECOLORSPACE, EMR_CREATECOLORSPACEW, EMR_COLORCORRECTPALETTE, EMR_COLORMATCHTOTARGETW, EMR_DELETECOLORSPACE, EMR_SETCOLORADJUSTMENT, EMR_SETCOLORSPACE, EMR_SETICMMODE, EMR_SETICMPROFILEA, EMRJETICMPROFILEW EMR_ANGLEARC, EMR_ARC, EMR_ARCT0, EMR_FLATTENPATH, EMR_LINETO, EMR_M0VET0EX, EMR_POLYBEZIER, EMR_P0LYBEZIER16, EMR_POLYBEZIERTO, EMR_P0LYBEZIERT016, EMR_POLYDRAW, EMR_P0LYDRAW16, EMR_POLYLINE, EMR_P0LYLINE16, EMR_P0LYLINET0, EMR_P0LYLINET016, EMR_POLYPOLYLINE, EMR_P0LYP0LYLINE16, EMR_STROKEPATH, EMR_WIDENPATH EMR_CH0RD, EMRJLLIPSE, EMR_FILLPATH, EMR_FILLRGN, EMR_FRAMERGN, EMR_GRADIENTFILL, EMR_INVERTRGN, EMR_PAINTRGN, EMR_PIE, EMR_P0LYG0N, EMR_P0LYG0N16, EMR_P0LYP0LYG0N, EMR_P0LYP0LYG0N16, EMR_RECTANGLE, EMR_ROUNDRECT, EMRJTROKEANDFILLPATH EMR_ALPHABLEND, EMR_BITBLT, EMRJXTFLOODFILL, EMR_MASKBLT, EMR_PLGBLT, EMR_SETDIBITSTODEVICE, EMRJETPIXELV, EMRJTRETCHBLT, EMRJTRETCHDIBITS, EMRJRANSPARENTBLT EMR EXTTEXTOUTA, EMRJXTTEXTOUTW, EMR_POLYTEXTOUTA, EMR_POLYTEXTOUTW EMR_GLSBOUNDEDRECORD, EMR_GLSRECORD, EMR_PIXELFORMAT EMR_RESERVED_105, EMR_RESERVED_106, EMR_RESERVED_107, EMR_RESERVED_108, EMR_RESERVED_109, EMR_RESERVED_110, EMR_RESERVED_119, EMR_RESERVED_120 EMR EOF, EMR GDICOMMENT, EMR HEADER Сравнивая приведенные в таблице типы записей с функциями Win32 API, можно понять, о чем следует помнить и какие решения следует принимать при разработке EMF. Некоторые из моих личных заметок приведены ниже. О В формате EMF хранятся только постоянные данные. В нем нет переменных выражений, прямых ссылок на манипуляторы GDI или каких-либо зависимостей от результатов вызова функций. О Все вычисления и запросы обрабатываются в процессе построения EMF, а в EMF сохраняются только результаты. По этой причине в EMF не предусмотрены записи для информационных функций GDI — таких, как GetDeviceCaps, GetBkMode, GetBkColor и т. д. Построение EMF не сводится к простой записи потока команд; это комбинация записей с вычислениями. Если ваш графический код содержит условные вычисления или зависит от значений, возвращаемых при вызове функций, состояние эталонного контекста устройства фиксируется на момент построения. Нельзя гарантировать, что воспроизведение записанного EMF приведет к тому же результату, что и исходный код. О Только кисти, перья, шрифты, палитры и цветовые пространства (для ICM) кодируются в виде объектов GDI (то есть в EMF для них создаются записи
916 Глава 16. Метафайлы создания, выбора и удаления объектов). Траектории также неявно интерпретируются как объекты GDI, однако в EMF не предусмотрена запись для получения данных траектории функцией GetPath, поскольку это требует использования переменных. «Тяжеловесные» объекты GDI — аппаратно-зависимые растры (DDB), DIB-секции, регионы, совместимые контексты устройств и расширенные метафайлы — не сохраняются в EMF в виде объектов GDI. Например, в EMF не существует записи для создания DDB-растров или вложенных метафайлов. Как будет показано ниже, полные данные DDB, DIB- секции или региона передаются в виде дополнений к записям тех графических функций, в которых они используются. Вызовы функций с участием совместимых контекстов устройств или других контекстов, кроме приемного, просто выполняются без записи в EMF. О Поддерживаемые модулем управления окнами (USER32.DLL), графические функции не сохраняются в EMF непосредственно. В частности, в табл. 16.1 не встречаются записи для таких функций, как DrawEdge, DrawFrameControl, DrawCaption, Drawlcon, DrawText и т. д. Некоторые из этих функций пользуются услугами GDI; соответствующие вызовы GDI сохраняются в EMF. Другие задействуют системные функции, работающие в обход пользовательской части GDI, где происходит запись EMF. Скажем, в модуле USER поддерживается системная функция NtUserDrawCaption. Графические вызовы, обходящие пользовательскую часть GDI, в EMF не сохраняются. О Поддержка OpenGL в EMF представлена специальными данными заголовка и тремя специальными типами записей EMF. DirectX в EMF не поддерживается. О Команды печати в EMF не поддерживаются, хотя GDI и спулер могут сохранить задание печати в EMF-файле спулера и воспроизвести его позднее при помощи драйвера устройства. Расшифровка записей EMF Зная манипулятор EMF, можно вызвать функцию GDI GetEnhMetaFileBits и получить все записи EMF для последующей обработки. Функция GetEnhMetaFileBits определяется следующим образом: UINT GetEnhMetaFileBits(HENUMMETAFILE hEmf. UINT cbBuffer, LPBYTE IpbBuffer); Сначала приложение получает размер EMF, вызывая GetEnhMetaFileBits с последним параметром, равным NULL, а затем получает данные EMF следующим вызовом. Приведенный ниже фрагмент иллюстрирует методику перебора всех записей EMF. int DumpEMF(HENHMETAFILE hEmf. ofstream & stream) { int size - GetEnhMetaFileBits(hEmf. 0. NULL); if ( size<=0 ) return 0; BYTE * pBuffer = new BYTE[size]; if ( pBuffer==NULL )
Строение расширенных метафайлов 917 return 0; GetEnhMetaFileBits(hEmf, size, pBuffer); const EMR * emr = (const EMR *) pBuffer; TCHAR mess[MAX_PATH]; int recno = 0; // Перебор всех записей EMF while ( (emr->iType>=EMR_MIN) && (emr->iType<=EMR_MAX) ) { recno ++; wsprintf(mess, "*3d: EMRJ03d U4d bytes)\n". recno, emr->iType. emr->nSize); stream « mess; if ( emr->iType— EMRJOF ) break; emr = (const EMR *) ( ( const char * ) emr + emr->nSize ); } delete [] pBuffer; return recno; } Функция DumpEMF перебирает все записи EMF и выводит номер, тип и размер каждой записи в файловый поток C++. Эта функция всего лишь показывает, что перебор записей помогает разобраться во внутренней структуре EMF. На компакт-диске имеется мощное средство для анализа EMF, реализованное в классе KEmfDC. Этот класс позволяет вывести содержимое EMF в виде иерархического дерева (TreeView) с расшифровкой записей EMF на команды и параметры GDI. На рис. 16.4 слева приведена расшифровка команд EMF, а справа — результат воспроизведения EMF. ъЖ>' *, nBytes 427460 |*]! nRecords 47 nHandles 3 sReserved 0 nDescription 17 off Description 108 nPalE nines 0 szlDevice {1152,864} szlMillimeters { 320,240} cbPixelFormat 0 offPixelFormat 0 bOpenGL 0 szMicroMeters {320000,240000} 2 h0b|[1 ]=CreateFont(-48A0,0,400,0,0,0,0,4,0,0,1 • 3 SelectOb|ect(hDC, h0b|[1 ]),12 bytes 4 StretchDIBits(hDC, 50,50,554,278,0,0,554,278 5 SetBkModefhDC, OPAQUE)/! 2 bytes 6 SetBkColorfhDC, RGB(0xFF,0xFF,0xFF)),12 byte • 7 SetTextColorfhDC, RGB(0,0,0)),12 bytes mjOl-rfil jT Рис. 16.4. Расшифровка и просмотр EMF в программе
918 Глава 16. Метафайлы На рисунке воспроизведен метафайл с рельефным текстом, созданный одной из программ главы 15. Программа просмотра и расшифровки EMF входит в один из примеров этой главы. Откройте EMF-файл на диске или вставьте EMF из буфера обмена — программа расшифрует его записи и воспроизведет их. В левой части рисунка видна часть заголовка EMF и пять расшифрованных команд GDI. Как показывает заголовок, метафайл состоит из 47 записей, имеет длину 427 460 байт и записан для экрана 1152 х 864 пикселов. Среди записей EMF мы видим функции создания логического шрифта, выбора его в контексте устройства, вывода растров и настройки цвета/режима заполнения фона для последующего вывода. В правой части окна изображен результат воспроизведения метафайла в масштабе 1:1. Простые объекты GDI в EMF Программа просмотра и расшифровки EMF (см. рис. 16.4) является ценным инструментом для анализа метафайлов и диагностики проблем, возникающих при работе с ними. Давайте рассмотрим структуру EMF подробнее. Только четыре типа объектов GDI — логическое перо, логическая кисть, логический шрифт и логическая палитра — сохраняются в EMF именно как объекты GDI. Функции создания объектов этих типов имеют похожее представление в записях EMR: список параметров начинается с индекса в таблице манипуляторов EMF, за которым следует логическое определение объекта. В качестве примера приведу структуру записи EMF для функции CreatePen: typedef struct tagEMRCREATEPEN { EMR emr; // Стандартный заголовок DWORD ihPen: // Индекс в таблице манипуляторов LOGPEN lopn; // Логическое определение } EMRCREATEPEN; При воспроизведении EMF GDI создает небольшую таблицу манипуляторов, число элементов в которой определяется полем nHandles записи заголовка EMF. Индекс в записи EMRCREATEPEN относится именно к этой таблице манипуляторов EMF, а не к скрытой системной таблице объектов GDI. Первый элемент таблицы манипуляторов EMF резервируется. Таблица описывается структурой HANDLETABLE. typedef struct tagHANDLETABLE { HGDIOBJ objecthandleCl]: // Переменный размер, определяется nHandles } HANDLETABLE: Стандартные объекты GDI не хранятся в таблице манипуляторов EMF. Для ссылки на стандартный объект его идентификатор указывается с обратным знаком. В настоящее время документируются стандартные объекты GDI с GetStock- Object(WHITE_BRUSH) до GetStockObject(DC_PEN). В GDI32.H WHITEJRUSH определяется со значением 0, a DC_PEN — со значением 19, поэтому их индексы лежат в интервале от 0 до -19 соответственно. Это также объясняет, почему индекс 0 в таблице манипуляторов EMF зарезервирован. В EMF записи часто ссылаются на логические перья, кисти, шрифты или палитры. Из рис. 16.4 видно, что вторая запись EMF создает логический шрифт и заносит его в элемент 1 таблицы манипуляторов EMF; третья запись EMF выбирает объект, ссылка на который хранится в элементе 1, в контексте устройства.
Строение расширенных метафайлов 919 Применение простой таблицы манипуляторов EMF изящно решает проблему временной, недетерминированной природы манипуляторов объектов GDI. Впрочем, преобразование манипуляторов GDI в индексы — не такая простая задача, как кажется на первый взгляд. Во-первых, GDI не может просто зарегистрировать функцию создания объекта GDI, поскольку манипулятор может вообще не использоваться в эталонном контексте устройства. Запись создания объекта сохраняется в EMF лишь при первом фактическом использовании манипулятора. Это означает, что при каждой ссылке на манипулятор пера, кисти, палитры или шрифта GDI приходится просматривать таблицу манипуляторов EMF и проверять, был ли ранее зарегистрирован данный манипулятор. Если манипулятор задействуется впервые, GDI при помощи функции GetObject получает определение, по которому создавался манипулятор, и генерирует запись создания объекта; в противном случае берется индекс из таблицы. Функция DeleteObject тоже сохраняется в EMF с типом EMRDELETEOBJECT. Конечно, это происходит лишь в том случае, если манипулятор реально использовался. После воспроизведения EMF в таблице манипуляторов EMF могут остаться неудаленные элементы. GDI гарантирует, что таблица будет должным образом освобождена; это предотвращает утечку объектов GDI при воспроизведении EMF, обусловленную ошибками при записи. Приложение может проверить количество манипуляторов в таблице и узнать, какие манипуляторы остались в ней после воспроизведения. Это тоже помогает бороться с утечками ресурсов. Растры в EMF GDI поддерживает три типа растров: аппаратно-зависимые растры (DDB), аппа- ратно-независимые растры (DIB) и DIB-секции. DIB-растры не являются объектами GDI в том смысле, что GDI не управляет хранением их данных, однако DDB и DIB-секции принадлежат к числу объектов GDI. Тем не менее вы не встретите в EMF записей создания объектов DDB и DIB-секций. DDB по своей природе зависит от конкретного устройства и даже от его текущей конфигурации. Конечно, DDB нельзя напрямую сохранить в расширенном метафайле, который должен обеспечивать аппаратно-независимое представление графических данных. Другая проблема с DDB-растрами заключается в том, что они не могут непосредственно выводиться в контексте устройства; для работы с ними приходится привлекать совместимый контекст устройства. Возможно, именно из-за этого разработчики GDI не стали интерпретировать DDB и DIB- секции в расширенных метафайлах как объекты GDI. Вместо этого DDB и DIB- секции всегда преобразуются в неупакованные DIB-растры. В GDI неупакованный DIB-растр представлен двумя указателями — на структуру BITMAP INFO и на массив пикселов. При отсутствии манипулятора сослаться на растр в EMF невозможно; было решено, что данные растров следует передавать вместе с теми командами, в которых они используются. Давайте посмотрим, как функция BitBlt GDI кодируется в записи EMF EMRBITBLT. typedef struct tabEMRBITBLT { EMR emr;
920 Глава 16. Метафайлы RECTL LONG LONG LONG LONG DWORD LONG LONG XFORM COLORREF DWORD DWORD DWORD DWORD DWORD EMRBITBLT rclBounds; xDest; yDest; cxDest; , cyDest; dwRop; xSrc; ySrc; xformSrc; crBkColorSi iUsageSrc; offBmiSrc; cbBmiSrc; offBitsSrc cbBitsSrc; // Задается в единицах устройства // Преобразование исходного контекста устройства // Фоновый цвет исходного контекста устройства в RGB // Формат цветовой таблицы растра // (DIB_RGB_COLORS) // Смещение структуры BITMAPINFO // Размер структуры BITMAPINFO // Смещение графических данных растра // Размер графических данных растра Вспомните, что функция BitBlt GDI получает девять параметров: манипулятор приемного контекста устройства, четыре параметра приемного многоугольника, манипулятор исходного контекста устройства, базовую точку в исходном контексте и растровую операцию. В структуре EMRBITBLT приемный контекст устройства не нужен, поскольку он определяется косвенно; приемный прямоугольник представлен четверкой {xDest, yDest, cxDest, cyDest}, базовая точка источника представлена полями {xSrc, ySrc}, а растровая операция определяется полем dwRop. Остается разобраться с манипулятором исходного контекста (и восемью полями структуры EMRBITBLT). Источником при вызове BitBlt может быть совместимый контекст устройства с выбранным DDB-растром или DIB-секцией или же экранный контекст устройства. Маловероятно, чтобы им оказался контекст устройства принтера, поскольку контексты принтеров обычно недоступны для чтения. Совместимый контекст устройства можно представить растром, который в нем содержится, а экранный контекст устройства легко преобразуется в растр, состоящий из его текущих пикселов. В любом случае источник преобразуется в DIB-растр, описываемый последними полями EMRBITBLT. Поле iUsage обеспечивает интерпретацию цветовой таблицы, поля (off Bmi Src, cbBmiSrc) ссылаются на структуру BITMAPINFO, а поля (offBitsSrc, cbBitsSrc) идентифицируют массив пикселов. На результаты вызова BitBlt также может влиять состояние исходного контекста устройства. В поле xformSrc хранятся данные отображений из логических координат в координаты устройства. Параметр cbBkColorSrc определяет фоновый цвет исходного контекста устройства, который может использоваться для вывода цветных растров в монохромных контекстах устройств. Поле rcl Bounds содержит ограничивающий прямоугольник в системе координат эталонного устройства. Конечно, этот прямоугольник можно вычислить во время воспроизведения, но хранение его в EMRBITBLT несколько повышает быстродействие. Все растры в EMF представлены по одному образцу: флаг формата цветовой таблицы, дополнение с данными BITMAPINFO и дополнение с массивом пикселов. Недостаток подобного представления заключается в том, что растр сохраняется заново при каждом использовании. Если один и тот же растр применяется 100 раз,
Строение расширенных метафайлов 921 он будет 100 раз сохранен в EMF. Возможно, для небольших или однократно используемых растров это еще терпимо, но в современных графических пакетах, часто использующих растровые заливки, возникают серьезные проблемы. Как показал эксперимент для программы, при повторном выводе растра в EMF включается его полная копия. Таким образом, размер EMF возрастает пропорционально количеству применений растра. Похоже, при выводе горизонтальной полосы растра GDI усекает внедренные данные до меньших размеров, но в более сложных ситуациях в EMF включается весь растр. Поскольку с распространением Интернета и цифровых фотоаппаратов все чаще требуются растры с повышенной цветовой глубиной, а многие драйверы принтеров используют спулинг в формате EMF, при работе с растровыми изображениями в EMF прикладные программисты все чаще сталкиваются с проблемами быстродействия. Программа расшифровки и просмотра EMF, показанная на рис. 16.4, выводит размер каждой записи и размеры каждого растра, что упрощает диагностику проблем такого рода. Интересно другое: как при текущей структуре EMF решить эту проблему с минимальными изменениями в GDI и нельзя ли приложению каким-либо образом ограничить размеры EMF? Мы знаем, что дополнения (например, растры в записи EMRBITBLT) всегда хранятся после открытых полей, однако для ссылок на них используются 32-разрядные смещения. Если бы смещения могли быть отрицательными или выходить за границы текущей записи EMF, разные записи EMF могли бы совместно использовать одну копию растра. Также можно включить в EMF специальную запись создания растрового объекта, чтобы растр сохранялся в EMF только один раз и в дальнейшем на него можно было ссылаться по индексу, как на перо или кисть. Регионы в EMF Представление регионов в EMF имеет много общего с представлением растров. С регионами не ассоциируются манипуляторы; создание регионов и операции с ними просто выполняются без создания записей в EMF. При использовании региона в контексте устройства, в котором осуществляется запись, данные региона полностью включаются в запись EMF. Рассмотрим пример — запись EMREXTSELECTCLIPRGN, соответствующую функциям SelectClipRgn и ExtSel ectCl i pRgn. typedef struct tagEMREXTSELECTCLIPRGN { EMR emr; DWORD cbRgnData; // Размер данных региона в байтах DWORD i Mode; BYTE RgnData[l]: } EMREXTSELECTCLIPRGN; Как видно из определения EMREXTSELECTCLIPRGN, данные региона включаются в запись даже без стандартного поля смещения. Массив переменного размера RgnData в действительности содержит структуру RGNDATA, возвращаемую функцией GetRegionData.
922 Глава 16. Метафайлы Как и в случае с растрами, при многократном использовании одного региона в EMF сохраняется несколько копий его данных. Если ваше приложение работает со сложными регионами, будьте внимательны. Траектории в EMF Операции с траекториями в EMF достаточно близки к аналогичным функциям GDI. В EMF предусмотрены типы записей для функций BeginPath, CloseFigure, EndPath и функций прорисовки траекторий. Таким образом, можно говорить о неявной реализации траектории как объекта GDI. Функции SaveDC и RestoreDC тоже поддерживаются в EMF, что позволяет использовать данные одной траектории несколько раз. Поддержка функции SelectClipPath в записях EMF тоже сокращает необходимость во внедрении данных траекторий. Например, если приложение хочет использовать эллиптический регион отсечения, то вместо функций CreateEllip- ticRgn и SelectRegion оно может воспользоваться функциями BeginPath, Ellipse, EndPath и SelectClipPath и избежать включения данных региона в EMF. Если вы используете функцию GetPath для получения данных траектории, вызовите PolyDraw для ее прорисовки; данные траектории внедряются в запись EMRPOLYDRAW. Палитры в EMF В EMF предусмотрены типы записей для основных операций с палитрой в GDI (функции CreatePalette, SelectPalette, ResizePalette и RealizePalette). Логическая палитра интерпретируется в EMF как объект GDI. Однако GDI несколько иначе интерпретирует вызовы SelectPalette в EMF. Напомню, что при вызове SelectPalette передаются три параметра: манипулятор контекста устройства, манипулятор палитры и флаг. Флаг является признаком форсированного использования фоновой палитры. Если окно, в котором осуществляется вывод, является активным, а параметр bForceBackground функции SelectPalette равен FALSE, палитра позднее будет реализована в качестве основной. Все различия между основной и фоновой палитрами состоят в том, что только основная палитра может удалять нестатические цвета из системной палитры, чтобы реализовать больше однородных цветов для повышения точности цветопередачи; фоновая палитра может лишь занимать свободные позиции палитры или подбирать подходящие цвета среди уже существующих. В записи EMF для функции SelectPalette (тип EMRSELECTPALETTE) параметр bForceBackground не фиксируется. При воспроизведении EMF логическая палитра всегда выбирается в качестве фоновой. Смысл такого решения заключается в том, что воспроизведение EMF не должно приводить к изменению текущих цветов экрана, что привело бы к раздражающему мерцанию и искажению цветов. Управление основной палитрой не может осуществляться на уровне EMF, оно относится к более высокому уровню обработки сообщений (то есть выполняется в обработчиках WMPAINT и WMPALETTECHANGED). Если приложение действительно хочет согласовать текущую системную палитру с цветами EMF (то есть реализовать палитру EMF в качестве основной),
Строение расширенных метафайлов 923 к его услугам полная цветовая таблица, которую GDI сохраняет в последней записи EMRE0F. В процессе записи EMF GDI накапливает элементы палитры и заносит их в «палитру метафайла», входящую в запись EMRE0F. Приложение может получить палитру метафайла при помощи функции GetEnhMetaFilePaletteEntries. UINT GetEnhMetaFilePaletteEntries(HENHMETAFILE hemf, UINT cEntries, LPPALETTEENTRY lppe); А теперь подумайте, как эта функция реализуется в GDI? Конечно, по манипулятору EMF GDI может найти запись EMRE0F, но как именно это сделать при отсутствии прямых ссылок? Перебор всех записей EMF займет слишком много времени, если для этого придется загружать EMF в память с диска. Разгадка кроется в nSizeLast, последнем поле записи EMRE0F. Вспомните: поле nSizeLast расположено после цветовой таблицы. По общему размеру EMF, хранящемуся в заголовке EMF, GDI может определить адрес поля nSizeLast. В этом поле хранится размер записи EMRE0F, по которому легко определяется начало записи EMRE0F. Операции с палитрой подробно рассматриваются в главе 13. Следующий фрагмент показывает, как создать логическую палитру по цветовой таблице EMF. HPALETTE GetEMFPaletteCHENHMETAFILE hEmf. HDC hDC) { // Запросить количество элементов int no « GetEnhMetaFi1ePaletteEntries(hEmf, 0, NULL); if ( no<=0 ) return NULL; // Выделение памяти LOGPALETTE * pLogPalette - (LOGPALETTE *) new BYTE[sizeof(LOGPALETTE) + (no-1) * sizeof(PALETTEENTRY)]; pLogPalette->palVersion = 0x300; pLogPalette->palNumEntries = no; // Получение данных GetEnhMetaFilePaletteEntries(hEmf, no, pLogPalette->palPal Entry); HPALETTE hPal = CreatePalette(pLogPalette); delete [] (BYTE *) pLogPalette; return hPal; } Приложение может реализовать логическую палитру, возвращенную функцией GetEMFPalette, в качестве основной и организовать обработку сообщений палитры. И последнее, что следует сказать о палитрах и EMF: перед воспроизведением EMF функцией PlayEnhMetaFile GDI сбрасывает контекст устройства в состояние по умолчанию и восстанавливает его позднее. Следовательно, EMF не сможет воспользоваться содержимым логической палитры, выбранной в контексте устройства перед воспроизведением.
924 Глава 16. Метафайлы Системы координат в EMF В воспроизведении EMF участвуют два контекста устройств: эталонный и приемный. Эталонный контекст устройства используется при построении EMF, а в приемном контексте EMF воспроизводится функцией PlayEnhMetaFile. Эталонный контекст устройства не имеет внешних проявлений, но именно к нему относятся координаты, хранящиеся в записях EMF. Каждый контекст устройства обладает логической системой координат и системой координат устройства, поэтому в воспроизведении EMF участвуют по меньшей мере четыре системы координат: О логическая система координат эталонного контекста; О система координат устройства эталонного контекста; О логическая система координат приемного контекста; О система координат устройства приемного контекста. Я говорю «по меньшей мере четыре», поскольку ничто не гарантирует, что в эталонном контексте используется всего одна логическая система координат. EMF полностью поддерживает настройку и модификацию логических систем координат функциями SetWi ndowExtEx, SetViewportExtEx, SetWorldTransform и т. д. Возникает непростой вопрос: допустим, в EMF записывается команда вывода линии длиной 1 дюйм в режиме отображения MMLOENGLISH или MMHIENGLISH. Какую длину будет иметь линия при воспроизведении EMF функцией PlayEnhMetaFile? Еще более сложный вопрос: если мы выбираем регион отсечения, заданный в системе координат устройства, как он будет интерпретироваться при воспроизведении EMF? При воспроизведении EMF GDI может интерпретировать записи EMF, изменяющие системы координат, как отображение логической системы координат эталонного контекста в систему координат устройства. Пусть это отображение определяется матрицей преобразования xformSrc. Все точки логической системы координат приемного устройства также отображаются в систему координат устройства. Пусть матрица этого преобразования называется xformDst. Таким образом, отображение координатных пространств при воспроизведении EMF определяется связью между системой координат устройства эталонного контекста и логической системой координат приемного контекста. Назовем соответствующую матрицу преобразования xformPlay. На рис. 16.5 изображены два контекста устройств, четыре координатных пространства и три преобразования, участвующие в воспроизведении EMF. Матрица преобразования xformPlay вычисляется по прямоугольнику кадра, хранящемуся в заголовке EMF (rclFrame), и прямоугольнику, переданному при вызове PlayEnhMetaFile (IpRect). Остается лишь преобразовать rcl Frame из единиц 0,01 мм в систему координат устройства эталонного контекста. Следующий фрагмент показывает, как вычисляется матрица преобразования.
Строение расширенных метафайлов 925 Логическая система координат эталонного контекста Система координат устройства эталонного контекста Логическая система контекста координат приемного контекста Система координат устройства приемного ,."*г „,-"*' .у ..** S* rcl Frame в заголовке EMF ipRect, переданный при вызове PlayEnhMetaFile Рис. 16.5. Системы координат и преобразования, участвующие в воспроизведении EMF // Преобразование из координат устройства эталонного контекста // в логические координы приемного контекста BOOL GetPlayTransformation(HENHMETAFILE hEmf. const RECT * rcPic, XFORM & xformPlay) { ENHMETAHEADER emfh; if ( GetEnhMetaFileHeader(hEmf, sizeof(emfh), return FALSE; & emfh)<=0 ) try // Единицы 0,01 мм -> 1 мм -> проценты -> пикселы устройства double sxO = emfh.rclFrame.left / 100.0 / emfh.szlMillimeters.cx * emfh.szlDevice.ex; double syO = emfh.rclFrame.top / 100.0 / emfh.szlMillimeters.cy * emfh.szlDevice.cy; double sxl = emfh.rclFrame.right / 100.0 / emfh.szlMillimeters.cx * emfh.szlDevice.ex; double syl = emfh.rclFrame.bottom / 100.0 / emfh.szlMillimeters.cy * emfh.szlDevice.cy; // Отношения размеров источника к приемнику double rx = (rcPic->right - rcPic->left) / ( sxl - sxO ); double ry = (rcPic->bottom - rcPic->top) / ( syl - syO ); у * eM21 + eDx * eM22 + eDy // x' - x * eMll // у' = x * eM12 ■ j ...__ xformPlay.eMll = (float) rx; xformPlay.eM21 - (float) 0; xformPlay.eDx = (float) (- sxO rx rcPic->left); xformPlay.eM12 = (float) 0; xformPlay.eM22 = (float) ry: xformPlay.eDy = (float) (- syO * ry + rcPic->top);
926 Глава 16. Метафайлы } catch (...) { return FALSE; } return TRUE; } Обратите внимание: при воспроизведении вместо четырех систем координат мы работаем с тремя матрицами преобразований. Матрица xformDst определяется приложением в приемном контексте устройства перед воспроизведением EMF. Матрица xformSrc изначально определяет тождественное преобразование и динамически изменяется при воспроизведении записей EMF, связанных с изменением системы координат. Связующим звеном между этими матрицами является матрица преобразования xformPlay, которая определяется в заголовке EMF, передаваемого функции PlayEnhMetaFile. Как правило, вам не приходится думать о матрице преобразования приемного контекста, поскольку при выводе на приемной поверхности GDI обычно работает с логическими координатами. Все логические координаты в EMF перед выводом на приемной поверхности должны пройти через матрицы преобразований xformSrc и xformPlay. Некоторые координаты EMF (например, координаты в регионах отсечения) относятся к системе координат устройства эталонного контекста. Такие координаты необходимо преобразовать в систему координат устройства приемного контекста. GDI может выполнить это преобразование последовательным применением матриц xformPlay и xformDst. Как говорилось выше, все данные регионов в EMF хранятся в структуре RGNDATA, преобразуемой в объект региона GDI функцией ExtCreateRegion. Функция ExtCreateRegion удобна тем, что при вызове ей можно передать матрицу преобразования, применяемую ко всем координатам, а для объединения двух матриц преобразований можно воспользоваться функцией CombineTransform. Из-за операций масштабирования и отображения, используемых при работе с EMF, разрешение логической системы координат эталонного устройства оказывает значительное влияние на качество графики. Если метафайл строился в режиме отображения ММ_ТЕХТ на экране с разрешением 96 dpi, все координаты будут представляться целыми числами в этой системе координат и в этом разрешении. При воспроизведении EMF с увеличением и на устройствах высокого разрешения координаты масштабируются, что может нарушить выравнивание текста или создать неровности в контурах многоугольников и траекторий. Команды вывода в EMF EMF поддерживает широкий ассортимент графических команд GDI. Из 122 известных типов записей EMF 47 соответствуют графическим функциям GDI. Существует еще несколько типов записей, предназначенных для записи команд OpenGL, а также могут существовать недокументированные графические команды.
Строение расширенных метафайлов 927 Обычно все координаты в EMF хранятся в виде 32-разрядных значений. Впрочем, в восьми типах записей EMF основные данные хранятся в 16-разрядном формате, например, функция PolyPolygon представлена двумя типами записей EMF — 32-разрядной версией EMRP0LYP0LYG0N и 16-разрядной версией EMR- P0LYP0LYG0N16. Эти две версии различаются только форматом массива точек. Хотя 16-разрядные версии почти вдвое сокращают затраты памяти, если значения логических координат ограничиваются 16 битами, неизвестно, в каких именно системах они используется. Даже Windows 98 при спулинге в формате EMF генерирует записи EMRP0LYP0LYG0N вместо EMRP0LYP0LYG0N16. Для элементарных графических функций (таких, как LineTo и Rectangle) в записях EMF сохраняются только исходные координаты. Для более сложных функций GDI сохраняет в записях EMF ограничивающий прямоугольник в системе координат устройства. В частности, поле ограничивающего прямоугольника включается в записи EMRPOLYLINE, EMRP0LYG0N и EMRSTRETCHBLT. Ограничивающий прямоугольник иногда бывает очень полезен — например, по нему можно исключить из воспроизведения записи EMF, отсекаемые или выходящие за границы текущей области вывода. В частности, эта возможность может использоваться GDI при поэтапной передаче EMF-файла спулера, когда драйвер принтера при каждой пересылке принимает всего одну горизонтальную полосу, a GDI повышает эффективность пересылки за счет передачи только тех команд, которые соприкасаются с прямоугольником текущей полосы. Базовые функции вывода отдельных пикселов, SetPixel и SetPixelV, представлены одним типом записи EMF EMRSETPIXELV. Конечно, это объясняется тем, что зависимость от возвращаемого значения функции приходится исключать на стадии построения EMF. В формате EMF практически полностью поддерживаются функции GDI для вывода линий и кривых, разве что функция MoveToEx не возвращает предыдущей позиции курсора, а функция LineDDA не поддерживается. Впрочем, LineDDA не обеспечивает самостоятельного вывода, поскольку она всего лишь разбивает линию на последовательность координат пикселов в логической системе координат. Весь вывод осуществляется функциями косвенного вызова, предоставленными вызывающей стороной; эти команды будут сохранены в файле. В полной мере поддерживаются и функции GDI, предназначенные для заполнения замкнутых фигур. Например, функции Chord, Ellipse, Polygon и даже PolyPolygon представлены в EMF соответствующими типами записей. Несколько странно выглядит тот факт, что для функций, определяющих геометрическую фигуру по ограничивающему прямоугольнику (например, Rectangle и Ellipse), GDI при записи EMF исключает правую нижнюю сторону. Например, прямоугольник {0,0,50,50} сохраняется в виде {0,0,49,49}. Таким образом, прямоугольники, хранящиеся в EMF, интерпретируются с включением всех сторон. Аналогичная интерпретация используется GDI при выводе в расширенном графическом режиме. При обычном выводе в масштабе 1:1 GDI точно передает исходную форму таких записей EMF, но при увеличении могут возникнуть искажения. Например, два прямоугольника Rectangle(0,0,50,50) и Rectangle(50,0,100,50) должны соприкасаться всегда, даже при увеличении. Но поскольку в EMF они представлены в виде {0,0,49,49} и {50,50,99,49}, при увеличении между ними возникает крошечный промежуток.
928 Глава 16. Метафайлы Три функции заполнения замкнутых фигур — FillRect, FrameRect и InvertRect — не принадлежат к числу функций GDI. Они реализуются модулем управления окнами USER32.DLL, который выполняет вывод при помощи функций GDI. Эти вызовы GDI — создание и выбор кисти, простой блиттинг — и будут сохранены bEMF. Функции прорисовки регионов FillRgn, FrameRgn, InvertRgn и PaintRgn поддерживаются полностью. Объект региона GDI преобразуется в структуру данных региона и присоединяется к этим графическим командам в виде дополнения. Функции построения траекторий, в отличие от функций построения регионов, поддерживаются полностью. Также поддерживаются функции прорисовки траекторий Fill Path, StrokeAndFi 11 Path и StrokePath. Поскольку эти функции ссылаются на неявный объект траектории в контексте устройства, в их записях EMF сохраняется простейший ограничивающий прямоугольник. Для вычисления реального ограничивающего прямоугольника GDI пришлось бы вызывать GetPath в процессе построения EMF. В EMF поддерживаются все функции вывода растров, от простейшей BitBlt до AlphaBlend, кроме PatBlt. Функция PatBlt объединяется с более общей формой BitBlt, и для них используется одна и та же запись EMRBITBLT. Из-за этого объединения PatBlt представляется 100 байтами. Если бы существовала отдельная запись EMRPATBLT, она бы состояла из 66 байт. Текст в EMF Оставшиеся четыре типа записей EMF предназначены для вывода текста. Они представляют функции GDI ExtTextOut и менее известную функцию PolyTextOut в ANSI- и Unicode-версиях. Функция PolyTextOut представляет собой простую последовательность вызовов ExtTextOut, объединенных в один вызов. Вызовы TextOut преобразуются GDI в ExtTextOut. В EMF они представлены одним типом EMREXTTEXTOUT. Как говорилось выше, в GDI передавать массив межсимвольных расстояний при вызове ExtTextOut необязательно, но в EMF этот массив всегда заполняется правильными данными, что обеспечивает фиксированное, однозначное расположение всех символов в строке. Из рис. 16.1 и 16.2 видно, что при увеличении EMF расстояния между символами тоже масштабируются. Однако глифы символов на этих двух рисунках сохраняют прежние размеры, поскольку при выводе используется шрифт, выбранный по умолчанию в контексте устройства. Если бы при выводе использовался логический шрифт, определенный в программе, глифы бы нормально масштабировались. Мы знаем, что увеличение иногда приводит к искажениям, поскольку исходные данные получаются посредством округления более точных вещественных величин. Чтобы сгенерировать точные массивы межсимвольных расстояний, приложение может создать логический контекст устройства с высоким разрешением и воспользоваться приемами, описанными в предыдущей главе. Как показали эксперименты, в Windows 2000 с компонентом Uniscribe и установленной поддержкой нескольких языков после записей EMRTEXT0UT для функций TextOut и ExtTextOut добавляются вызовы создания, выбора и удаления логических шрифтов. В результате при каждом выводе текста в EMF может появляться десяток ненужных записей. В Windows NT и даже в ранних версиях Windows 2000 ничего похожего нет.
Строение расширенных метафайлов 929 Вызовы DrawText, DrawTextEx и TabbedTextOut в EMF преобразуются в серии вызовов ExtTextOut, чередующихся с вызовами SetTextAlign, SetBkMode, MoveToEx и даже SelectClipRgn. Вероятно, вас удивит количество записей EMF, представляющих всего один вызов DrawText или TabbedTextOutput. Аппаратная независимость EMF Познакомившись поближе с архитектурой EMF, давайте вернемся к главному вопросу — до какой же степени формат EMF является аппаратно-независимым? Аппаратная независимость — важнейший аспект архитектуры расширенных метафайлов. При описании аппаратной независимости EMF Microsoft утверждает, что сохраненный в EMF рисунок 2x4 дюйма сохраняет исходные размеры при печати на принтере с разрешением 300 dpi и при выводе на монитор SuperVGA. При вызове CreateEnhMetaFile указывается прямоугольник кадра, сохраняемый в заголовочной структуре EMF вместе с данными о разрешении и размерах поверхности. Приложение может запросить данные из заголовка, получить размеры рисунка в физических единицах, преобразовать их в логическую систему координат текущего контекста устройства и указать при вызове PlayEnhMetaFile; в этом случае метафайл будет иметь точно такие же размеры, с какими он был записан. EMF также можно масштабировать с разными коэффициентами. Словом, в отношении аппаратной независимости размеров EMF проявляет себя неплохо. С другой стороны, метафайл, при построении которого за эталон был взят экранный контекст, зависит от размеров экрана, для которых система всегда возвращает значения 320 х 240 мм. Разрешение, вычисленное по этим размерам, отличается от логического разрешения экрана, используемого в большинстве приложений. Другая проблема, которую также пытается решить EMF, — аппаратная зависимость цветов. Все аппаратно-зависимые растры в EMF преобразуются в ап- паратно-независимые растры. Цвета накапливаются и сохраняются в палитре метафайла, которую приложение может легко получить и реализовать перед воспроизведением EMF. Следовательно, если метафайл использует логическую палитру, его цвета можно достаточно успешно воспроизвести на другом устройстве с поддержкой палитры. Конечно, при воспроизведении цветов на устройствах High Color и True Color возникают небольшие проблемы. Но если метафайл был построен на устройстве True Color и не использует логическую палитру, его воспроизведение на устройствах с палитрой плохо обеспечивается на уровне базовых возможностей EMF. Даже если приложение выберет и реализует полутоновую палитру перед воспроизведением такого метафайла, GDI все равно возвращается к системной палитре из 20 стандартных цветов. Другой аспект аппаратной независимости — различия в реализациях вечно изменяющегося интерфейса Win32 API. Метафайл, созданный в Windows NT/ 2000, не всегда удается полностью воспроизвести в Windows 95/98, поскольку в нем могут использоваться дополнительные возможности, поддерживаемые только в Windows NT/2000. Чтобы ваш метафайл мог использоваться на всех активных платформах Win32, приходится ограничиваться функциями GDI, реализованными в Windows 95.
930 Глава 16. Метафайлы Проблемы возникают и со шрифтами. Запись создания логического шрифта EMREXTCREATEFONTINDIRECTW содержит очень подробное описание шрифта в виде структуры EXTLOGFONTW. В нее входит структура LOGFONT вместе с полным именем, стилем, версией, идентификатором разработчика и числом PANOSE. Руководствуясь этими данными, GDI находит точное или хотя бы очень близкое соответствие. Но если подходящий шрифт найти не удается, EMF не удастся нормально воспроизвести на другом компьютере. Спулер Windows NT/2000 решает проблему зависимости от шрифтов, внедряя шрифты в EMF-файл спулера перед его отправкой на сервер печати. Однако базовый формат EMF не поддерживает ни внедрения шрифтов, ни оперативной установки шрифтов в системе. В EMF отсутствуют записи для таких функций, как AddFontResource. Перечисление записей EMF В предыдущем разделе было показано, как происходит перебор всех записей EMF. В Win32 API поддерживается интересная функция EnumEnhMetaFile, которая позволяет приложению организовать перечисление всех записей при воспроизведении EMF в контексте устройства. Это действительно интересная и неповторимая функция, поскольку с ее помощью приложение может следить за воспроизведением EMF и вмешиваться в него в случае необходимости. typedef struct tagHANDLETABLE { HGDIOBJ objecthandle[l]; // Переменный размер } HANDLETABLE; typedef struct tagENHMETARECORD { DWORD iType; DWORD nSize; DWORD dParm[l]; // Переменный размер } ENHMETAFILERECORD; typedef int (CALLBACK* ENHMFENUMPROCKHDC hDC, HANDLETABLE * IpHTable, CONST ENHMETARECORD * IpEMFR, int nObj, LPARAM lpData): BOOL EnumEnhMetaFileCHDC hDC. HENHMETAFILE emf, ENHMFENUMPPRC IpEnhMetaFunc, LPVOID lpData. CONST RECT * IpRect); BOOL PlayEnhMetaFileRecord(HDC hDC. LPHANDLETABLE IpHandleTable. CONST ENHMETARECORD * IpEnhMetaRecord. UINT nHandles); Функция EnumEnhMetaFile получает пять параметров: манипулятор приемного контекста устройства, манипулятор EMF, указатели на функцию косвенного вызова и данные, предоставленные приложением, и прямоугольник воспроизведения EMF на приемной поверхности. По сравнению с PlayEnhMetaFile добавились два новых параметра — третий и четвертый. На самом деле функции EnumEnhMetaFile и PlayEnhMetaFile похожи — обе воспроизводят EMF в прямоугольной области приемного контекста устройства. Впрочем, PlayEnhMetaFile еще и вызывает заданную функцию для каждой записи EMF. Функция косвенного вызова в EnumEnhMetaFile тоже получает пять параметров: манипулятор приемного контекста устройства, указатель на таблицу мани-
Перечисление записей EMF 931 пуляторов EMF, указатель на текущую запись EMF, размер таблицы манипуляторов EMF и указатель на данные, предоставленные приложением. Таблица манипуляторов EMF предназначена для преобразования индексов объектов, используемых в EMF, в манипуляторы объектов GDI. Размер этой таблицы хранится в заголовочной записи EMF. Информация о каждой записи EMF передается функции косвенного вызова в структуре ENHMETARECORD. Запись EMF в этой структуре представляет собой 32- разрядный идентификатор типа и 32-разрядное поле размера, за которыми следует некоторое количество двойных слов. Отдельные записи EMF воспроизводятся функцией PlayEnhMetaFileRecord. Эта функция была включена в GDI для того, чтобы функция косвенного вызова могла вызвать ее и воспроизвести текущую запись EMF в приемном контексте устройства. Класс C++ для перечисления записей EMF Любая функция косвенного вызова, получающая данные от приложения, является хорошим кандидатом для объектной реализации, поскольку вы можете передать указатель this статической функции, которая передаст вызов виртуальной функции C++. Ниже приведен родовой класс C++ для перечисления записей EMF. class KEnumEMF { // Виртуальная функция для обработки записей EMF // Чтобы завершить перечисление, функция возвращает О virtual int ProcessRecordCHDC hDC, HANDLETABLE * pHTable. const ENHMETARECORD * pEMFR. int nObj) { return 0; } // Статическая функция косвенного вызова // передает управление виртуальной функции ProcessRecord static int CALLBACK EMFProc(HDC hDC, HANDLETABLE * pHTable. const ENHMETARECORD * pEMFR, int nObj, LPARAM IpData) { KEnumEMF * pObj = (KEnumEMF *) IpData: if ( IsBadWritePtrCpObj. sizeof(KEnumEMF)) ) { assert(false); return 0; } return pObj->ProcessRecord(hDC, pHTable, pEMFR, nObj); } public: BOOL EnumEMF(HDC hDC. HENHMETAFILE hemf. const RECT * IpRect) {
932 Глава 16. Метафайлы return ::EnumEnhMetaFile(hDC. hemf. EMFProc, this. IpRect); } }: Класс KEnumEMF содержит виртуальную функцию ProcessRecord, которая берет на себя роль функции косвенного вызова. Реализация по умолчанию возвращает 0, завершая перечисление записей EMF. Главная точка входа EnumEMF вызывает функцию EnumEnhMetaFi le GDI и передает ей статическую функцию EMFProc, которая передает управление виртуальной функции C++. Подобная инкапсуляция средств Win32 API в классах C++ хороша тем, что все операции с Win32 API выполняются всего в одном месте. Вы можете добавить новые переменные в производных классах, реализовать новые возможности переопределением виртуальных функций, не говоря уже о создании нескольких экземпляров класса. Замедленное воспроизведение EMF В простейшей реализации виртуальная функция KEnumEMF::ProcessRecord сводится к простому вызову PlayEnhMetaFileRecord. Фактически вы вручную реализуете PlayEnhMetaFile с небольшой задержкой, связанной с появлением дополнительного кода. Хотя это слово вызывает отрицательные ассоциации, правильно выбранная задержка помогает проследить за воспроизведением метафайлов. Приведенный ниже класс KDel ayEMF делает небольшую паузу перед воспроизведением записи. class KDelayEMF : public KEnumEMF { int m_delay; virtual int ProcessRecordCHDC hDC. HANDLETABLE * pHTable, const ENHMETARECORD * pEMFR. int nObj) { Sleep(m_delay); return PlayEnhMetaFileRecord(hDC, pHTable, pEMFR, nObj); } public: KDelayEMF(int delay) { m_delay = delay; } }: // Пример использования KDelayEMF delay(lO); del ay.EnumEMF(hDC. hEmf. IpPictureRect); Если вы когда-нибудь интересовались тем, как создаются качественные трехмерные эффекты при выводе текста, скопируйте объемный текст в программу EMF этой главы и проследите за замедленным воспроизведением. Построение трехмерной строки показано на рис. 16.6.
Перечисление записей EMF 933 Рис. 16.6. Замедленное воспроизведение EMF Трассировка воспроизведения EMF От простейшей задержки мы переходим на следующий уровень — трассировке воспроизведения EMF и выводе информации в текстовое окно. Класс KTraceEMF использует класс KEmfDC для расшифровки записей EMF и вывода данных в текстовом окне, реализованном классом KLogWindow. class KTraceEMF : public KEnumEMF { int KEmfDC int HGDIOBJ FLOAT m_nSeq; m emfdc; m value[32]; m_object[8]; m float[8]; virtual int ProcessRecordCHDC hDC, HANDLETABLE * pHTable, const ENHMETARECORD * pEMFR, int nObj) } CompareDC(hDC); m_pl_og->Log("*4d: *08x *3d % 6d \ m_nSeq++, pEMFR. pEMFR->iType, pEMFR->nSize); m_pLog->Log(m_emfdc.DecodeRecord((const EMR *) pEMFR)); m_pLog->Log("\r\n"); return PlayEnhMetaFileRecord(hDC. pHTable, pEMFR, nObj); public: KLogWindow * m_pLog; void CompareDC(HDC hDC);
934 Глава 16. Метафайлы KTraceEMFCHINSTANCE hlnst) } m_pLog = new KLogWindow; // Выделенная память освобождается // при обработке WMJOESTR0Y m_pLog->Create(hInst, "EMF Trace"); mjiSeq = 1; memset(m_value, memset(m_object, memsetdn float, OxCD, sizeof(m_value)); OxCD, sizeof(m_pbject)); OxCD, sizeof(m float)); Одна из дополнительных возможностей, реализованных в классе KTraceEMF, — сравнение атрибутов контекста устройства перед воспроизведением, между записями EMF и после воспроизведения. Атрибуты контекста устройства запрашиваются обычными функциями GDI (такими, как GetBkMode), сохраняются в трех массивах и сравниваются с предыдущими значениями. Наблюдая за изменениями в атрибутах контекста устройства, вы сможете лучше понять, как реализовано воспроизведение EMF. Ниже приведены неполные данные трассировки, полученные с использованием класса KTraceEMF. /////////////// Перед выводом /////////////// GraphicsMode WT.eMll WT.eM12 WT.eM21 WT.eM22 WT.eDx WT.eDy Pen Brush Font Palette 1 1.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0x01b00017 0x01900010 0x018a0021 0xa50805ca /////////////// Начало вывода 111111111111111 GraphicsMode : 2 WT.eDx : 5.00000 WT.eDy : 5.00000 Font : 0x018a0026 Palette : 0x0188000b 1: 012e0000 1 132 // Заголовок 2: 012e0084 27 16 MoveToEx(hDC, 300, 50, NULL); 3: 012e0094 54 16 LineTo(hDC, 350. 50); 4: 012e00a4 27 16 MoveToExChDC. 300. 51. NULL); 5: 012e00b4 54 16 LineTo(hDC, 400. 51): 6: 012e00c4 43 24 Rectangle(hDC. 300. 60. 349. 7: 012e00dc 43 24 Rectangle(hDC. 350, 80. 399. 129); 8: 012e00f4 42 24 Ellipse(hDC, 410, 60. 459, 149); 9: 012e010c 42 24 Ellipse(hDC, 460, 60, 509, 149); 10: 012e0124 76 100 PatBltChDC. 300. 150. 100. 100. BLACKNESS); 11: 012e0188 76 100 PatBltChDC. 400. 160. 100. 100. PATINVERT); 109);
Перечисление записей EMF 935 12: 012е01ес 39 24 h0bj[l]=CreateSolidBrush(RGB(0x59.0x97. 0x64)); 13: 012е0204 37 12 SelectObjecUhDC, hObjCl]): Brush : 0x5fl0045e 71: 012e0978 14 20 // EMREOFC0. 16, 20) llllIII IIIII III После вывода 111111111111111 GraphicsMode : 1 WT.eDx : 0.00000 WT.eDy : 0.00000 Font : 0x018a0021 Palette : 0xa50805ca Происходит нечто весьма интересное. Перед вызовом EnumEnhMetaFile контекст устройства находится в совместимом графическом режиме с атрибутами по умолчанию (за исключением полутоновой палитры). Когда функция косвенного вызова приступает к обработке заголовочной записи EMF, контекст переключается в расширенный графический режим, матрица мирового преобразования обновляется, а манипуляторы шрифта/палитры заменяются стандартными объектами GDI. Это говорит о том, что в Windows NT/2000 GDI при воспроизведении EMF использует расширенный графический режим с мировым преобразованием, а другие атрибуты контекста устройства перед воспроизведением записей EMF всегда сбрасываются в состояние по умолчанию. Расширенный графический режим очень удобен для воспроизведения EMF. GDI просто объединяет три матрицы преобразования (см. рис. 16.5), назначает результат матрицей мирового преобразования при воспроизведении EMF и затем выводит все записи с исходными координатами, хранящимися в EMF. Остается лишь преобразовать регион отсечения из системы координат устройства эталонного контекста в систему координат устройства приемного контекста. В Windows 95/98 расширенный графический режим фактически не реализован, поэтому GDI приходится использовать режим отображения MM_ANISOTROPIC в сочетании со специальной настройкой отображения «окно/область просмотра», эквивалентной комбинированной матрице преобразования. В ходе трассировки также выводятся сведения об изменениях в объектах GDI, связанных с контекстом устройства. Мы видим, что GDI перед воспроизведением EMF всегда заменяет эти объекты стандартными объектами GDI. В частности, это объясняет, почему выбор логической палитры перед воспроизведением не обеспечивает вывода правильных цветов в EMF, не содержащих собственной логической палитры. Класс KTraceEMF можно наделить и другими полезными способностями — например, класс может отслеживать создание, выбор и удаление объектов GDI и искать возможные утечки ресурсов в EMF. Хотя GDI всегда освобождает манипуляторы, оставшиеся в таблице манипуляторов EMF, ликвидация утечки ресурсов поможет в отладке кода построения EMF. Динамическое изменение EMF Запись EMF, передаваемая функции косвенного вызова, доступна только для чтения; ее невозможно модифицировать и вернуть GDI. Однако приложение
936 Глава 16. Метафайлы может создать копию этой записи, изменить ее во время выполнения программы и передать GDI для вывода. Иначе говоря, программа может динамически изменить EMF и передать GDI измененный вариант. Ниже приведен простой класс, который преобразует все цвета текста, фона, перьев и кистей в оттенки серого. Если EMF не содержит цветных растров, в результате воспроизведения классом KGrayEMF цветной метафайл преобразуется в серый. Код преобразования цветных растров в оттенки серого приведен в главе 12. inline void MaptoGray(COLORREF & cr) { if ( (cr & OxFFOOOOOO) != PALETTEINDEX(O) ) // He является индексом { // палитры BYTE gray - ( GetRValue(cr) * 77 + GetGValue(cr) * 150 + GetBValue(cr) * 29 + 128 ) / 256; cr = (cr & OxFFOOOOOO) | RGB(gray, gray, gray); } } class KGrayEMF ; public KEnumEMF { virtual int ProcessRecordCHDC hDC. HANDLETABLE * pHTable. const ENHMETARECORD * pEMFR, int nObj) { int rslt; switch ( pEMFR->iType ) { case EMR_CREATEBRUSHINDIRECT: { EMRCREATEBRUSHINDIRECT cbi; cbi - * (const EMRCREATEBRUSHINDIRECT *) pEMFR; MaptoGray(cbi.lb.lbColor); rslt - PlayEnhMetaFileRecord(hDC. pHTable, (const ENHMETARECORD *) & cbi, nObj); } break; case EMR_CREATEPEN: { EMRCREATEPEN cp; cp - * (const EMRCREATEPEN *) pEMFR; MaptoGray(cp.lopn.lopnColor); rslt - PlayEnhMetaFileRecord(hDC. pHTable, (const ENHMETARECORD *) & cp, nObj); } break; case EMR_SETTEXTCOLOR: case EMR_SETBKC0L0R; { EMRSETTEXTCOLOR stc: Stc - * (const EMRSETTEXTCOLOR *) pEMFR;
Перечисление записей EMF 937 MaptoGray(stc.crColor); rslt = PlayEnhMetaFileRecorcKhDC. pHTable, (const ENHMETARECORD *) & stc. nObj); } break; default: rslt - PlayEnhMetaFileRecorcKhDC, pHTable. pEMFR. nObj); } return rslt; } }: Класс KGrayEMF является отдельным представителем целой категории классов преобразований, применяемых к EMF во время воспроизведения. Аналогичным способом можно изменить толщину пера в соответствии с параметрами графического устройства, заменить штриховые узоры, слишком мелкие для печати на принтере, исключить из документа все растровые вставки или отрегулировать цвета. Построение производных метафайлов Приемный контекст устройства функции PlayEnhMetaFile (а следовательно, и метода KEnumEMF: :EnumEMF) может быть любым допустимым контекстом, в том числе и метафайловым. Если вызвать PlayEnhMetaFile для контекста устройства EMF и передать специально написанную функцию косвенного вызова, вы фактически будете управлять процессом создания нового расширенного метафайла на основе записей существующего метафайла. Использовать подобные возможности всегда очень интересно, хотя наряду с новыми знаниями вас ждет немало сюрпризов. Ниже приведены функция FilterEMF и используемая ею вспомогательная функция MaplOumToLogical. void MaplOumToLogical(HDC hDC. RECT & rect) { POINT * pPoint = (POINT *) & rect; // Перейти от единиц 0,01 мм к пикселам текущего устройства for (int i=0; i<2; i++) { int t - GetDeviceCaps(hDC. HORZSIZE) * 100; pPoint[i].x = ( pPoint[i].x * GetDeviceCaps(hDC. HORZRES) + t/2 ) / t; t - GetDeviceCaps(hDC. VERTSIZE) * 100; pPoint[i].y = ( pPoint[i].y * GetDeviceCaps(hDC. VERTRES) + t/2 ) / t; } // Преобразовать в логическую систему координат DPtoLPChDC. pPoint, 2); }
938 Глава 16. Метафайлы HENHMETAFILE Fi1terEMF(HENHMETAFILE hEmf. KEnumEMF & filter) { ENHMETAHEADER emh; GetEnhMetaFileHeader(hEmf, sizeof(emh), &emh); RECT rcFrame; memcpy(& rcFrame, & emh.rclFrame, sizeof(RECT)); HDC hDC = QuerySaveEMFFileCFiltered EMF\0". & rcFrame. NULL); if ( hDO-NULL ) return NULL; MaplOumToLogicaKhDC, rcFrame): filter.EnumEMF(hDC. hEmf. & rcFrame); return CloseEnhMetaFile(hDC); } Функция FilterEMF строит новый метафайл на основании данных существующего метафайла. Процесс преобразования полностью контролируется экземпляром KEnumEMF или производного класса. Кадр нового метафайла определяется прямоугольником кадра исходного метафайла, преобразованным в логическую систему координат нового метафайла. Это гарантирует, что новый метафайл имеет те же размеры и те же отступы, что и исходный. Преобразование кадра выполняется вспомогательной функцией MeplOumToLogical. Например, если в качестве фильтра используется класс KGrayEMF, функция FilterEMF преобразует метафайл в оттенки серого цвета (если в нем отсутствуют цветные растры). Новый метафайл состоит из тех же объектов, но окрашивается в другие цвета. Однако в приведенном примере новый метафайл увеличивается на 424 байта и в нем появляется 26 дополнительных записей. Ниже приведена расшифровка новых записей EMF, полученная при помощи класса KTraceEMF. 2: SaveDC(hDC); 3: SetLayout(hDC. 0); 4: SetMetaRgn(hDC); 5: SelectObject(hDC. GetStockObjet(WHITE_BRUSH)); 6: SelectObject(hDC. GetStcckObjet(BLACK_PEN)); 7: SelectObjecUhDC. GetStockObjet(DEVICE_DEFAULT_FONT)); 8: SelectPalette(hDC. (HPALETTE)GetStockObjet(DEFAULT_PALETTE). TRUE); 9: SetBkColor(hDC. RGB(OxFF.OxFF.OxFF)); 10: SetTextColor(hDC, RGB(O.O.O)): 11: SetBkMode(hDC. OPAQUE): 12: SetPolyFillMode(hDC, ALTERNATE); 13: SetR0P2(hDC. R2_C0PYPEN): 14: SetStretchBltMode(hDC, STRETCH_ANDSCANS); 15: SetTextAlign(hDC. TAJIOUPDATECP | TA_LEFT | TAJOP); 16: SetBrushOrgEx(hDC. 0, 0. NULL); 17: SetMiterLimitChDC. 0.00000); 18: // Unknown record [120] 19: MoveToEx(hDC, 0. 0. NULL): 20: SetWorldTransform(hDC. 1, 0. 0. 1, 0, 0); 21: ModifyWorldTransform(hDC. 1, 0, 0. 1, 0, 0. 0x4 /*Unknown*/); 22: SetLayout(hDC. 0);
Перечисление записей EMF 939 23: // GdiComment(52, GDIC. 0x2) //GdiComment(8, GDIC, 0x3) RestoreDC(hDC, -1); DeleteObject(hObj[l]); Delete0bject(h0bj[2]); В этом листинге приведен точный список действий, выполняемых GDI при воспроизведении EMF. Поскольку воспроизведение происходит в метафайло- вом контексте, все операции не просто незаметно выполняются, а фиксируются в виде записей EMF. Подробнее о воспроизведении EMF Давайте проанализируем все операции, выполняемые GDI при воспроизведении EMF. Сначала GDI сохраняет текущее состояние контекста устройства функцией SaveDC. Напоследок прежнее состояние контекста восстанавливается функцией RestoreDC, поэтому сторона, вызвавшая PlayEnhMetaFile или EnumEnhMetaFile, не заметит никаких изменений в контексте устройства. Далее вызывается редко используемая функция SetMetaRgn. Напомню, что ме- тарегион представляет собой атрибут контекста устройства, который в сочетании с регионом отсечения обеспечивает двухуровневый контроль над отсечением. Функция SetMetaRgn преобразует текущий регион отсечения, заданный приложением перед вызовом EnumEnhMetaFile, в метарегион и сбрасывает регион отсечения в NULL. В процессе воспроизведения EMF регион отсечения в EMF может интерпретироваться как регион отсечения, но при фактическом выводе он всегда объединяется с метарегионом. Перед нами пример очень умного использования метарегионов — впрочем, не исключено, что метарегионы были разработаны как раз для воспроизведения EMF. Обратите внимание: ни прямоугольник кадра, ни прямоугольник воспроизведения не имеют ничего общего с отсечением. Десяток записей, следующих за вызовом SetMetaRgn, понять несложно. Все эти записи присваивают атрибутам контекста устройства значения по умолчанию, чтобы отделить воспроизведение EMF от текущих значений атрибутов. Записи EMF, соответствующие вызовам SetWorldTransform и ModifyWorldTransform, иногда бывают очень интересными. Поскольку мы выполняем все необходимые вычисления в FilterEMF, обе записи содержат матрицы тождественных преобразований. При действующих преобразованиях смещения или масштабирования матрицы изменились бы соответствующим образом. Как ни странно, в EMF отсутствует команда переключения в расширенный графический режим. Из выходных данных класса KTraceEMF (см. предыдущий пример) мы знаем, что GDI изменяет графический режим при воспроизведении EMF. Существует лишь одно разумное объяснение: разработчики хотели, чтобы новый метафайл можно было использовать и в Windows 95/98. Вообще-то Windows 98 GDI тоже создает записи EMF для мировых преобразований, но во время воспроизведения используется режим отображения MM_ANISOTROPIC. При воспроизведении EMF с использованием мировых преобразований особое внимание следует обращать на текст. Как говорилось выше, в совместимом графическом режиме текст не переворачивается даже в том случае, если в логической системе координат ось у направлена в противоположном направлении. В расширенном графическом режиме текст выводится в соответствии с направ-
940 Глава 16. Метафайлы лением осей, как и все остальные графические примитивы. В Windows NT/2000 проблема решается изменением мировой системы координат перед вызовом текстовых функций. В EMF могут использоваться любые режимы отображения. Кстати, обратите внимание на передачу недокументированного флага 4 при вызове ModifyWorldTransform. Три последних записи EMF восстанавливают прежнее состояние контекста устройства и удаляют два объекта GDI. Похоже, в исходном метафайле обнаружилась утечка ресурсов. Впрочем, ее причины кроются не в моем коде, а в действиях GDI при построении исходного метафайла. Моя программа получала две кисти системных цветов вызовами GetSysColorBrush. Поскольку кисти возвращаются из таблицы, принадлежащей USER32.DLL, они должны удаляться самим приложением. Кисти системных цветов ассоциируются с идентификатором процесса, равным 0, что позволяет совместно использовать их на уровне системы. Однако цвета системных кистей являются аппаратно-зависимыми, поэтому при построении EMF GDI преобразует их в обычные однородные кисти. При построении исходного метафайла GDI забывает удалить эти кисти. Остается рассмотреть еще две разновидности записей: недокументированные записи EMF и записи GdiComment. Недокументированные типы записей EMF На стадии инициализации контекста используется недокументированный тип записи EMF, определяемый в WINGDI.H с идентификатором EMRRESERVED120. Функция EnumEnhMetaFile позволяет легко узнать, что делает эта запись. Для этого следует включить проверку EMRRESERVED120 в функцию косвенного вызова, передать запись GDI функцией PlayEnhMetaFileRecord, установить точку прерывания и проанализировать несколько ближайших ассемблерных команд. Оказывается, функция PlayEnhMetaFileRecord проверяет, входит ли тип записи EMF в допустимый интервал (от EMRMIN до EMR_MAX), и вызывает функцию из таблицы. Для EMRRESERVED120 вызывается функция bPlay:: MRSETTEXTJUSTIFICATION, которая, в свою очередь, вызывает SetTextJustification. Смысл вызова этой функции неясен, поскольку при выводе текста используются явно заданные межсимвольные интервалы. Ниже приведен полный список недокументированных типов записей EMF. EMR_RESERVED_105 ESCAPE EMR_RESERVED_106 ESCAPE EMR_RESERVED_107 STARTDOC EMR_RESERVED_108 SMALLTEXTOUT EMR_RESERVED_109 FORCEUFIMAPPING EMR_RESERVED_110 NAMEDESCAPE 117 не используется EMR_RESERVED_119 SETLINKEDUFIS EMR_RESERVED_120 SETTEXTJUSTIFICATION GDIComment Специальная функция GDIComment предназначена для включения в EMF комментариев (дополнительных данных). Комментарий может содержать любую приватную информацию, известную обеим сторонам (читающей и записывающей). Например, приложение может включить в EMF PostScript-версию представлен-
EMF как средство программирования 941 ного объекта. Осведомленный получатель данных может воспользоваться данными PostScript вместо того, чтобы заниматься расшифровкой команд GDI. Microsoft документирует несколько стандартных комментариев GDI; все они начинаются с 32-разрядного идентификатора GDICOMMENTJDENTIFIER, который в текстовом виде соответствует цепочке символов «GDIC». Например, GDICOMMENT_ WINDOWS_METAFILE присоединяет к EMF данные в старом формате метафайлов Windows. Комментарий GDICOMMENTBEGINGR0UP сообщает о начале группы записей, а комментарий GDICOMMENT_ENDGROUP — о ее завершении. В нашем примере встречаются комментарии GD I COMMENTBEG INGR0UP (2) и GDI - COMMENTENDGROUP (3), которые отделяют вспомогательные записи, добавленные GDI, от исходных команд, переданных приложением. Построение новых метафайлов на базе существующих имеет множество нетривиальных практических применений. Например, к записям EMF могут применяться многочисленные оптимизации — исключение команд создания ненужных объектов или присваивания ненужных значений, а также удаление неиспользуемых частей растров. Возможны и другие применения — например, создание специальных эффектов с использованием не аффинных преобразований. В следующем разделе мы рассмотрим еще одно интересное применение — построение кода С по данным EMF. EMF как средство программирования Итак, мы выяснили, что EMF представляет собой графический объект, который может использоваться для кодировки, передачи и воспроизведения графических данных между разными приложениями, устройствами и операционными системами. Однако возможность записи команд GDI в одном удобном объекте находит и другие интересные применения. В этом разделе рассматриваются возможности применения EMF не только в области компьютерной графики, но и при программировании. Декомпилятор EMF В одном из разделов этой главы был представлен класс KEmfDC, выводящий расшифрованные записи EMF в виде иерархического дерева или в текстовое окно. На самом деле расшифровка записей EMF — дело второстепенное. Класс KEmfDC предназначен для декомпиляции EMF во фрагменты кода С. Компиляция и выполнение этих фрагментов приводит к тому же результату, что и воспроизведение EMF. Правила преобразования простых записей EMF в программный код С определяются особыми строковыми шаблонами. Рассмотрим несколько примеров. const Emrlnfo Pattern [] = { { EMRJETWINDOWEXTEX. "SetWindowExtTex(hDC, *d. Xd. NULL);" }, { EMRJXTCREATEFONTINDIRECTW. ,,#o=CгeateFont(XdДdДdДd.XdДbДbДbДbДbДbДbДbДS);,, }. { EMR_SETPIXELV . "SetPixeWhDC. *d. *d. #с;Г },
942 Глава 16. Метафайлы { EMR_POLYGON . "\nstatic const POINT Points Jn[]=#P;\n" "Polygon(hDC. Points Jn, %A\" }. }: Первый шаблон означает, что запись EMR_SETWINDOWEXTEX преобразуется в вызов SetWindowExtEx с двумя 32-разрядными целыми параметрами, значения которых берутся из записи EMF. Во втором примере запись EMR_EXTCREATEFONTINDIRECTW декомпилируется в команду присваивания результата CreateFont в запись таблицы объектов EMF. Список параметров CreateFont состоит из пяти 32-разрядных значений, восьми 8-разрядных значений и строки. В третьем примере запись EMR_SETPIXELV преобразуется в вызов функции SetPixelV, которой передаются два 32-разрядных целых параметра и дескриптор цвета. В последнем примере (EMR_ POLYGON) создается статический массив для хранения массива POINT переменного размера, используемого при вызове функции Polygon. Более сложные записи EMF, которые не удается преобразовать по шаблонам, обрабатываются специальными фрагментами кода. Растры сохраняются в отдельных файлах, которые затем подключаются в виде ресурсов. EMF преобразуется в функцию OnDraw, которой при вызове передается манипулятор контекста устройства. После добавления небольших фрагментов кода получается простая, но вполне законченная программа, которая создает простое окно и обрабатывает сообщение WM_PAINT для вывода декомпилированного метафайла. Ниже приведен пример вывода декомпилятора. Как видите, наша программа находит одинаковые растры и задействует одну копию (два вызова StretchDIBits используют один и тот же растр). void OnDrawCHDC hDC) { HGDIOBJ h0bj[5] = { NULL }; MoveToEx(hDC, 300. 50. NULL); LineTo(hDC. 350. 50); Rectangle(hDC. 300. 60. 349. 109); Ellipse(hDC. 410. 60. 459. 149); PatBl t(hDC.300.150.100.100.BLACKNESS); h0bj[l]=CreateSolidBrush(RGB(0x59.0x97.0x64)): SelectObject(hDC.hObj[1]); PatBlt(hDC.300.300.100.100.PATCOPY); SelectObjectChDC. GetStockObject(WHITE_BRUSH)); static const POINT Points_l[]={ 10. 200. 50. 200. 90. 200. 130. 200 }; PolylineChDC. PointsJL. 4); static KDIB Dib_l; Dib_l.Load(IDB_BITMAPl);// 350x250x8 Dib_l.StretchDIBits(hDC. 10.10.350,250. 0.0.350.250. DIB_RGB_COLORS.SRCCOPY); Dib_l.StretchDIBits(hDC. 10.270.350.250. 0.0.350.250. DIB RGB COLORS.SRCCOPY);
EMF как средство программирования 943 Возникает вопрос — кому и зачем нужно декомпилировать EMF в код C/C++? По многим причинам. По мере усложнения программ (особенно если разные компоненты разрабатываются разными группами или даже компаниями) становится очень трудно анализировать код на системном уровне. У инженера имеется множество приборов, помогающих ему разобраться в поведении системы; в распоряжении программиста только отладчики, средства отслеживания API и команды трассировки. При графическом выводе в EMF регистрируются все вызовы GDI, поступившие от разных компонентов системы. Декомпиляция EMF в более наглядный код С упрощает диагностику возникающих затруднений и поиск возможных решений. Декомпилированный код также помогает находить лишние вызовы GDI и неэффективные конструкции, а кроме того, выявлять те возможности GDI, которыми по разным причинам лучше не пользоваться. Диагностика проблем с печатью затруднена тем, что окончательный результат обеспечивается тесным взаимодействием приложения, GDI и драйвера принтера. Большинство драйверов принтеров поддерживают спулинг в формате EMF. Сохраните метафайл, отправленный на принтер, декомпилируйте его и проанализируйте результат — обычно это помогает решить многие проблемы с печатью. Метафайл можно рассматривать как своего рода «срез» программы, поскольку в нем сохраняются только команды графического вывода в контексте устройства, а все остальные функции просто выполняются без сохранения. Например, если вы используете функцию GetGlyphOutline для получения контуров глифов при выводе объемного текста в контексте EMF, в метафайле сохраняются только итоговые вызовы графических функций. Это бывает полезно, если вы хотите пропустить длительные вычисления и воспользоваться окончательными данными для повышения эффективности вывода. Декомпилированный метафайл упрощает обработку предварительно обработанных данных в приложениях. Так, в некоторых приложениях для изменения привычной прямоугольной формы окна используются данные сложных регионов, построенных заранее по растровым изображениям или векторным объектам. Некоторые графические функции API применяют графические данные, сгенерированные GDI. Скажем, DirectDraw не работает с объектами регионов GDI напрямую, но задействует структуру REGIONDATA для определения отсечения. Декомпиляция EMF также может принести немалую пользу в области оптимизации. Мы знаем, что процесс построения EMF в основном сводится к простой записи команд. Я встречал всего одну разновидность оптимизации — объекты не записываются в EMF, пока они не выбраны в контексте устройства. Кроме того, в некоторых ситуациях усекаются неиспользуемые части растров. В приложениях, критичных по размерам или быстродействию, некоторые проблемы решаются ручной оптимизацией декомпилированных метафайлов. Сохранение EMF-файла спулера Помимо обмена графическими данными между приложениями, метафайлы также используются для работы с заданиями печати в системах Win32. Принтеры обычно работают медленно — гораздо медленнее современных компьютеров. Когда приложение начинает печать, вместо того чтобы заставлять приложение дожидаться ее физического завершения, спулер Windows с помощью GDI пере-
944 Глава 16. Метафайлы сылает все графические запросы от приложения в метафайл. Этот процесс называется спулингом (spooling). Окончание спулинга завершает печать с точки зрения приложения. Пользователь продолжает работу с приложением, а спулер воспроизводит EMF-файл и передает команды драйверу принтера. В Windows 95/98 файлы спулера сохраняются в стандартном формате EMF. Каждая страница печатаемого документа записывается в отдельный файл. Обычно файлы спулера хранятся в каталоге временных файлов Windows с именами вида ^emfxxxx.tmp. Завершив построение страницы EMF, спулер вызывает функцию GDI gdi PI aySpool Stream для передачи страницы драйверу принтера. Точнее говоря, страница сначала пересылается процессору печати, который после необходимой обработки передает задание драйверу принтера. Процесс спулера называется «Spooler Process» и создает окно с именем класса «SpoolProcessClass». При желании внешняя программа может легко найти скрытое окно, созданное процессом спулера, установить для него перехватчик (hook) и подключить свою библиотеку DLL к работе спулера. Эта DLL может перехватывать вызовы gdi - PI aySpool Stream (приемы отслеживания и вмешательства в работу API описаны в главе 4 этой книги). Функция gdi PI aySpool Stream получает файл задания спулера, объединяющий все страницы задания печати в формате EMF. Хотя формат файла задания спулера не документирован, найти в нем имена файлов не так уж трудно. Таким образом, в Windows 95/98 мы можем подключиться к процессу спулера и получить имена всех EMF-файлов спулера перед тем, как они будут переданы драйверу принтера. Зная имя файла, вы можете скопировать файл в формате EMF и делать с ним все, что пожелаете. Спулер Windows NT/2000 работает несколько иначе. Он не создает скрытого окна, а обычные способы внедрения DLL не подходят, поскольку процесс спулера является системным. Даже файлы спулинга устроены иначе. Графические команды всего задания хранятся в одном файле, который не соответствует стандартному формату EMF. Для каждого задания печати спулер создает два файла. Файл с расширением .SHD содержит параметры, а файл с расширением .SPL — графические команды. К счастью, спулер Windows NT/2000 позволяет сохранять файлы после вывода задания печати для повторного использования, поэтому мы сможем получить файлы и без подключения к процессу спулера. По умолчанию файлы спулера создаются в каталоге SystemRoot\system32\spool\printers. Формат файлов спулера Windows NT/2000 можно описать как «формат ме- та-EMF». Файл состоит из последовательности метазаписей, начинающихся с 32-разрядного идентификатора типа и 32-разрядного размера, после которых следуют данные переменного размера. Данные EMF каждой страницы задания печати передаются с одной из этих метазаписей. Подобная архитектура позволяет хранить все задание печати в одном файле спулера. На рис. 16.7 показано окно утилиты EmfScope, предназначенной для сохранения и вывода файлов спулера. В Windows 95/98 EmfScope автоматически перехватывает файлы спулера и отображает их в своем окне по мере поступления. В Windows NT/2000 EmfScope работает с сохраненными файлами спулера. Утилита позволяет изменить масштаб вывода или прокрутить EMF-файл в окне. На рисунке изображена уменьшенная тестовая страница принтера.
Итоги 945 мШШ С \00005 spl 'ЧКЛккжте: ■2X0 Congrat.ulat.ions ! Windows 2000 Printer Test Page IX jO Рис. 16.7. Окно утилиты EmfScope с перехваченным EMF-файлом спулера Как упоминалось выше, диагностика проблем печати обычно сильно затрудняется тем, что в процессе печати в равной степени участвуют приложение, GDI и драйвер принтера. Теперь вы можете получить EMF-файл спулера, вывести его на экран, выбрать нужный масштаб, прокрутить и даже декомпилировать в код С. Конечно, это значительно упрощает поиск возможных неполадок с печатью. Например, если нужный объект отсутствует в файле, драйвер принтера здесь явно ни при чем, и проблемы следует искать в приложении или в GDI. Если для документа генерируется непропорционально большой EMF-файл, вероятно, это связано с неэффективным представлением каких-то команд GDI, поэтому причину следует искать в декомпилированном коде. Если же EMF нормально выглядит на экране, но печатается неверно, скорее всего, это связано с ошибками драйвера принтера. Итоги Эта глава посвящена метафайлам — чрезвычайно полезному средству графического программирования GDI. К сожалению, литература по программированию для Windows обычно не уделяет должного внимания метафайлам. Мы познакомились с основными концепциями двух форматов метафайлов и простыми примерами их практического применения, подробно изучили внутреннее строение метафайлов, рассмотрели процесс перечисления записей EMF, возможность де- компиляции EMF в код С. В завершение были рассмотрены способы сохранения EMF-файлов спулера.
946 Глава 16. Метафайлы Формат расширенных метафайлов Windows в основном разрабатывался для обмена графическими данными между приложениями или устройствами, чтобы изображения могли воспроизводиться с сохранением размеров и цветов. EMF хорошо справляется с этой задачей — настолько хорошо, что этот формат широко используется при печати. Однако формат EMF не позволяет обмениваться графическими данными для других целей — в частности, он не поддерживает редактирование внедренных объектов, поскольку в метафайле вместо высокоуровневых описаний объектов хранятся графические команды GDI. Последний раздел этой главы, посвященный использованию EMF в работе спулера, естественно приводит нас к теме следующей главы — печати. Дополнительная информация Другим распространенным метафайловым форматом является формат CGM (Computer Graphics Metafile). Он разрабатывался под покровительством ISO и ANSI как общий формат независимого от платформы обмена растровыми и векторными данными. Информацию о CGM можно получить на web-сайте www. cgmopen.org. Microsoft Platform SDK содержит нетривиальный пример — редактор EMF. Программа находится в каталоге Samples\Multimedia\MetaFile\MfEdit. Программа расшифровки EMF также входит в MSDN. Примеры программ К этой главе прилагаются три программы, две больших и одна маленькая (табл. 16.2). Родовые функции и классы, относящиеся к работе с EMF, находятся в файлах EMF.H и EMF.CPP. Таблица 16.2. Программы главы 16 Каталог проекта Описание Samples\Chapt_16\EMF Программа иллюстрирует создание, загрузку и сохранение EMF, обмен данными через буфер обмена, расшифровку и различные способы перечисления записей, построение новых метафайлов на основе уже существующих и декомпиляцию EMF Samples\Chapt_16\test Тестовая программа для преобразования декомпилированного метафайла в автономную Windows-программу Samples\Chapt_16\EMFScope Сохранение и вывод EMF-файлов спулера
Глава 17 Печать Операционная система Windows заметно упростила печать по сравнению со старыми версиями DOS, в которых каждое приложение снабжалось собственным комплектом драйверов. Но даже с учетом дополнительных удобств Win32 API коммерческие приложения подняли стандарты качества на такую высоту, что поддержка печати в приложении требует от программиста немалых усилий. Проблемы с реализацией печати в приложениях всегда считались одной из причин популярности MFC (Microsoft Foundation Classes) — библиотеки, обеспечивавшей более удобную (хотя и не идеальную) инкапсуляцию средств печати Win32. В этой главе рассматривается архитектура системы печати Win32 и множество практических задач — подключение к принтеру, вывод в контексте устройства принтера командами GDI и печать простейших примитивов GDI. В примерах этой главы показано, как создать систему аппаратно-независимой многостраничной печати программного кода с выделением синтаксических элементов и как напечатать изображение в формате JPEG. Знакомство со спулером Средства печати Windows образуют довольно сложную подсистему общей графической системы. Хотя с точки зрения обычного пользователя или даже программиста сложность системы печати не столь очевидна, при возникновении нетривиальных проблем с печатью вам придется познакомиться с длинным списком компонентов системы печати и разобраться в их взаимодействиях. В разделе «Архитектура системы печати» главы 2 этой книги приведено подробное описание архитектуры подсистемы печати вместе со списком компонентов. Самыми очевидными участниками процесса печати являются пользовательские приложения, GDI, графический механизм Windows, драйвер печати и принтер. Впрочем, есть и другие, менее известные компоненты — процесс спулера, клиентская библиотека DLL спулера, провайдер печати, процессор печати, языковой монитор, монитор порта и драйвер ввода-вывода.
948 Глава 17. Печать В этом разделе мы не станем подробно рассматривать все перечисленные компоненты, а уделим основное внимание связи обычных приложений Windows с подсистемой печати. Процесс печати Обработка даже простых заданий печати в операционной системе Windows — дело далеко не простое. Весь процесс печати от исходного запроса на печать до ее завершения состоит из десятка с лишним этапов. Ниже приведено краткое описание этого процесса. 1. Приложение запрашивает у клиентской библиотеки DLL спулера Win32 (через функции спулинга или стандартные диалоговые окна) информацию о принтерах. Стандартные диалоговые окна являются удобной оболочкой для использования API спулера. 2. Клиентская библиотека DLL спулера Win32, которая является DLL пользовательского режима, предоставляет приложениям и пользователям интерфейс к драйверу печати. С ее помощью можно получить информацию о принтерах, заданиях печати, параметрах печати и т. д. 3. После инициирования процесса печати приложение передает системе задание печати, используя для этого команды GDI. В GDI существует несколько специальных функций, сообщающих о начале и завершении задания печати, а также о разбиении документа на страницы. 4. GDI получает от приложения команды вывода, записывает их в файл формата EMF (файл спулинга) и передает его процессу спулера. 5. Процесс спулера представляет собой системную службу, управляющую обработкой заданий печати. Клиентская библиотека DLL взаимодействует с процессом спулера через механизм вызова удаленных процедур (Remote Procedure Call, RPC). Спулер передает задание маршрутизатору (router) спулинга. 6. Маршрутизатор должен правильно выбрать провайдера печати для обработки задания. 7. Провайдер печати отвечает за передачу задания печати на компьютер с физически подключенным принтером (локальным или удаленным). Кроме того, он управляет очередью заданий печати и реализует функции API для запуска, остановки и перечисления заданий печати. Операционная система предоставляет локального провайдера печати, сетевого провайдера печати Windows, сетевого провайдера печати Novell и провайдера печати HTTP. Если принтер не подключен к локальному компьютеру, сетевой провайдер печати отвечает за пересылку задания по сети. Окончательная обработка задания осуществляется локальным провайдером печати, который передает задание процессору печати. 8. Процессор печати отвечает за преобразование файла, находящегося в очереди, в формат данных, который может непосредственно обрабатываться принтером. В Windows 2000 чаще всего используется процессор печати EMF, который является частью локального провайдера печати. 9. Процессор печати обращается к GDI с требованием передать EMF-файл спулера в контекст устройства драйвера физического принтера.
Знакомство со спулером 949 10. Графический механизм Windows обращается к драйверу принтера за реализацией графических команд GDI, переданных в контекст устройства принтера, и возможной поддержкой вывода со стороны драйвера. § 11. Драйвер принтера отвечает за преобразование графических примитивов уровня DDI (Device Driver Interface) в низкоуровневые данные в формате, приемлемом для принтера. Драйвер принтера возвращает низкоуровневые данные спулеру. 12. Спулер передает низкоуровневые данные языковому монитору, который отвечает за поддержку двустороннего канала обмена данными между спулером и принтером. Языковой монитор передает данные монитору порта. 13. Монитор порта обеспечивает коммуникационный канал между спулером и драйвером порта ввода-вывода, который работает в режиме ядра и обладает доступом к аппаратному порту ввода-вывода, поддерживаемому принтером. 14. Драйвер порта ввода-вывода пересылает данные с компьютера на принтер. Кроме того, он получает от принтера статусную информацию и возвращает ее монитору порта и языковому монитору. 15. Микрокод принтера, работающий на встроенном процессоре, получает данные из порта ввода-вывода принтера, восстанавливает и преобразует во внутренний формат. При этом он управляет бесчисленными механическими, электрическими и электронными компонентами принтера, обеспечивающими реальный вывод точек на листе бумаги. Принтер может быть оснащен мощным RISC-процессором, большим объемом памяти и даже жестким диском, использовать многозадачную операционную систему реального времени и т. д. Язык управления принтером Язык, на котором управляющий компьютер общается с принтером, называется языком управления принтером (printer control language). Низкоуровневые данные принтера (то есть данные, готовые к печати) выражаются на языке управления принтером. Разные принтеры работают на разных языках, поддерживаемых микрокодом принтера. Некоторые принтеры могут поддерживать несколько языков управления принтером, переключение между которыми осуществляется специальными командами. Языки управления принтером делятся на три основных категории. Выбор языка управления принтером относится к числу важнейших архитектурных решений, принимаемых при проектировании принтера. Язык определяет возможности, сложность и стоимость принтера, степень сложности драйвера, скорость печати и требования к ресурсам управляющего компьютера. Текстовые языки управления принтером В простейших языках управления принтером используется простой текст с ограниченным набором команд форматирования. Языками этой категории управляются классические барабанные принтеры, позволяющие выводить только текст без векторной или растровой графики. Ветераны еще помнят, что на таких принтерах растровую графику приходилось имитировать тщательно подобранными комбинациями букв, образующими различные оттенки серого. Такие принтеры
950 Глава 17. Печать используются и в наши дни для вывода длинных финансовых отчетов на фальцованной бумаге или специальных бланках. Практически любой принтер может работать в текстовом режиме. Например, в окне DOS-сеанса можно скопировать текстовый файл в порт LPT1, и этот файл будет передан на принтер в исходном текстовом виде. Растровые языки управления принтером Вторая категория языков управления принтерами работает с растрами определенных форматов. Большинство принтеров, представленных на современном рынке, относится именно к этой категории. Матричные принтеры, принтеры DeskJet и другие струйные принтеры, простейшие лазерные принтеры — невзирая на принципиальные различия, все они относятся к категории растровых. Данные в растровом языке управления принтером обычно преобразуются к разрешению и цветовому пространству принтера. Например, принтер HP DeskJet может получать данные с разрешением 600 dpi в формате «1-разрядный черный/ 2-разрядный CMY» — это означает, что каждый квадратный дюйм состоит из 600 х 600 пикселов, каждый из которых представлен 7 битами. Растровые данные принтера представляют собой последовательность строк развертки, сжатую в определенный формат и разделенную на последовательность команд. Растровый принтер получает данные в строго определенном порядке — от верхней части страницы к нижней. Когда объем накопленных данных позволит напечатать очередную полосу, принтер выводит их и переходит к приему новых данных. Процедура повторяется до завершения страницы. На растровых принтерах обычно устанавливается память меньшего объема, в которой помещаются растровые данные небольшой части страницы, и более простой микрокод. На растровых принтерах драйверу приходится выполнять всю работу по преобразованию графических примитивов, полученных от приложения, в растровое изображение на уровне отдельных полос. При помощи GDI драйвер принтера делит страницу на полосы. Графические команды каждой полосы воспроизводятся в растре, проходят полутоновую обработку, преобразуются в цветовое пространство принтера и формулируются на языке управления принтером. При альбомной ориентации страница делится на вертикальные полосы вместо горизонтальных, а растровые данные после воспроизведения поворачиваются на 90°. Драйверы растровых принтеров бывают довольно сложными, а преобразование команд GDI в растровые данные с высоким разрешением и высокой цветовой глубиной может быть сопряжено со значительными затратами ресурсов управляющего компьютера. Объем данных и время передачи данных на принтер значительно возрастают с увеличением разрешения. Ниже приведен пример данных на языке управления принтером PCL3, используемом принтерами семейства DeskJet. PCL_RESET "<1B>EM PJL_ENTER_PCL3GUI "<1B>@PJL ENTER LANGUAGE=PCL3GUK0D><0A>M PCL_RESET "<1B>E" CmdStartDoc "<1B>&u600D<1B>*o5W<0409000000>" PCL_USJ_ETTER: "<1B>&12AM PCL_MEDS0URCE_TRAY1 "<1B>&11H" PCL MEDS0URCE PRELOAD "<1В>&1-2Ни
Знакомство со спулером 951 PCL_MEDIA_PLAIN "<1В>&10М" PCL_PQ_NORMAL "<1В>*оОМ" PCL_CRD_K662_C334 ,,<1В>*д2би/<0204025802580002012С012С0004012С>и "<012С0004012С012С0004>И PCL_ORIENT_PORTRAIT M<1B>&100" CmdStartPage H<lB>&10E<lB>*p0y0X<lB>&10L<lB>*rlA" Raster Data "<1B2A62306D32393779326D313776AC00>" "<0103C0EA0003FFFC00C0EA000103C031>" "<3776AC000103C0EA0003FFFC00C0EA00>" CmdEndPage "<1В>*гС<0О" PJLJX IT_LANGUAGE " <1В>П - 12345X" Команды PCL начинаются со служебного символа из набора ASCII (0x1 В в синтаксисе С). Печатная страница в PCL начинается с десятка команд инициализации, сообщающих принтеру информацию о разновидности языка, размерах и источнике бумаги, типе носителя, качестве печати, ориентации и т. д. Далее идет основной блок закодированных растровых данных, после чего следуют завершающие команды. Язык описания страниц Языки третьей категории принимают текстовые данные и векторную графику наряду с растровыми данными. Такие языки управления принтерами позволяют описать страницу с использованием разнообразных геометрических форм, текста, цветов и операций вывода, напоминающих команды GDI. Обычно они называются языками описания страниц (Page Description Language, PDL). К этой категории относятся PostScript, PCL5 и PCL6 с поддержкой векторной графики. Принтеры, поддерживающие современные языки описания страниц, должны быть значительно более мощными, чем принтеры с растровыми языками. Применение геометрических примитивов для описания страниц означает, что порядок следования графических команд в потоке данных невозможно предсказать заранее. Объем памяти принтера должен быть достаточным для того, чтобы хранить полную страницу графических примитивов, отсортированных в порядке их появления на странице, воспроизвести их в растровом формате, произвести полутоновую обработку и отправить на печать. В сущности, принтеру поручаются функции, обычно выполняемые драйвером растрового принтера. Микрокод принтера также должен обеспечить вывод всего текста, для чего он либо использует шрифтовой картридж принтера, либо загружает шрифты TrueType с управляющего компьютера. Поддержка мощного языка описания страниц в некоторых отношениях упрощает драйвер принтера, поскольку снимает необходимость в построении изображения на управляющем компьютере. Можно предположить, что печать должна выполняться быстрее и с меньшими затратами ресурсов управляющего компьютера. Тем не менее отображение команд GDI на команды языка описания стра-
952 Глава 17. Печать ниц иногда становится очень сложной задачей. Ситуация усложняется поддержкой шрифтов устройств, заменой и загрузкой шрифтов. Ниже приведен пример файла PostScript, сгенерированного драйвером PostScript для принтера HP Color LaserJet. <1В> M2345X@PJL JOB @PJL ENTER LANGUAGE - POSTSCRIPT *!PS-Adobe-3.0 mi tie: Document UCreator: Pscript.dll Version 5.0 ^Orientation: Portrait nPageOrder: Special UTargetDevice: (HP Color LaserJet 8500) (3010.104) 1 ULanguageLevel: 3 nEndComments UlncludeResource: font TimesNewRomanPSMT F /F0 0 /256 T /TimesNewRomanPSMT mF /F0S53 F0 [83 0 0 -83 0 0] mFS F0S53 setfont 650 574 moveto (Printer Control Language)[47 28 23 41 23 37 28 21 55 42 41 23 28 42 23 21 50 37 41 41 41 37 4]xshow showpage (ЩРаде: 1]П) = HPageTrailer mrailer moundingBox: 12 12 600 780 UPages: 1 (n[LastPage]n) = UEOF <lB>M2345X(apjL EOJ <1В>П2345Х После длинного заголовка, макросов и определений начинается последовательное преобразование графических команд GDI в команды PostScript. Оператор setfont выбирает шрифт Times New Roman в качестве текущего, оператор moveto задает позицию вывода, оператор xshow предназначен для вывода текста с точным указанием позиции символов, а оператор showpage начинает печать страницы. Прямой вывод в порт Как упоминалось выше, низкоуровневые данные, сгенерированные драйвером принтера, передаются монитором порта драйверу порта ввода-вывода и в конечном итоге пересылаются на принтер. Монитор порта стандартными файловыми операциями Win32 открывает манипулятор для драйвера ввода-вывода и пере-
Знакомство со спулером 953 дает ему данные. Если приложение знает язык управления принтером, оно может сделать то же самое и общаться с принтером напрямую. Следующий фрагмент показывает, как передать файл в порт принтера. BOOL SendFile(HANDLE hOutput, const TCHAR * filename, bool bPrinter) { HANDLE hFile - CreateFile(filename. GENERIC_READ, FILE_SHARE_READ, NULL. OPENJXISTING. FILE_ATTRIBUTEJORMAL. NULL); if ( hFile==INVALID_HANDLE_VALUE ) return FALSE; char buffer[1024]: for (int size = GetFileSize(hFile. NULL); size; ) { DWORD dwRead « 0. dwWritten = 0; if ( ! ReadFile(hFile. buffer. min(size. sizeof(buffer)). & dwRead. NULL) ) break; if ( bPrinter ) WritePrinter(hOutput. buffer. dwRead. & dwWritten); else WriteFile(hOutput. buffer. dwRead. & dwWritten. NULL); size -= dwRead; } return TRUE; } void Demo_WritePort(void) { KFileDialog fd; if ( fd.GetOpenFileName(NULL. "prn". "Raw printer data") ) { HANDLE hPort - CreateFileClptl;", GENERIC_WRITE. FILE_SHARE_READ. NULL. OPENJXISTING. FILE_ATTRIBUTE_NORMAL. NULL); if ( hPort!=INVALID_HANDLE_VALUE ) { SendFile(hPort. fd.m_TitleName. false); CloseHandle(hPort); } } } Функция SendFile открывает манипулятор для входного файла и копирует блоки данных в выходной файл. Функция Demo_WritePort выводит диалоговое окно, в котором пользователь выбирает файл для передачи на принтер, создает манипулятор порта ввода-вывода и вызывает SendFile. Запись низкоуровневых данных на языке управления принтером часто требуется при адаптации DOS-программ, а также в приложениях, ограничиваю-
954 Глава 17. Печать щихся текстовым выводом или полагающих, что они справятся с работой лучше обычного драйвера принтера. Приложение также может сохранить низкоуровневые данные, сгенерированные драйвером принтера (печать в файл), загрузить их и передать прямо на принтер без участия GDI. В Windows NT/2000 порт LPT1: не соответствует обычному аппаратному порту, хотя вызов WriteFile проходит через ту же системную функцию, что и запись в настоящий порт. Утилиты типа WINOBJ (www.sysinternals.com) показывают, что LPT 1: представляет собой символическую ссылку на адрес Device\ NamedPipe\Spooler\LPTl. Оказывается, вывод все равно осуществляется под управлением спулера. Устройство, похожее на настоящий порт, называется NONSPOOLED_ LPT1 и представляет собой символическую ссылку на адрес \Device\ParallelO. Если спулер не работает (например, если он был завершен командой net stop spooler), попытки открыть LPT1: завершаются неудачей. Печать с использованием спулера Другой вариант вывода на принтер заключается в использовании API спулера. Win32 API включает богатый набор функций спулера, при помощи которых приложение может получить информацию о состоянии спулера, управлять заданиями печати, задавать параметры принтеров или передавать данные прямо на принтер. В приложениях Windows эти функции вызываются редко, поскольку доступ ко многим стандартным возможностям можно получить через стандартные диалоговые окна или приложение Printers (Принтеры) панели управления. По этой причине мы рассмотрим лишь некоторые функции спулера. BOOL OpenPrinterCLPTSTR pPrintName, LPHANDLE phPrinter, LPPRINTER_DEFAULTS pDefault): DWORD StartDocPrinter(HANDLE hPrinter, DWORD Level. LPBYTE pDodnfo); BOOL StartPagePrinter(HANDLE hPrinter); BOOL WritePrinter(HANDLE hPrinter, LPVOID pBuf. DWORD cbBuf. LPWORD pcWritten); BOOL EndPagePrinter(HANDLE hPrinter); BOOL EndDocPrinter(HANDLE hPrinter); BOOL ClosePrinter(HANDLE hPrinter); BOOL AbortPrinter(HANDLE hPrinter); Функция OpenPrinter получает имя принтера и указатель на структуру PRINTER_ DEFAULTS с параметрами по умолчанию, а возвращает манипулятор объекта принтера, поддерживаемого DLL спулера Win32. Обратите внимание: этот манипулятор не принадлежит ни к объектам ядра, ни к объектам GDI, поэтому он может использоваться только функциями спулера. В текущей реализации Windows NT/ 2000 манипулятор принтера представляет собой обычный указатель на адресное пространство пользовательского режима. Функция StartDocPrinter сообщает спулеру о появлении нового документа, который следует поставить в очередь печати. В последнем параметре этой функции передается указатель на структуру D0C_INF0_1 или D0C_INF0_2, определяющую название документа, имя выходного файла и тип данных для задания печати. DLL спулера создает новое задание печати функцией AddJob и файл спулинга в каталоге спулера. Функция StartDocPrinter используется в паре с функцией
Знакомство со спулером 955 EndDocPrinter, которая завершает задание печати, удаляет его из спулера и освобождает все выделенные ресурсы. Функция StartPagePrinter сообщает спулеру о начале новой страницы. После вызова этой функции приложение может передавать данные спулеру функцией WritePrinter. Каждому вызову StartPagePrinter должен соответствовать парный вызов EndPagePrinter, после которого начинается новая страница или завершается задание печати. Если произошла ошибка, задание печати можно отменить функцией Abort- Printer. Функции спулера экспортируются клиентской библиотекой DLL спулера Win32 winspool.drv, чтобы программы Windows могли взаимодействовать со спулером. Однако настоящая реализация спулера находится в отдельном системном процессе (spoolsv.exe). Клиентская библиотека DLL общается со спулером через механизм RPC. Например, функция StartPagePrinter вызывает RpcStartPagePrinter, которая в свою очередь вызывает NdrC1ientCan2. Функциями спулера можно воспользоваться и для отправки низкоуровневых данных на принтер. Впрочем, полная поддержка спулинга позволяет сделать много больше. Выражаясь точнее, вы можете передавать любые данные при условии, что они поддерживаются процессором печати, который отвечает за обработку данных. Для проверки форматов данных, поддерживаемых процессором печати для конкретного драйвера принтера, откройте окно свойств принтера и перейдите на вкладку Advanced (Дополнительно). На рис. 17.1 показано, какие форматы поддерживаются для стандартного процессора печати Windows 2000. Advanced * AvaSabi© ftone Гг 11<МХ1ЛМ ,f 2Ш ЗййкОД * differ^ р№ ргшж? may result to d#f <srer& epttom hm$ r*™ ■■■,, -v sjwtabl»fardtimfctUttto/pm*Ifywrтнкшdmwfcq*dfy$utafcyp* . Drfvac J HP DeskJet ^*1ШтЫ1т*ЛЫитй^ * % * * ^'^; Sport ^Ашш д/ \Г;8ш primal 4 ■■■■"■■■■■^■-■^--•^-■-■•■-■* r ■ PrlfKfc ргвсшоп ;,; Шшк datafyptt SFMPSPRT RAW [FF appended] RAW [FF auto] NT EMF 1,003 NT EMF 1.006 NT EMF 1,007 NT EMF 1,008 TEXT К^УЫщтЫШ\ху ^'\v; */л\'< "«<"'/,,, -,/, , t 4<J'f/J;_* л 'y*>-'J, Ap* un&M&ev&mxi ' *''. *..'.*'*..'.'<. ..?"*' : / ' ' ' ;:'' * l?ft^Dtf«tftfc„'Г 'Шиши**» ' BtiwatorFwfcM J *•'' tmmmtmmmmttm» w n щит mmmmmtmrnmimm щтт. mmmnnu mmmt ii4Niri-iii-i-iriiiiinn 1 i f? Рис. 17.1. Типы данных, поддерживаемые стандартным процессором печати Windows
956 Глава 17. Печать Как видно из рисунка, стандартный процессор печати Windows 2000 поддерживает три категории типов данных: низкоуровневые, текстовые и NT EMF. Хотя в списке присутствуют четыре версии NT EMF, точные спецификации и различия между ними не документированы. Также следует обратить внимание на то, что имя WinPrint не соответствует физической библиотеке DLL. Стандартный процессор печати Windows 2000 является частью локального процессора печати (localspi.dll), о чем свидетельствуют имена экспортируемых функций — такие, как PrintDocumentOnPrintProcessor. Небольшой эксперимент убедит всех скептиков в том, что документированный интерфейс API спулера благополучно справляется с EMF-файлами. Следующая функция иллюстрирует использование функций спулера с EMF-файлами. void Demo_WritePrinter(void) { PRINTDLG pd; memset(&pd. 0, sizeof(PRINTDLG)); pd.lStructSize = sizeof(PRINTDLG); if ( PrintDlg(&pd)==ID0K ) { HANDLE hPrinter; DEVM0DE * pDevMode = (DEVM0DE *) Global Lock(pd.hDevMode); PRINTER_DEFAULTS prn; prn.pDatatype = "NT EMF 1.008"; prn.pDevMode = pDevMode; prn.DesiredAccess = PRINTER_ACCESS_USE; if ( 0penPrinter((char *) pDevMode->dmDeviceName, & hPrinter, & prn) ) { KFileDialog fd; if ( fd.GetOpenFileName(NULL, "spl", "Windows 2000 EMF Spool file") ) { D0CJNF0J docinfo: docinfo.pDocName = "Testing WritePrinter"; docinfo.pOutputFile = NULL; docinfo.pDatatype = "NT EMF 1.008"; \StartDocPrinter(hPrinter, 1, (BYTE *) & docinfo); StartPagePrinter(hPrinter); SendFile(hPrinter. fd.m_TitleName, true); EndPagePrinter(hPrinter); EndDocPrinter(hPrinter); }
Знакомство со спулером 957 ClosePrinter(hPrinter); } if ( pd.hDevMode ) GlobalFree(pd.hDevMode); if ( pd.hDevNames ) GlobalFree(pd.hDevNames); } } Функция Demo_WritePrinter создает стандартное диалоговое окно для выбора принтера, на котором будет производиться печать. Если в диалоговом окне был выполнен щелчок на кнопке ОК, в структуру PRINTDLG заносится глобальный манипулятор блока структуры DEVM0DE, содержащей все параметры печати. Манипулятор DEVM0DE преобразуется в указатель и используется для заполнения полей структуры PRINTER_DEFAULTS, передаваемой функции OpenPrinter. Если вызов OpenPrinter прошел успешно, программа предлагает пользователю выбрать EMF- файл спулера Windows NT/2000. Затем функция вызывает StartDocPrinter, указывает тип данных «NT EMF 1.008» и пересылает содержимое EMF-файла функцией SendFile (см. выше). Если все прошло нормально, EMF-файл передается драйверу заданного принтера и выводится на печать. Ключом к успешной работе Demo_WritePrinter является правильный формат EMF-файла спулера. В главе 16, посвященной EMF, упоминались способы получения EMF-файла спулера — при помощи утилиты EMFScope в Windows 95/98 или команды сохранения файла спулера в Windows NT/2000. Также были представлены инструменты декодирования EMF-файлов вообще и EMF-файлов спулера в частности. Этот прием позволяет приложениям передавать низкоуровневые данные печати или данные спулинга в формате EMF на принтер без прямого участия GDI. В сочетании с возможностью получения EMF-файлов от спулера появляется возможность заново использовать файл спулера без запуска исходного приложения, создавшего этот файл. Это может пригодиться при построении универсальных средств обработки документов, обеспечивающих единый механизм обработки выходных данных разных приложений. Учтите, что EMF-файл спулера должен быть совместим с принтером, на котором вы печатаете, поскольку при построении EMF-файла спулера в качестве эталона выбирается контекст драйвера принтера. Также обратите внимание на то, что в функции Demo_WritePrinter используется структура DEVM0DE с текущими настройками принтера. Правильнее было бы извлечь структуру DEVM0DE из SHD-файла, сгенерированного вместе с EMF-фай- лом. Дело в том, что некоторые поля структуры DEVM0DE могут измениться с момента последнего построения EMF-файла. Рассмотрим маленькую схему, которая помогает лучше представить, как реализован спулинг EMF-файлов. Если при создании нового задания GDI решает, что спулинг.ЕМР разрешен, то новое задание спулера в формате EMF создается аналогичным способом. Для каждого вызова функции GDI данные записи EMF- файла передаются спулеру при помощи WritePrinter. Функция StartDoc GDI вызывает StartDocPrinter, функция StartPage вызывает StartPagePrinter и т. д., а вывод из очереди организуется процессором печати. Конечно, это всего лишь упрощенная концептуальная схема. Мы вернемся к диалоговым окнам принтера и структуре DEVM0DE при описании печати средствами GDI.
958 Глава 17. Печать Процессор печати EMF При передаче данных спулинга в формате EMF функцией WritePrinter возникает интересный вопрос: что же именно делает процессор печати EMF? В разделе «Архитектура системы печати» главы 2 этой книги приведено довольно подробное описание работы процессора печати в контексте архитектуры системы печати Windows. А сейчас мы в общих чертах познакомимся с тем, что же делает процессор печати Windows 2000. Процессор печати представляет собой настраиваемый компонент архитектуры системы печати Windows, который создавался с расчетом на будущее. До появления Windows 2000 процессор печати почти не использовался из-за ограниченности его возможностей. Когда процессор печати получал от спулера задание в формате EMF, он просто передавал его драйверу принтера функцией GdiPlayEMF (gdoPlaySpool Stream в Windows 95/98) GDI. Объявление функции GdiPlayEMF в Windows NT 4.0 выглядит следующим образом: B00L GdiPlayEMFCLPWSTR pwszPrinterName. LPDEVM0DEW pDevmode. ELPWSTR pwszDocName, EMFPLAYPR0C prnEMFPlayFn, HANDLE hPageQuery); Как видите, процессор печати получает только имя принтера, DEVM0DE и имя документа. Все, что он может, — вывести несколько экземпляров документа многократным вызовом GdiPlayEMF. Последние два параметра предназначены для избирательного воспроизведения отдельных страниц EMF, но в Windows NT 4.0 эта возможность не поддерживается. В Windows 2000 возможности процессора печати были расширены. Теперь он может управлять воспроизведением страниц EMF, объединять несколько логических страниц на одной физической странице, изменять порядок печати страниц в документе и даже применять преобразования к логическим страницам. С учетом этих усовершенствований процессор печати Windows 2000 позволяет выводить несколько страниц на одной физической странице, печатать страницы в обратном порядке, выводить несколько копий каждой страницы, печатать брошюры и контуры страниц. Все эти возможности реализуются централизованно и легко расширяются без модификации GDI и драйверов принтеров. Доступ к новым возможностям процессора печати открывают новые функции, экспортируемые GDI. Ниже приведены объявления трех важнейших функций. HANDLE GdiGetPageHandle(HANDLE SpoolFileHandle. DWORD Page. LPDW0RD pdwReserved); BOOL GdiPlayPageEMF(HANDLE SpoolFileHandle, HANDLE hEmf. RECT * prectDocument, RECT * prectBorder); HDC GdiGetDCCHANDLE SpoolFi1eHandle); Функция GdiGetPageHandle позволяет процессору печати получить манипулятор конкретной страницы в EMF-файле спулера. Напомню, что этот манипулятор не является ни манипулятором объекта GDI или ядра, ни указателем на графические данные EMF. Он всего лишь может использоваться функцией GdiPlayEMF для воспроизведения одной страницы через драйвер принтера. Параметр prectDocument позволяет масштабировать логическую страницу EMF в часть физической страницы для печати нескольких страниц на одном листе или вывода брошюры. Необязательный параметр prectBorder определяет прямоугольник внешнего
Знакомство со спулером 959 контура страницы и упрощает визуальную разметку нескольких логических страниц на одной физической странице. Функция GdiGetDC возвращает процессору печати нормальный манипулятор контекста устройства GDI, который может использоваться для применения мирового преобразования перед воспроизведением EMF. В результате применения мировых преобразований процессор печати может поворачивать или выполнять зеркальное отражение страниц. Пример исходного текста процессора печати EMF включен в Windows NT 4.0/ 2000 DDK (каталог src\print\genprint). Специальные функции GDI для работы с процессором печати EMF документированы в DDK. Возможно, у вас возник вопрос — как же работает функция GdiPlayPageEMF? Если несколько логических страниц могут печататься на одной физической странице, значит, отдельные страницы EMF не могут воспроизводиться в контексте устройства (особенно для драйверов принтеров, использующих поддержку GDI для разбиения на полосы), поскольку для этого понадобился бы дополнительный уровень построения и воспроизведения EMF. Функция GdiPlayPageEMF не воспроизводит EMF в контексте устройства принтера; вместо этого она всего лишь сохраняет новую логическую страницу во внутренней структуре данных GDI. Воспроизведение нескольких логических страниц начинается лишь с вызовом GdiPlayPageEMF. При выполнении GdiEndPageEMF в отладчике обнаруживается любопытная динамика печати в GDI. Чтобы проследить за работой GdiEndPageEMF, подключите отладчик к процессу спулера в диспетчере задач, для чего следует щелкнуть правой кнопкой мыши на имени процесса спулера и выбрать в контекстном меню команду Debug. После подключения к процессу спулера установите точку прерывания по адресу _GdiEndPageEMF@8 в модуле gdi32.dll. Теперь можно запустить задание печати. Выясняется, что GdiEndPageEMF вызывает функцию StartPage GDI и внутреннюю функцию StartBanding, после чего в цикле вызывает функции InternalGdiPlayPageEMF и NextBand. Функция InternalGdiPlayPageEMF настраивает мировое преобразование и вызывает интересную функцию PrintBand. Функция PrintBand вызывает системную функцию NtGdiGetPerBandlnfo, соответствующую документированной точке входа драйвера принтера и передающую GDI информацию об очередной полосе. Затем PrintBand вызывает функцию PlayEnhMetaFile, которая и воспроизводит EMF в контексте устройства драйвера принтера. Где-то в этой схеме должен присутствовать цикл перебора логических страниц на физической странице. Вероятно, теперь вы гораздо лучше понимаете, почему EMF отводится центральное место в системе печати, особенно в Windows 2000. Перечисление принтеров В спулерный интерфейс Win32 API входит функция EnumPrinter, при помощи которой приложение может получить список принтеров и запросить информацию о принтере. Функция EnumPrinter весьма сложна, она имеет большое количество параметров и возвращает разные типы структур. С ее помощью можно получить списки локальных принтеров, провайдеров печати, имен доменов, а также всех принтеров и серверов печати в домене. Функция EnumPrinter заполняет
960 Глава 17. Печать массивы структур от PRINTERINF01 до PRINTERINF05. Наиболее полная информация о принтере хранится в структуре PRINTERINF02, состоящей из 21 поля, в том числе из полей имени сервера, имени принтера, имени драйвера, DEVMODE, процессора печати, типа данных спулинга и т. д. За подробной информацией о EnumPrinter обращайтесь к MSDN. Ниже приведен пример функции, которая перечисляет все локальные принтеры и подключения к удаленным принтерам. void * EnumeratePrinters(DWORD flag, LPTSTR name, DWORD level, DWORD & nPrinters) { DWORD cbNeeded; nPrinters = 0; EnumPrintersCflag. name, level, NULL. 0, & cbNeeded. & nPrinters); BYTE * pPrnlnfo = new BYTE[cbNeeded]; if ( pPrnlnfo ) EnumPrinters(flag. name, level, (BYTE*) pPrnlnfo. cbNeeded. & cbNeeded. & nPrinters); return pPrnlnfo; } void ListPrintersCHWND hWnd, int message) { DWORD nPrinters; PRINTER_INF0_5 * pInfo5 = (PRINTER_INF0_5 *) EnumeratePrinters(PRINTER_ENUM_LOCAL, NULL, 5, nPrinters); if ( pInfo5 ) { for (unsigned i=0; i<nPrinters; i++) SendMessage(hWnd. message. 0, (LPARAM) pInfo5[i].pPrinterName); delete [] (BYTE *) pInfo5; PRINTERJNFOJ * plnfol - (PRINTERJNFOJ *) EnumeratePrinters(PRINTER_ENUM_CONNECTIONS. NULL. 1, nPrinters); if ( plnfol ) { for (unsigned i=0; i<nPrinters; i++) SendMessage(hWnd, message, 0. (LPARAM) pInfol[i].pName); delete [] (BYTE *) plnfol; Функция EnumeratePrinters представляет собой простую оболочку для Enum- Printers. Она управляет получением данных о размерах блока и выделением памяти. Функция ListPrinters сначала вызывает EnumeratePrinters для перечисления
Знакомство со спулером 961 локальных принтеров, а затем — для удаленных принтеров. Имена принтеров заносятся в список, в котором пользователь может выбрать нужный принтер. Перечисление принтеров позволяет приложениям конструировать нестандартные диалоговые окна печати. Например, стандартные диалоговые окна Windows могут оказаться неподходящими для игры или учебной программы, написанной для DirectX. Некоторые приложения должны предоставлять пользователю быстрый доступ к принтеру по умолчанию. Имя текущего принтера по умолчанию можно получить функцией GetDefaultPrinter, которая поддерживается только в Windows 2000. BOOL GetDefaultPrinter(LPTSTR pszBuffer, LPDWORD pcchBuffer); Получение информации о принтере По манипулятору принтера функция GetPrinter возвращает разнообразные сведения о принтере. Она может возвращать различные структуры от PRINTERINF01 до PRINTER_INF0_9. Приложение также может воспользоваться функцией DeviceCapabitilies и получить от интерфейсного модуля драйвера устройства сведения о лотках для подачи бумаги, поддержке печати по копиям, поддержке двусторонней печати, размере приватной части DEVMODE, допустимых размерах бумаги, скорости печати и т. д. За подробной информацией о функциях GetPrinter и DeviceCapabilities обращайтесь к MSDN. Настройка драйвера принтера Всевозможные параметры печати хранятся в структуре DEVMODE. Точнее говоря, структура DEVMODE используется всеми графическими устройствами для обмена информацией о конфигурации устройства между приложением, GDI и драйвером устройства. В частности, указатель на структуру DEVMODE передается в последнем параметре функций CreateDC и CreatelC. Впрочем, для принтеров структура DEVMODE играет более важную роль, чем для экранных устройств. Ниже приведено определение структуры DEVMODE. typedef struct _devicemode { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra: DWORD dmFields; union { struct { short dmOrientation; short dmPaperSize; short dmPaperLength: short dmPaperWidth; }: POINTL dmPosition; }:
962 Глава 17. Печать short dmScale: short dmCopies; short dmDefaultSource; short dmPrintQuality; short dmColor; short dmDuplex; short dmYResolution; short dmTTOption; short dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; union { DWORD dmDisplayFlags; DWORD dmNup; } DWORD dmDisplayFrequency: DWORD dmICMMethod: DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmReservedl: DWORD dmReserved2: DWORD dmPanningWidth: DWORD dmPanningHeight; } DEVMODE: Структура DEVMODE весьма сложна, что объясняется несколькими причинами. Она имеет переменный размер, зависящий от версии Windows, а интерпретация ее полей продолжает изменяться. После открытых полей структуры DEVMODE драйвер устройства может разместить дополнительные параметры, используемые во внутренней работе драйвера, поэтому приложение должно запросить размер структуры DEVMODE и выделить память из кучи (вместо того, чтобы предположить фиксированный размер структуры и создать ее в стеке). Поле dmDeviceName содержит «пользовательское» имя принтера, выводимое в приложении Printers (Принтеры) панели управления. Учтите, что заданное имя усекается до 32 символов. Поле dmSpecVersion определяет версию структуры DEVMODE. В файле wingdi.h определен макрос DM_SPECVERSION для обозначения текущей версии, в настоящее время равной 0x401. В поле dmDriverVersion хранится внутренняя версия драйвера, назначенная разработчиком драйвера. Например, для драйверов семейства UniDriver в Windows 2000 используется версия 0x500. Поле dmSize определяет размер открытой части структуры DEVMODE в байтах. При создании новой структуры DEVMODE ему следует присвоить значение sizeof(DEVMODE). Но если структура DEVMODE получена от внешнего источника, не следует предполагать, что значение dmSize совпадает с sizeof(DEVMODE), поскольку вы можете откомпилировать программу с новейшим заголовочным файлом Win32 и запустить ее на старом компьютере со старым драйвером, поддерживающим предыдущую версию DEVMODE (или наоборот). Поле dmDriverExtra задает размер блока, используемого драйвером устройства для хранения закрытых данных после от-
Знакомство со спулером 963 крытых полей DEVMODE. Если закрытые поля отсутствуют, полю присваивается 0. Общий объем памяти для хранения структуры DEVMODE равен dmSize +dmDriverExtra. Поле dmFields содержит информацию об инициализированных полях. Разным полям соответствуют разные флаги; например, флаг DM0RIENTATI0N относится к полю dmOrientation. В остальных полях DEVMODE хранятся в основном параметры устройства. Поле dmPrintQuality обычно определяет качество печати, которое существенно влияет на внешний вид напечатанных страниц, скорость, размер данных принтера и т. д. Качество печати обычно задается стандартными макросами DMRESHIGH, DMRES_ MEDIUM, DMRES_L0W и DMRESDRAFT. Драйвер принтера обычно сообщает GDI разные разрешения в зависимости от текущего значения поля dmPrintQuality, от чего зависит объем данных, получаемых им от GDI. Качество печати также влияет на воспроизведение графических команд драйвером принтера. Фактические значения этих макросов лежат в интервале от -4 до -1. Вместо этих значений драйвер принтера может присвоить полю dmPrintQuality фактически используемое разрешение (за подробностями обращайтесь к MSDN). Функция DocumentProperties заполняет структуру DEVMODE по имени и манипулятору принтера. LONG DocumentProperties(HDC hWND. HANDLE hPrinter, LPTSTR pDeviceName, PDEVMODE pDevModeOutput. PDEVMODE pDevModelnput. DWORD fMode); Последний параметр fMode определяет операцию, выполняемую функцией. Если fMode = 0, функция возвращает общий размер открытых и закрытых полей DEVMODE. Если fMode = DM_0UT_BUFFER, то структура, на которую указывает параметр pDevModeOutput, заполняется текущими параметрами DEVMODE заданного драйвера. Если fMode = DMINBUFFER, параметр pDevModelnput указывает на структуру DEVMODE с новыми значениями параметров. Если fMode = DM_IN_PR0MPT, функция выводит окно свойств принтера, в котором пользователь может изменить текущую конфигурацию. Следующая функция GetDEVMODE показывает, как использовать функцию DocumentProperties. DEVMODE * GetDEVMODE(TCHAR * PrinterName, int nPrompt) { HANDLE hPrinter; if ( !OpenPrinter(PrinterName. ShPrinter, NULL) ) return NULL; // Если последний параметр равен нулю. // функция возвращает необходимый размер буфера int nSize = DocumentProperties(NULL, hPrinter, PrinterName, NULL. NULL, 0); DEVMODE * pDevMode = (DEVMODE *) new char[nSize]; if ( pDevMode—NULL ) return NULL; // Обратиться к драйверу с запросом // на инициализацию структуры DEVMODE
964 Глава 17. Печать DocumentProperties(NULL, hPrinter. PrinterName, pDevMode. NULL, DM_OUT_BUFFER); // Вывести страницу свойств, чтобы пользователь // мог внести необходимые изменения BOOL rslt = TRUE; switch ( nPrompt ) { case 1: rslt = AdvancedDocumentProperties(NULL, hPrinter, PrinterName, pDevMode, pDevMode) == IDOK; break; case 2: rslt = ( DocumentProperties(NULL, hPrinter, PrinterName, pDevMode. pDevMode. DM_IN_PROMPT | DM_OUT_BUFFER | DM_IN_BUFFER ) — IDOK ): break; } ClosePrinter(hPrinter); if ( rslt ) return pDevMode; else { delete [] (BYTE *) pDevMode; return NULL; } } Работа функции GetDEVMODE начинается с вызова функции DocumentProperties, возвращающей реальный размер структуры DEVM0DE. После выделения памяти функция DocumentProperties вызывается снова для получения текущих настроек DEVM0DE, заданных пользователем в панели управления. Последний параметр GetDEVMODE указывает, следует ли предложить пользователю изменить настройки печати на странице свойств драйвера принтера или ограничиться окном дополнительных настроек (Advanced). Функция AdvancedDocumentProperties также поддерживается клиентской библиотекой DLL спулера Win32. Другая взаимосвязанная функция, PrinterProper- ties, выводит страницу свойств заданного принтера. На рис. 17.2 показаны примеры окон, вызванных функциями DocumentProperties, AdvancedDocumentProperties и PrinterProperties. Все окна, показанные на рисунке, реализуются интерфейсной библиотекой DLL драйвера принтера. В Windows 95/98 драйвер принтера представляет собой 16-разрядную библиотеку DLL, загружаемую 16-разрядным модулем gdi.exe GDI. Пользовательский интерфейс и базовый драйвер могут находиться в одной библиотеке DLL. В Windows NT 4.0 базовый драйвер принтера реализуется в виде DLL режима ядра, а пользовательский интерфейс сосредоточен в DLL пользовательского режима, поэтому они всегда находятся в разных библиотеках DLL. Хотя в Windows 2000 система допускает существование драйверов принте-
Базовая печать средствами GDI 965 ров пользовательского режима, интерфейсная библиотека DLL все равно должна существовать отдельно от базового драйвера. (ЖШвё*^:. Л^^йрРЙ РадазР^&кя*- [2 31 до HP DeskJet 895Cxi Advanced Documenl Settings "♦. L^ Paper/Output _+ jij Graphic C-] &$ Document Options A^W^F^^fafc»** [Enabled 3 Color Printing Mode tu .< i\i\u< ■; ^j Printer Features Print Mode <*: ч> > Print Quality \ст% «ход Nfr HP DeskJet 895Cxi Device Settings - ^5 Form To Tray Assignment Manual Paper Feed v-tr. Envelope, Manual Feed ч«»|- -33 Рис. 17.2. Окна настройки драйвера Реализация этих трех функций загружает интерфейсную библиотеку DLL в адресное пространство приложения для настройки параметров драйвера или свойств принтера. При этом загружаются и все используемые ей DLL. Загруженные библиотеки DLL обычно выгружаются перед выходом из этих функций. Похоже, в Windows 2000 предусмотрены какие-то меры оптимизации для простых запросов, но вывод страниц свойств по-прежнему сопровождается загрузкой десятка системных библиотек DLL. Базовая печать средствами GDI Функции спулера, описанные в предыдущем разделе, обеспечивают взаимодействие приложения со спулером и интерфейсными библиотеками DLL драйвера принтера. Обычно приложение производит настройку принтеров при помощи стандартных диалоговых окон, а для печати использует функции GDI. За кулисами стандартные диалоговые окна и GDI взаимодействуют со спулером и драйвером печати при помощи функций спулера. В этом разделе рассматривается базовая процедура создания заданий печати с использованием стандартных диалоговых окон и функций GDI. Стандартные диалоговые окна печати Стандартные диалоговые окна не относятся к числу основных средств Win32 API, поскольку все их возможности при желании можно имитировать другими
966 Глава 17. Печать функциями Win32. Однако эти окна определяют фактический стандарт пользовательского интерфейса для выполнения некоторых действий в операционной системе Windows. До настоящего момента мы рассмотрели стандартные окна для выбора цвета и шрифта, а также открытия/сохранения файла; все они были вполне удобными. Для печати в Windows предусмотрены два стандартных диалоговых окна — окно печати и окно параметров страницы. typedef struct tagPD { DWORD HWND HGLOBAL HGLOBAL HOC DWORD WORD WORD WORD WORD WORD HINSTANCE LPARAM LPPRINTHOOKPROC LPSETUPHOOKPROC LPCSTR LPCSTR HGLOBAL HGLOBAL PRINTDLG; IStructSize; hwndOwner; hDevMode; hDevNames; hDC; Flags; nFromPage; nToPage; nMinPage; nMaxPage; nCopies: hlnstance; ICustData; lpfnPrintHook; IpfnSetupHook; lpPrintTemplateName; IpSetupTemplateName; hPrintTemplate; hSetupTemplate; pedef struct tagPSD DWORD HWND HGLOBAL HGLOBAL DWORD POINT RECT RECT HINSTANCE LPARAM IStructSize; hwndOwner; hDevMode; hDevNames; Flags; ptPaperSize; rtMinMargin; rtMargin; hlnstance; ICustData; LPPAGESETUPHOOK 1pfnPageSetupHook; LPPAGEPAINTHOOK IpfnPagePaintHook; LPCSTR 1pPageSetupTemplateName; HGLOBAL hPageSetupTemplate; PAGESETUPDLG; BOOL PageSetupDlgCLPPAGESETUPDLG lppsd): Функция PrintDlg выводит стандартное диалоговое окно печати, в котором пользователь выбирает принтер, диапазон печатаемых страниц, количество копий, режим подбора по копиям, а также может вызвать страницы свойств принтера. Функция PageSetupDTg выводит стандартное окно параметров страницы, в котором пользователь выбирает размер бумаги, источник бумаги, ориентацию
Базовая печать средствами GDI 967 страницы и размеры полей. Функция PrintDlg также позволяет получить текущие настройки принтера по умолчанию без вывода диалогового окна; для этого при вызове ей передается флаг PDRETURNDEFAULT. На рис. 17.3 показано, как выглядят оба окна в Windows 2000. J№»^^-; мш «,„~ ~~. ,., -swwj&l & яь ^ \ Add Printer HP 8500 HPDJ970C HP Plotter №Ш PS t*0m~*- ~3 J №***«?«*&* f3 *§* ; p Cefet* ^ I рдоаддо, For: W* , $омщ ]Automatically Select -3 1 h Г Un&cup* ; Tqjsi [1 ft*** |1 Рис. 17.3. Стандартные диалоговые окна печати и параметров страницы в Windows 2000 Функция PrintDlg использует структуру PRINTDLG для получения параметров от приложения, возврата результатов приложению и настройки внешнего вида окна. В поле hDevMode хранится глобальный манипулятор структуры DEVM0DE, содержащей параметры печати. Поле hDevNames содержит глобальный манипулятор структуры DEVNAMES, содержащей имена драйвера принтера, устройства и порта вывода. Глобальные манипуляторы (а точнее, манипуляторы глобальных блоков памяти) были унаследованы от Win 16 API, где все задачи в системе работали в общем адресном пространстве. Глобальный манипулятор используется для ссылок на блок памяти, выделенный из глобальной кучи. В результате дефрагмен- тации и освобождения места для больших блоков такие блоки памяти могли перемещаться в куче, поэтому их приходилось фиксировать функцией Global Lock, возвращавшей дальний указатель на блок, и освобождать функцией Global Unlock. В Win32 API поддержка глобальных манипуляторов была сохранена только для того, чтобы упростить адаптацию 16-разрядных приложений. Впрочем, и в программах Win32 манипулятор глобального блока памяти и указатель на этот блок — совершенно разные вещи. Чтобы преобразовать манипулятор глобального блока в указатель на блок данных, следует вызвать функцию Global Lock. Впрочем, манипуляторы ресурсов имеют те же значения, что и соответствующие указатели. Поле hDC структуры PRINTDLG содержит манипулятор контекста устройства GDI или информационного контекста, созданный и возвращенный функций PrintDlg
968 Глава 17. Печать при передаче флага PDRETURNDC или PDRETURNIC. Поле Flags управляет интерпретацией входных данных структуры и построением выходных данных. Следующие четыре поля — nFromPage, nToPage, nMinPage и пМахРаде — управляют настройкой диапазона печатаемых страниц (см. левый нижний угол диалогового окна печати) — весьма удобная возможность для приложений, поддерживающих многостраничные документы. Поле nCopies задает количество копий. Остальные поля PRINTDLG предназначены для настройки диалогового окна печати: Программы с модифицированными окнами печати встречаются довольно часто. Например, программа бухгалтерского учета может поддерживать режим печати по интервалам дат вместо страниц. За подробным описанием структур PRINTDLG обращайтесь к MSDN. Функция PageSetupDlg использует аналогичную структуру PAGESETUP для получения параметров от приложения, возврата результатов приложению и настройки внешнего вида окна. Поля hDevMode и hDevNames структуры PAGESETUP имеют тот же смысл, что и в структуре PRINTDLG. Поле Flags также содержит десятки всевозможных флагов, управляющих работой PageSetupDlg. Главная информация PAGESETUP содержится в полях ptPageSize, rtMinMargin и rtMargin. Поле rtMinMargin задает минимальный размер полей при печати листа. Вследствие физических ограничений, обусловленных конструкцией принтера, на всех четырех сторонах листа имеются области, печать в которых невозможна. Поле rtMargin задает текущие поля, введенные пользователем в диалоговом окне, которые должны быть не меньше rtMinMargin. Ориентация листа сопровождается сменой горизонтальных и вертикальных метрик, а также отражается в структуре DEVM0DE. Данные, возвращаемые функциями PrintDlg и PageSetupDlg, чрезвычайно важны — по ним приложение форматирует документ для печати. Следовательно, они должны использовать одни и те же манипуляторы DEVM0DE и DEVNAMES, чтобы обеспечить согласованность настроек. Приложение также должно поддерживать настройку параметров печати на уровне документа, чтобы их можно было сохранить вместе с документом и восстановить при загрузке. Некоторые приложения предлагают пользователю выбрать принтер перед созданием документа. Многие приложения обращаются с запросом к драйверу принтера, чтобы синхронизировать параметры печати при загрузке документа. В листинге 17.1 приведено объявление и часть реализации класса KOutput- Setup, инкапсулирующего функции PrintDlg и PageSetupDlg. Листинг 17.1. Объявление и часть реализации класса KOutputSetup class KOutputSetup { PRINTDLG m_pd; PAGESETUPDLG m_psd; void Release(void); public: KOutputSetup(void); -KOutputSetup(void); void DeletePrinterDC(void); void SetDefaultCHWND hwndOwner, int minpage, int maxpage);
Базовая печать средствами GDI 969 int PrintDialogCDWORD flag): BOOL PageSetup(DWORD flag): void GetPaperSizeCPOINT & p) const p = m_psd.ptPaperSize: void GetMargin(RECT & rect) const rect = m_psd.rtMargin; void GetMinMargin(RECT & rect) const rect = m_psd.rtMinMargin; HDC GetPrinterDC(void) const return m_pd.hDC: DEVMODE * GetDevMode(void) return (DEVMODE *) GlobalLock(m_pd.hDevMode); const TCHAR * GetDriverName(void) const const TCHAR * GetDeviceName(void) const const TCHAR * GetOutputName(void) const HDC CreatePrinterDC(void): KOutputSetup::KOutputSetup(void) { memset (&m_pd. 0. sizeof(PRINTDLG)); m_pd.lStructSize = sizeof(PRINTDLG): memset(& m_psd, 0, sizeof(m_psd)); m_psd.lStructSize = sizeof(m_psd): } void KOutputSetup::SetDefault(HWND hwndOwner, int minpage, int maxpage) { m_pd.hwndOwner = hwndOwner: PrintDialog(PD_RETURNDEFAULT); m_pd.nFromPage = minpage; m_pd.nToPage = maxpage: m_pd.nMinPage = minpage: m_pd.nMaxPage = maxpage: m_psd.hwndOwner = hwndOwner; m_psd.rtMargin.left - 1250; // 1,25 дюйма m_psd.rtMargin.right = 1250; // 1,25 дюйма m_psd.rtMargin.top = 1000; // 1.25 дюйма m psd.rtMargin.bottom= 1000; // 1,25 дюйма Продолжение ^>
970 Глава 17. Печать Листинг 17.1. Продолжение HDC hDC = CreatePrinterDCO: int dpix = GetDeviceCaps(hDC, LOGPIXELSX); int dpiy = GetDeviceCaps(hDC. LOGPIXELSY); m_psd.ptPaperSize.x = GetDeviceCaps(hDC. PHYSICALWIDTH) * 1000 / dpix; m_psd.ptPaperSize.y = GetDeviceCaps(hDC. PHYSICALHEIGHT) * 1000 / dpiy; m_psd.rtMinMargin.left - GetDeviceCaps(hDC. PHYSICALOFFSETX) * 1000 / dpix; m_psd.rtMinMargin.top = GetDeviceCaps(hDC. PHYSICALOFFSETY) * 1000 / dpiy; m_psd.rtMinMargin.right = m_psd.ptPaperSize.x - m_psd.rtMinMargin.left - GetDeviceCaps(hDC. H0RZRES) * 1000 / dpix; m_psd.rtMinMargin.bottom= m_psd.ptPaperSize.y - m_psd.rtMinMargin.top - GetDeviceCaps(hDC. VERTRES) * 1000 / dpiy; DeleteObject(hDC); } int K0utputSetup:;PrintDialog(DW0RD flag) { m_pd.Flags = flag; return PrintDlg(&m_pd); } BOOL K0utputSetup;:PageSetup(DW0RD flag) { m_psd.hDevMode - m_pd.hDevMode; rn_psd. hDevNames = m_pd. hDevNames; m_psd.Flags = flag | PSD_INTHOUSANDTHSOFINCHES | PSD_MARGINS; return PageSetupDlg(& m_psd); } Класс KOutputSetup напоминает классы CPrintDialog и CPageSetupDialog MFC, слитые воедино. Конструктор просто инициализирует переменные m_pd (структура PRINTDLG) и m_psd (структура PAGESETUPDLG). Метод SetDefault присваивает значения нескольким важным полям без вывода диалогового окна. Для m_pd вызов PrintDlg с флагом PDRETURNDEFAULT возвращает манипуляторы DEVM0DE и DEVNAMES. Поля выбора страниц заполняются по значениям параметров SetDefault. По умолчанию размеры полей равны 1,25 дюйма для левого и правого поля и 1 дюйм для верхнего и нижнего поля. Минимальные размеры полей вычисляются с учетом физических размеров листа, печатных размеров листа и физических смещений; все эти данные возвращаются функцией GetDeviceCaps с соответствующим индексом. Размеры бумаги, возвращаемые при передаче индексов PHYSICALWIDTH и PHYSICALHEIGHT, определяют физические размеры; так, при разрешении 300 dpi размер листа формата Letter (8,5 х 11 дюймов) в пикселах равен 2250 х 3300. Размеры печатной части листа, возвращаемые при передаче индексов H0RZRES и VERTRES, определяют размеры печатной области в центре листа. Физические смещения (индексы PHYSICALOFFSETX и PHYSICALOFFSETY) определяют размеры верхних и нижних полей. На рис. 17.4 показан смысл шести метрик, возвращаемых функцией GetDeviceCaps.
Базовая печать средствами GDI 971 PHYSICAL-WIDTH PHYSICALHEIGHT PHYSICALOFFSETY <— PHYSICALOFFSETX HORZRES VERTRES Рис. 17.4. Размеры бумаги, возвращаемые функцией GetDeviceCaps Метод PrintDialog вызывает функцию PrintDlg, реализованную модулем стандартных диалоговых окон. Метод PageSetup вызывает функцию PageSetupDlg с теми же манипуляторами DEVMODE и DEVNAMES, которые используются при вызове PrintDlg; это обеспечивает синхронизацию их значений. Создание контекста устройства принтера Функция PrintDlg (а следовательно, и класс KOutputSetup) может вернуть контекст устройства принтера, позволяющий организовать вывод на печать средствами GDI. Для этого при вызове PrintDlg передается флаг PD_RETURNDC. Рассмотрим простой пример: void Demo_0utputSetup(boo1 bShowDialog) { KOutputSetup setup; DWORD flags - PD_RETURNDC; if ( ! bShowDialog ) flags |= PD_RETURNDEFAULT; if ( setup.PrintDialog(flags)==IDOK ) { HDC hDC - setup.GetPrinterDCO; // Использовать DC принтера
972 Глава 17. Печать Если флаг bShowDialog равен TRUE, на экран выводится диалоговое окно для настройки принтера; в противном случае используются текущие параметры. В обоих случаях возвращается манипулятор контекста устройства принтера, который может использоваться программой, и манипуляторы структур DEVM0DE и DEVNAMES. Все эти ресурсы освобождаются деструктором класса KOutputSetup. В общем, не происходит ничего особенного — контекст устройства принтера создается хорошо знакомой функцией CreateDC. Вспомните, что функция CreateDC получает четыре параметра: имя драйвера, имя устройства, имя порта/файла вывода и указатель на структуру DEVM0DE. Прототип CreateDC унаследован от Win 16 API, где графический драйвер представлял собой загружаемую 16-разрядную библиотеку DLL. В приложениях Win32 приложения уже не могут напрямую обращаться к драйверу графического устройства. Все параметры, необходимые для вызова CreateDC, хранятся в структуре PRINTDLG. Имена драйвера, устройства и порта вывода содержатся в структурах DEVM0DE и DEVNAMES. Приведенный ниже метод KOutputSetup: :CreatePrinterDC создает контекст устройства для принтера по манипуляторам DEVM0DE и DEVNAMES. HDC KOutputSetup::CreatePrinterDC(void) { return CreateDCCNULL. GetDeviceNameO. NULL, GetDevModeO); } const TCHAR * KOutputSetup::GetDeviceName(void) const { const DEVNAMES * pDevNames = (DEVNAMES *) Global Lock(m_pd.hDevNames): if ( pDevNames ) return (const TCHAR *) ( (const char *) pDevNames + pDevNames->wDeviceOffset ): else return NULL: } Методы GetDriverName, GetDeviceName и GetOutputName берут имена драйвера, устройства и порта вывода из структуры DEVNAMES. Типичными значениями являются «winspool», имя устройства и «lptl:». winspool.drv — клиентская библиотека DLL спулера Win32, предоставляющая все функции спулера приложениям Win32. Для создания контекста устройства принтера абсолютно необходим только один параметр — имя устройства. Имя драйвера подставляется автоматически; без имени порта вывода можно обойтись, поскольку оно передается GDI при вызове StartDoc; указатель на DEVM0DE тоже необязателен. Если вместо указателя на DEVM0DE передается NULL, драйвер принтера использует текущие настройки принтера, заданные в панели управления. Чтобы создать контекст устройства с нестандартными параметрами, необходимо передать правильно заполненную структуру DEVM0DE. Самый простой способ создания контекста устройства принтера в Windows 2000 без стандартных диалоговых окон печати заключается в использовании GetDefaultPrinter и CreateDC. В следующем фрагменте создается контекст устройства для текущего принтера по умолчанию со стандартными параметрами: TCHAR PrinterName[64]; DWORD Size - 64;
Базовая печать средствами GDI 973 GetDefaultPrinter(PrinterName, & Size); HDC hDC = CreateDC(NULL PrinterName, NULL. NULL); // Использовать DC принтера DeleteDC(hDC); При создании контекста устройства также можно запросить список принтеров, получить стандартную структуру DEVMODE, изменить ее и создать контекст устройства с именем принтера и настройками по вашему выбору. Получение информации о контексте устройства принтера Получив манипулятор контекста устройства «принтер», вы можете получить информацию о контексте функцией GetDeviceCaps. Вызов GetDeviceCaps с индексом TECHNOLOGY позволяет узнать тип принтера. Для плоттеров возвращается значение DT_PLOTTER, а для любых растровых принтеров и даже принтеров PostScript возвращается DTRASTPR INTER. Учтите, что некоторые плоттеры нового поколения тоже используют растровую технологию вместо традиционного набора из 8 перьев. При передаче индексов LOGPIXELSX и LOGPIXELSY функция возвращает разрешение принтера — важный показатель, используемый приложениями при настройке логического контекста устройства. В отличие от экранных устройств, которые при помощи логического разрешения увеличивают изображение на экране для удобства просмотра, на бумаге один дюйм всегда соответствует ровно одному дюйму. Впрочем, необходимо помнить о некоторых обстоятельствах, относящихся к разрешению принтера. О Разрешение принтера зависит от выбранного качества печати. Драйвер принтера может сообщать GDI разные значения — 1200 х 1200 dpi, 600 х 600 dpi или 300 х 300 dpi — в зависимости от качества печати и типа носителя в структуре DEVMODE. О Лист со всех четырех сторон ограничен полями (см. рис. 17.4). Вызовы GetDeviceCaps с индексами H0RZRES и VERTRES возвращают ширину и высоту не всего листа, а его печатной области. О Драйвер принтера или микропрограммное обеспечение принтера может перевести данные, полученные от GDI, в более высокое разрешение, чтобы улучшить качество печати. Например, драйвер принтера может сообщить GDI разрешение 1200 х 1200 dpi и масштабировать данные до разрешения 2400 х 1200 dpi. О Разрешение является важным, но не единственным фактором, влияющим на качество печати. Также приходится учитывать качество исходных данных, алгоритмы полутоновой обработки/смешения цветов, разрядность каждого цветового канала, механическую точность, химический состав чернил, регулировку цвета в зависимости от типа носителя и т. д. О В Windows 95/98 из-за ограничений 16-разрядной версии GDI увеличение разрешения приводит к уменьшению максимального размера бумаги. Например, если драйвер сообщает о поддержке разрешения 1200 dpi, максимальные
974 Глава 17. Печать размеры бумаги равны 32 767 пикселов (27,3 дюйма), а если разрешение увеличивается до 2400 dpi, максимальные размеры сокращаются до 13,65 дюйма. Индексы BITSPIXEL, PLANES, SIZEPALETTE и NUMC0L0RS позволяют определить формат палитры и пикселов устройства. Впрочем, вам вряд ли удастся найти драйвер принтера с поддержкой палитры. Индексы CLIPCAPS, RASTERCAPS, CURVECAPS, LINECAPS, P0LYG0NALCAPS и TEXTCAPS, относящиеся к поддержке примитивов DDI со стороны драйвера устройства, не играют особой роли для приложений в системах семейства NT. В этих системах графический механизм гораздо лучше справляется с поддержкой вывода в стандартном кадровом буфере формата DIB и разбиением команд GDI на примитивы. Скорее, эти атрибуты используются графическим механизмом для получения информации о драйвере принтера. Впрочем, если у вас возникнут проблемы с конкретным драйвером принтера — проверьте значения этих атрибутов. Возможно, это поможет вам в процессе диагностики. В Windows 98/2000 добавились новые индексы SHADEBLENDCAPS и C0L0RMGMCAPS для проверки возможностей устройства по поддержке градиентных заливок, альфа-наложения и управления цветом. При помощи функций GDI также можно перечислить шрифты, поддерживаемые принтером. Современные принтеры часто поддерживают шрифты, недоступные для драйвера экрана. На рис. 17.5 показаны атрибуты контекста устройства принтера, полученные при помощи функции GetDeviceCaps и взятые из структуры PRINTERI NF0_2, заполненной при вызове GetPrinter. Для сбора информации использовалась несколько измененная версия программы Device из главы 5. vVtf ъ/9 &•& ''' *4 ф '« / ' ' ' Oavbe Hm&< rm\mmjnmjt ГЙвй 1 Driver Name Printer Name Share Name Port Name Driver Name Comment Location Separator Page Print Processor JHPDJ970C *_—^ : Values HP DeskJet 970C Series HP DJ370C LPTV HP DeskJet 970C Series WmPrint ОС» w -ill TECHNOLOGY DRIVERVERSION HORZSIZE VERTSIZE HORZRES VERTRES LOGPIXELSX L0GPIXELSY BITSPIXEL PLANES NUMBRUSHES NUMPENS NUMMARKERS NUMF0NTS NUMC0L0RS PDEVICESIZE CURVECAPS LINECAPS ii::;::::;::::i; i Value 2 0x4005 203 mm 265 mm 2400 pixels 3141 pixels 300 dpi 300 dpi 24 bits 1 planes -1 5000 0 0 1000 0 0x1 ff Oxfe . * 1 , j 4 1 —J A J jt ж Рис. 17.5. Информация о контексте устройства принтера, возвращаемая функцией GetDeviceCaps
Базовая печать средствами GDI 975 Последовательность формирования заданий печати После настройки контекста устройства принтера можно переходить к построению задания печати средствами GDI. В GDI предусмотрены специальные функции для логической группировки команд GDI при построении заданий печати. typedef struct { int cbSize; LPCTSTR IpszDocName; LPCTSTR IpszOutput; LPCTSTR lpszDataType; DWORD fwType; } DOCINFO: int StartDoc(HDC hDC. CONST DOCINFO * Ipdi); int StartPage(HDC hDC); int EndPage(HDC hDC); int EndDoc(HDC hDC); HDC ResetDC(HDC hDC. const DEVMODE * IpInitData); int AbortDoc(HDC hDC); int SetAbortProc(HDC hdc. ABORTPROC IpAbortProc); Функция StartDoc сообщает GDI о начале нового задания печати. Структура DOCINFO, передаваемая при вызове StartDoc, содержит важнейшие сведения о задании, используемые GDI и спулером. В поле IpszDocName хранится имя документа, выводимое в диспетчере печати. Многие приложения включают в эту строку название приложения в формате <имя_приложения> - <имя_документа>. Поле 1 pszOutput содержит имя выходного устройства, которое получает данные, сгенерированные драйвером принтера. Изменяя значение этого поля, можно направить результаты вывода в файл вместо физического порта. Поле IpszDatatype содержит тип данных спулинга, рекомендуемый приложением; GDI и драйвер устройства могут игнорировать значение этого поля. Например, для применения особых возможностей Windows 2000 (скажем, печати нескольких страниц на листе) необходим спулинг в формате EMF, поэтому GDI может выбрать EMF-спулинг даже в том случае, если приложение запрашивает спулинг в низкоуровневом формате. Последнее поле содержит некоторые редкие флаги, используемые GDI и драйвером принтера. Флаг DI_APPBANDING сообщает, что разбиение страниц на полосы выполняется приложением; как упоминалось выше, GDI достаточно хорошо справляется с разбиением. Флаг DI_R0PS__READ_DESTINATI0N указывает, что приложение использует растровую операцию, читающую содержимое приемной поверхности. Растровые принтеры, у которых изображение строится на управляющем компьютере, обычно легко поддерживают любые растровые операции, но у принтеров PostScript поддержка операций, связанных с чтением с приемной поверхности, может вызвать затруднения. В Windows 95 флаг DI_R0PS_READ_DESTINATI0N фактически исключает спулинг в формате EMF. Функция StartPage начинает новую страницу задания печати, а функция EndPage завершает ее. Механизм работы спулера требует, чтобы весь вывод GDI четко делился на страницы. Графические команды не должны вызываться ни перед первым вызовом StartPage, ни между вызовами EndPage и StartPage. Из-за нетриви-
976 Глава 17. Печать альных возможностей вывода документов, реализованных в процессоре печати и драйвере принтера, StartPage и EndPage определяют только логические страницы, которые при выводе могут переставляться, разбиваться на листы или наоборот, выводиться по несколько страниц на одном физическом листе. Обычно страница выводится лишь после вызова EndPage. Это объясняется природой механизма спулинга и тем фактом, что команды GDI могут осуществлять вывод в любом месте страницы, поэтому драйвер принтера сначала получает все команды вывода для страницы и лишь потом выбирает, как действовать дальше. На этот процесс может влиять настройка спулера и особых возможностей вывода. Например, у спулера есть режим, при выборе которого печать начинается лишь после постановки в очередь последней страницы. Последнюю страницу приходится ожидать и при печати в обратном порядке, в режиме печати брошюр или двусторонней печати. При печати нескольких страниц на одном листе приходится ждать, пока в очередь будут поставлены все выводимые страницы. Функция EndDoc завершает задание печати, созданное функцией StartDoc. Вспомните, что при создании контекста устройства принтера обычно передается структура DEVM0DE со всеми необходимыми параметрами. Эти параметры можно изменять между страницами функцией ResetDC. Функции ResetDC передается манипулятор контекста устройства и указатель на новую, вероятно, измененную структуру DEVM0DE. При помощи этой функции приложение может изменить размер бумаги, ее ориентацию или другие параметры. Например, Microsoft Word позволяет выводить каждую страницу с новым размером, ориентацией и т. д. Функция AbortDoc предназначена для аварийного завершения задания печати и отмены вывода тех частей, которые еще не напечатаны. Функция SetAbortProc назначает функцию косвенного вызова, которая периодически вызывается GDI для проверки того, не следует ли отменить задание печати. Обычно эта функция используется средствами отмены печати в приложениях. В листинге 17.2 приведен несложный, но вполне реальный пример, демонстрирующий процесс формирования заданий печати в GDI. Листинг 17.2. Формирование заданий печати средствами GDI int nCall_AbortProc; BOOL CALLBACK SimpleAbortProc(HDC hDC, int iError) { nCall_AbortProc ++; return TRUE; } void SimplePrint(int nPages) { TCHAR temp[MAX_PATH]; DWORD size - MAX_PATH; GetDefaultPrinter(temp. & size); // Имя принтера по умолчанию HDC hDC = CreateDC(NULL. temp, NULL, NULL); // DC с параметрами по умолчанию
Базовая печать средствами GDI 977 if ( hDC ) { nCall_AbortProc - 0; SetAbortProc(hDC, SimpleAbortProc); DOCINFO docinfo; docinfo.cbSize = sizeof(docinfo); docinfo.IpszDocName = _T("SimplePrint"); docinfo.IpszOutput = NULL; docinfo.IpszDatatype = _T("EMF"); docinfo.fwType = 0; if ( StartDoc(hDC. & docinfo) > 0 ) { for (int p=0; p<nPages; p++) // По одной странице if ( StartPage(hDC) <« 0 ) break; else { int width - GetDeviceCaps(hDC. HORZRES); int height - GetDeviceCaps(hDC, VERTRES): int dpix - GetDeviceCaps(hDC, LOGPIXELSX); int dpiy - GetDeviceCaps(hDC, LOGPIXELSY); wsprintf(temp, _T("Page %6 of %6"). p+1. nPages); SetTextAlign(hDC. TAJOP | TA_RIGHT ); TextOut(hDC, width. 0, temp. _tcslen(temp)); Rectangle(hDC. 0. 0. dpix. dpiy); Rectangle(hDC. width, height, width-dpix. height-dpiy); if ( EndPage(hDC)<0 ) break; } EndDoc(hDC); } DeleteDC(hDC); } wsprintf(temp, "AbortProc called %6 times". nCall_AbortProc); MessageBoxCNULL. temp. "SimlePrint". MB_OK); } Функция SimplePrint организует простой цикл постраничной печати. Сначала она запрашивает имя принтера по умолчанию, создает контекст устройства, назначает функцию отмены печати и начинает вывод функцией StartDoc. Если все идет нормально, SimplePrint в цикле последовательно печатает все страницы. Все команды вывода находятся между вызовами StartPage и EndPage. Для каждой страницы функция запрашивает размер печатной области и разрешение, рисует квадрат со стороной 1 дюйм в левом верхнем и правом нижнем углах страницы и выводит номер страницы в правом верхнем углу. Обратите внимание: для контекста устройства принтера точка (0,0) в системе координат устройства (совпадает с точкой (0,0) в логической системе координат в режиме отображения ММТЕХТ) совмещается с первым печатным пиксе-
978 Глава 17. Печать лом страницы, а не просто с первым пикселом. Следовательно, ее расстояние от левого верхнего угла листа определяется величиной полей, возвращаемых функциями GetDeviceCaps(hDC, PHYSICALOFFSETX) и GetDeviceCapsChDC, PHYSICALOFFSETY). Иначе говоря, точное расположение вывода листинга 17.2 зависит от параметров устройства и шрифта, используемого при выводе текста, поскольку функция не выбирает собственный логический шрифт. По результатам, выведенным функцией SimplePrint, можно оценить размер печатной области и посмотреть, соответствует ли логический дюйм физическому. При выводе нескольких страниц их фактический порядок также учитывает другие параметры печати (например, печать в обратном порядке). В завершение своей работы SimplePrint выводит диалоговое окно, в котором приводится количество вызовов функции отмены печати. Возможно, вас удивит тот факт, что иногда эта функция не вызывается вообще, а иногда вызывается только раз на страницу. Впрочем, функция отмены печати постепенно утрачивает свое значение в новых версиях операционных систем из-за спулинга EMF и в приложениях Win32 из-за улучшенной поддержки многозадачности и многопо- точности. Поддержка печати в программах Используя функции GDI и спулера, описанные в двух предыдущих разделах, вы сможете найти принтер, настроить его, начать и завершить задание печати. Весь непосредственный вывод зависит только от ваших навыков обращения с базовыми графическими примитивами GDI. Тема вроде бы исчерпана, и мы можем двигаться дальше. Однако в реальных приложениях Windows с печатью возникает немало проблем, поскольку нигде толком не описано, как же реализуются сколько-нибудь нетривиальные возможности печати. Возможно, лучшим источником информации является система поддержки печати MFG, реализованная в архитектуре «документ/представление». Задачи, возникающие при поддержке печати в программе, делятся на несколько категорий. Нередко они оказывают влияние и на общую архитектуру программы. В этом разделе мы разработаем несколько классов, реализующих общие возможности печати в программе, в том числе поддержку единой логической системы • координат, изменения масштаба, разметки печатной страницы на экране, установки полей, вывода многостраничных документов, а также печати нескольких страниц на одном листе. В следующих двух разделах приводятся более завершенные примеры программ, предназначенных для вывода листингов с выделением синтаксических конструкций и печати фотоизображений. Единая логическая система координат В приведенных выше программах использовался режим отображения MMJTEXT, в котором преобразование из логической системы координат в координаты устройства является почти тождественным (не считая возможного смещения). Команды вывода в режиме ММ_ТЕХТ не удается легко использовать для вывода как
Поддержка печати в программах 979 на экран, так и на принтер, поскольку высокое разрешение принтера зависит от устройства и даже от текущих настроек печати. Более правильное решение заключается в выборе логической системы координат с физическими единицами (например, дюймами или миллиметрами). В GDI существует несколько стандартных режимов отображения — MM_LOENGLISH, MM_LOMETRIC, MMTWIPS и т. д. Во многих профессиональных приложениях пользователь выбирает масштаб вывода на экран. Например, Microsoft Word позволяет изменять масштаб от 500 до 10 % от логического разрешения, не говоря уже об изменении ширины, выводе всей страницы вместе с полями и режиме размещения двух страниц. Наконец, в режиме предварительного просмотра (Print Preview) функция вывода масштабирует изображение по размерам окна. Следовательно, стандартные режимы отображения исключаются. Остается единственный вариант — определить собственный режим отображения, используя наиболее общий режим MM_ANIS0TR0PIC. Ниже перечислены основные требования к такому режиму. О Единая логическая система координат. Количество единиц для представления физической единицы измерения в логической системе координат должно быть фиксированной величиной. Допустим, вы решаете, что один дюйм в логической системе координат всегда представляется 300 единицами независимо от масштаба вывода и устройства. При этом вы получаете один фрагмент графического кода, не содержащий внешних ссылок вида GetDevice- Caps(hDC, L0GPIXELS). О Поддержка масштабирования от 500 до 10 %. О Поддержка распространенных размеров носителей даже при работе в Windows 95/98. Точнее говоря, максимальный размер носителя должен составлять 43 см (17 дюймов). О Поддержка основных логических разрешений вывода без ошибок округления. При таких ограничениях нетрудно вычислить, что же мы можем сделать. Самые распространенные логические разрешения составляют 96 dpi (мелкий шрифт), 120 dpi (крупный шрифт), 360 и 600 dpi для принтеров. Наименьшее общее кратное 96, 120, 360 и 600 равно 7200. Умножая 7200 на 17 дюймов, мы получаем 122 400, что значительно больше максимальных размеров поверхности устройства в Windows 95/98 (32 767). В нашем распоряжении только числа, меньшие 1927 (32 767/17). Наименьшее общее кратное 96 и 120 равно 480; это число укладывается в отведенные границы. Наименьшее общее кратное 96,120 и 360 равно 1440, что тоже не превышает максимума. Следовательно, разумнее всего выбрать 1440 dpi — такое же логическое разрешение используется в режиме отображения MMJTWIPS. Максимальное разрешение экрана равно 120 dpi для режима крупного шрифта. Умножая 120 dpi на 500 %, мы получаем 600 dpi, что составляет примерно треть от 1927. Итак, если выбрать для нашей логической системы координат разрешение 1440 dpi, это позволит нам представить область размером до 22,75 х 22,75 дюйма, которую можно вывести в масштабе 1500 % на экране с разрешением 120 dpi, не нарушая ограничений 16-разрядной версии GDI в Windows 95/98. Главное преимущество разрешения 1440 dpi заключается в том, что оно позволяет приложению точно адресовать любые пикселы координатного пространства
980 Глава 17. Печать для графических устройств с разрешениями 96, 120 и 360 dpi без погрешностей округления. Например, один пиксел экрана с разрешением 96 dpi соответствует 15 единицам логического пространства, а на экране с разрешением 120 dpi один пиксел соответствует 12 единицам логического пространства. На принтере с разрешением 600 dpi один пиксел поверхности устройства соответствует 2,4 логической единицы, то есть 12 логических единиц соответствуют 5 пикселам. Впрочем, этим достоинства разрешения 1440 dpi не исчерпаны — 1440 делится на 72, поэтому один пункт (единица измерения кегля шрифта) соответствует 20 единицам. Если вы принадлежите к числу счастливчиков, которые пишут приложения только для систем семейства NT, подумайте об использовании логического пространства с разрешением 7200 dpi; это позволит точно адресовать все пикселы графических устройств с основными разрешениями 96, 120, 300, 360, 600, 720, 1200, 1440 и 2400 dpi. Как наглядно показывает приведенная ниже функция SetupULCS, создать единую логическую систему координат совсем несложно. #ifdef NT_0NLY #define BASE_DPI 9600 #else #define BASE_DPI 1440 #endif int gcddnt m. int n) { if ( m==0 ) return n; else return gcd(n % m, m): } void SetupULCS(HDC hDC. int zoom) { SetMapModeChDC. MM_ANIS0TR0PIC); int mul - BASE_DPI * 100; int div = GetDeviceCaps(hDC. LOGPIXELSX) * zoom: int fac = gcd(mul. div); mul /= fac; div /= fac; SetWindowExtEx(hDC, mul. mul, NULL): SetViewportExtEx(hDC, div, div, NULL); } Макрос BASE_DPI определяет количество единиц логической системы координат, соответствующих одному дюйму. Обычно оно равно 1440, если только вы не определите макрос NT_0NLY, сообщая тем самым компилятору, что программа предназначена только для систем семейства NT. Функция SetupULCS получает манипулятор контекста устройства и масштаб. Манипулятор может относиться к контексту любого графического устройства.
Поддержка печати в программах 981 Масштаб задается в процентах и изменяется в интервале от 400 до 10. На основании масштаба и логического разрешения контекста устройства функция вычисляет две внутренние переменные, из которых затем исключается наибольший общий делитель. Затем вызываются функции SetWindowExtEx и SetViewportExtEx, определяющие отображение из логической системы координат в систему координат устройства. Обратите внимание: при вызове SetWindowExtEx и горизонтальные, и вертикальные габариты определяются значением BASEDPI; это гарантирует, что BASEDPI единиц в логической системе координат всегда соответствуют одному дюйму. В табл. 17.1 приведены примеры отображений из логических координат в координаты устройства, определяемых функцией SetupULCS. Таблица 17.1. Поддержка разных устройств при разных масштабах Разрешение устройства Масштаб, % Габариты окна Габариты области просмотра 96 dpi (экран) 96 dpi (экран) 96 dpi (экран) 120 dpi (экран) 120 dpi (экран) 360 dpi (принтер) 600 dpi (принтер) 1200 dpi (принтер) 500 100 10 50 10 100 100 100 (3,3) (15,15) (150,150) (24,24) (120,120) (4,4) (12,12) (6,6) Имитация внешнего вида страницы Вывод границ листа на экране относится к числу стандартных приемов, используемых в профессиональных графических пакетах и текстовых редакторах. Границы листа помогают пользователю лучше представить, как же будет выглядеть напечатанный документ. В Microsoft Word этот режим называется разметкой страницы (page layout). Разметка страницы часто требуется и в режиме предварительного просмотра перед печатью. В некоторых приложениях весь пользовательский интерфейс строится именно на разметке страницы. Разметка печатной страницы на экране состоит из нескольких элементов. Во-первых, клиентская область окна обычно закрашивается слегка затемненным цветом. Страницы рисуются белыми, с черной рамкой и простейшей имитацией тени. Небольшие промежутки отделяют страницы друг от друга и от границ клиентской области. В режиме предварительного просмотра перед печатью непечатаемые области обычно обозначаются пунктирной линией, чтобы любые нарушения границ были хорошо видны на экране. Некоторые приложения также тем или иным способом обозначают границы полей, установленных пользователем в диалоговом окне параметров страниц.
982 Глава 17. Печать Ниже приведен пример разметки страницы на экране. Метод DrawPaper относится к классу KSurface, который будет рассматриваться ниже. Переменная т_Рарег класса KSurface определяет размеры листа, в переменной m_MinMargin хранятся минимальные размеры полей, а в переменной m_Margin — текущие размеры полей. Значения этих переменных берутся из диалогового окна параметров страниц. Вспомогательная функция DrawFrame вызывается в DrawPaper трижды. В первый раз DrawFrame рисует границу листа с тенью, во второй обозначает минимальные поля, а в третий — текущие поля. Функции рх и ру обеспечивают масштабирование координат. void KSurface::DrawPaper(HDC hDC. const RECT * rcPaint, int col, int row) { // Граница листа DrawFrame(hDC. px(0. col). py(0. row), px(m_Paper.cx, col). py(m_Paper.cy. row), RGB(0. 0. 0), RGB(0xE0. OxEO. OxEO). true); // Минимальные поля: граница печатной области DrawFrame(hDC, px(m_MinMargin.1 eft. col), py(m_MinMargin.top, row), px(m_Paper.cx - m_MinMargin.right, col), py(m_Paper.cy - m_MinMargin.bottom, row). RGB(0xF0, OxFO, OxFO), RGB(0xF0, OxFO, OxFO), false): // Поля DrawFrame(hDC. px(m_Margin.left. col). py(m_Margin.top. row). px(m_Paper.cx - m_Margin.right, col). py(m_Paper.cy - m_Margin.bottom, row), RGB(0xFF. OxFF. OxFF), RGB(0xFF. OxFF. OxFF). false): } Одновременный вывод страниц В общем случае документ состоит из нескольких страниц. Иногда при достаточно малом масштабе все страницы удается одновременно разместить на экране, что помогает пользователю получить представление о документе в целом. В таких приложениях основное внимание следует уделять логике размещения уменьшенных страниц на экране, чтобы ее не приходилось реализовывать снова и снова. Ниже приведена функция UponDraw, управляющая одновременным выводом для класса KSurface. // Вывод страниц в несколько столбцов с обозначением границ листов. // масштабированием и прокруткой void KSurface::UponDraw(HDC hDC. const RECT * rcPaint) { int nPage = GetPageCountO: int nCol = GetColumnCountO: int nRow - (nPage + nCol - 1) / nCol: for (int p=0: p<nPage: p++) { SaveDC(hDC): int col - p % nCol: int row - p / nCol:
Поддержка печати в программах 983 DrawPaper(hDC. rcPaint, col. row); SetupULCS(hDC, mjiZoom): OffsetViewportOrgExdiDC, px(m_Margin.left. col), py(m_Margin.top. row), NULL): UponDrawPage(hDC, rcPaint. GetDrawableWidthO, GetDrawableHeightO, p); RestoreDC(hDC. -1); } } Метод UponDraw (имя было выбрано для предотвращения конфликта с OnDraw) получает общее количество страниц в документе (виртуальная функция Get- PageCount) и количество столбцов в таблице (функция GetColumnCount). Затем он в цикле перебирает все страницы, находящиеся в разных строках и столбцах. Для каждой страницы UponDraw сохраняет состояние контекста устройства, вызывает функцию разметки и настраивает единую логическую систему координат. Перед виртуальным методом UponDrawPage, выводящим содержимое текущей страницы, вызывается метод OffsetViewportOrgEx, смещающий начало логической системы координат в позицию, определяемую полями текущей страницы. Функция UponDrawPage получает ширину и высоту печатной области (без учета полей) и номер страницы. Таким образом, ей не приходится беспокоиться о положении страницы на экране. После вывода страницы контекст устройства восстанавливается в прежнем состоянии для вывода следующей страницы. Печать нескольких страниц на одном листе Проблема одновременного вывода нескольких логических страниц уже рассматривалась в предыдущем разделе. Основная трудность заключается в том, чтобы использовать при печати тот же виртуальный метод UponDrawPage. В сущности, задача сводится к правильной настройке логической системы координат. Ниже приведен пример реализации для класса KSurface. // Одновременная печать, масштаб 100 % bool KSurface::UponPrint(HDC hDC, const TCHAR * pDocName) { int scale = GetDeviceCaps(hDC. LOGPIXELSX): SetMapMode(hDC. MM_ANISOTROPIC): SetWindowExtEx(hDC. BASE_DPI, BASEJPI. NULL): SetViewportExtEx(hDC. scale, scale. NULL): OffsetViewportOrgExdiDC. (m_Margin.left - m_MinMargin.left) * scale / BASE_DPI, (m_Margin.top - m_MinMargin.top ) * scale / BASE_DPI. NULL); DOCINFO docinfo: docinfo.cbSize = sizeof(docinfo): docinfo.IpszDocName = pDocName: docinfo.IpszOutput - NULL: docinfo. IpszDatatype = JVEMF");
984 Глава 17. Печать docinfo.fwType = 0; if ( StartDoc(hDC, & docinfo) <= 0) return false; int nFrom = 0; int nTo = GetPageCountO; for (int pageno=nFrom; pageno<nTo; pageno++) { if ( StartPage(hDC) < 0 ) { AbortDoc(hDC); return FALSE; } UponDrawPage(hDC. NULL. GetDrawableWidthO, GetDrawableHeightO, pageno); EndPage(hDC); } EndDoc(hDC); return true; } Логическая система координат для печати настраивается проще, поскольку вывод всегда осуществляется в масштабе 100 %. На принтере не нужно имитировать разметку страницы, но для использования той же функции UponDrawPage нам придется переместить начало логической системы координат в точку, определяемую размерами левого и верхнего полей страницы. Задача решается вызовом OffsetViewportOrgExt. Обратите внимание: смещение определяется только разностью между размерами полей и непечатаемой области, поскольку в системе координат устройства начало отсчета устанавливается в первую точку печатаемой области. Родовой класс печати Пора представить родовой класс KSurface, предназначенный для решения общих задач печати средствами GDI. В листинге 17.3 приведено объявление класса и те части реализации, которые не приводились выше. Листинг 17.3. Класс KSurface: одновременный вывод и печать нескольких страниц // 1440 = Н0К(72, 96, 120. 360) Удобно при ограничениях // в 22,75 дюйма в Win95/98 // 7200 = Н0К(72. 96. 120. 360. 600) Идеально подходит для большинства // устройств вывода #ifdef NT_0NLY typedef enum { ONE INCH - 7200 }; #else typedef enum {.ONEINCH - 1440 }: #endif
Поддержка печати в программах 985 class KSurface { public: typedef enum { BASE_DPI = ONEINCH. MARGINJ = 16. MARGIN Y =16 KOutputSetup m_OutputSetup; int mjiSurfaceWidth; // Ширина поверхности в пикселах int mjnSurfaceHeight; // Высота поверхности в пикселах SIZE m_Paper; // в BASEJPI RECT m_Margin; // в BASE_DPI RECT m_MinMargin; // в BASE_DPI int m_nZoom; // 100 для масштаба 1:1 int mjiScale; // GetDeviceCaps(hDC, LOGPIXELSX) * zoom / 100 int px(int x. int col) // Из base_dpi в экранное разрешение { return ( x + m_Paper.cx * col ) * mjiScale / BASE_DPI + MARGIN X * (col+1): int py(int y. int row) // Из base_dpi в экранное разрешение { return ( у + m_Paper.cy * row ) * mjiScale / BASE_DPI + MARGIN_Y * (row+1): } public: int GetDrawableWidth(void) { return m_Paper.cx - m_Margin.left - m_Margin.right: } int GetDrawableHeight(void) { return m_Paper.cy - m_Margin.top - m_Margin.bottom: } virtual int GetColumnCount(void) { return 1; } virtual int GetPageCount(void) { return 1: // Одна страница } virtual const TCHAR * GetDocumentName(void) { Продолжение &
986 Глава 17. Печать Листинг 17.3. Продолжение return _T("«Surface - Document"); } virtual void DrawPaper(HDC hDC. const RECT * rcPaint. int col. int row); virtual void CalculateSize(void); virtual void SetPaper(void); virtual void RefreshPaper(void); virtual void UponDrawPage(HDC hDC. const RECT * rcPaint. int width, int height, int pageno=l); virtual bool UponSetZoom(int zoom); virtual void Uponlnitialize(HWND hWnd); virtual void UponDraw(HDC hDC. const RECT * rcPaint); virtual bool UponPrint(HDC hDC. const TCHAR * pDocName); virtual bool UponFilePrint(void); virtual bool UponFilePageSetup(void); }: // Перейти от 1/1000 дюйма к BASE_DPI void «Surface::SetPaper(void) { POINT paper; RECT margin; RECT minmargin; m_OutputSetup.GetPaperSize(paper); mJMputSetup.GetMargin(margin); m_OutputSetup.GetMi nMargi n(mi nmargi n); m_Paper.cx - paper.x * BASE_DPI / 1000; m_Paper.cy - paper.у * BASEJPI / 1000; m_Margin.left - margin.left * BASE_DPI / 1000; m_Margin.right - margin.right * BASE_DPI / 1000; m_Margin.top - margin.top * BASE_DPI / 1000: m_Margin.bottom» margin.bottom * BASE_DPI / 1000; m_MinMargin.left - minmargin.left * BASE_DPI / 1000; m_MinMargin.right - minmargin.right * BASE_DPI / 1000; m_MinMargin.top - minmargin.top * BASE_DPI / 1000; m_MinMargin.bottom= minmargin.bottom * BASE_DPI / 1000; } // Вычислить общий размер поверхности для вывода nPage страниц в nCol столбцов void «Surface::CalculateSizeCvoid) { int nPage = GetPageCountO; int nCol = GetColumnCountO; int nRow = (nPage + nCol - 1) / nCol; m_nSurfaceWidth - px(m_Paper.cx. 0) * nCol + MARGINJ; m_nSurfaceHeight - py(m_Paper.cy. 0) * nRow + MARGINJ;
Поддержка печати в программах 987 bool KSurface::UponSetZoom(int zoom) { if ( zoom == m_nZoom ) return false; mjiZoom = zoom; HDC hDC = GetDC(NULL); m_nScale = zoom * GetDeviceCaps(hDC, LOGPIXELSX) / 100; DeleteDC(hDC); CalculateSizeO; return true; void KSurface;;RefreshPaper(void) { int zoom = mjiZoom; mjiZoom - 0; SetPaperO; UponSetZoom(zoom); } void KSurface::UponInitializeCHWND hWnd) { m_OutputSetup.SetDefault(hWnd. 1. GetPageCountO); m_nZoom = 100; RefreshPaperO; } void KSurface::UponDrawPage(HDC hDC. const RECT * rcPaint, int width, int height, int pageno) { for (int h*0; h<»(height-BASE_DPI); h +- BASE_DPI) for (int w=0; w<=(width-BASEJDPI); w +- BASE_DPI) Rectang1e(hDC. w. h. w+BASEJDPI. h+BASE_DPI); } bool KSurface::UponFilePrint(void) { int rslt - m_OutputSetup.PrintDialog(PD_RETURNDC | PD_SELECTION); if ( rslt==ID0K ) UponPrint(m_OutputSetup.GetPrinterDC(). GetDocumentName()); m__OutputSetup. Del etePri nterDC (); return false; bool KSurface::UponFilePageSetup(void) { if ( m_OutputSetup.PageSetup(PSD_MARGINS) )" { RefreshPaperO; return true; } return false; }
988 Глава 17. Печать Класс KSurface решает общую задачу одновременного вывода и печати нескольких страниц с поддержкой разных масштабов. Он настолько универсален, что даже не ассоциируется ни с каким окном — для работы с ним достаточно передать манипулятор контекста устройства. Следовательно, этот класс может использоваться для окон SDI и MDI, для диалоговых окон и страниц свойств и даже в элементах ActiveX, EMF или совместимых контекстах устройств. Переменная m_OutputSetup является экземпляром класса KOutputSetup, управляющего настройкой печати и параметров страниц. Переменные mjiSurfaceWidth и mjiSurfaceHeight определяют ширину и высоту поверхности вывода в пикселах и могут использоваться для организации прокрутки. Код вывода полностью поддерживает возможность прокрутки. Значения следующих трех переменных берутся из диалогового окна параметров страниц и преобразуются в единую логическую систему координат методом SetPaper. Переменные m_nZoom и m_nScale определяют масштаб вывода на экран и используются в подставляемых (in-line) функциях преобразования рх и ру. Смысл виртуальных и обычных методов класса вполне очевиден. Переопределение метода UponDrawPage играет ключевую роль при выводе. По умолчанию этот метод рисует на странице квадраты со стороной в один дюйм. Метод UponSetZoom связывается с командой меню или кнопкой панели инструментов и управляет масштабом вывода. Метод Uponlnitialize инициализирует переменные класса. Метод UponDraw связывается с обработчиком сообщения WMPAINT, если класс используется для вывода в окне. Метод UponFilePrint связывается с командой печати в меню. Наконец, метод UponFilePageSetup связывается с командой меню, обеспечивающей настройку параметров страниц. Рис. 17.6. Пример использования классов KSurface и KPageCanvas
Вывод в контексте устройства принтера 989 На прилагаемом компакт-диске приведен класс KPageCanvas, производный от классов KScroll Canvas (поддержка прокрутки в дочерних окнах MDI) и KSurface (одновременный вывод и печать нескольких страниц). На рис. 17.6 показан результат вызова стандартной функции UponDrawPage. Функция рисует квадраты со стороной 1 дюйм на листе размером 4x6 дюймов в альбомной ориентации, с полями размером 0,5 дюйма и в масштабе 75 %. Вывод в контексте устройства принтера Интерфейс GDI проектировался как аппаратно-независимый интерфейс, поэтому вывод в экранном контексте устройства не должен сильно отличаться от вывода в контексте принтера. И все же при работе с контекстом устройства принтера приходится учитывать ряд обстоятельств, особенно если результаты печати отличаются от желаемых. Некоторые проблемы связаны не столько с контекстом устройства принтера, сколько с методикой разработки графических алгоритмов, сохраняющих все пропорции при разных настройках логической системы координат. Единицы измерения Если в вашей программе вывод на экран и на принтер должен выполняться одним фрагментом кода, то от режима отображения ММ_ТЕХТ и системы координат устройства вам придется перейти на логическую систему координат. Однозначное соответствие между единицами логической системы координат и системы координат устройства при этом теряется. Например, класс KSurface из предыдущего раздела использует логическую систему координат с разрешением 1440 dpi как для печати, так и для вывода на экран. У большинства графических устройств разрешение не достигает 1440 dpi, поэтому один пиксел поверхности устройства обычно соответствует нескольким логическим единицам. Впрочем, в ближайшем будущем появятся принтеры с разрешением 2400 dpi. На таких устройствах одна логическая единица будет соответствовать нескольким пикселам поверхности устройства. Итак, при программировании аппаратно-независимого графического вывода следует обратить внимание на следующие обстоятельства, относящиеся к логической системе координат. О Если толщина пера превышает один пиксел, она задается в логической системе координат. При написании универсального графического кода толщину пера приходится задавать в реальных единицах, а не в пикселах. Например, при работе с классом KSurface, представляющим один дюйм 1440 единицами, при определении пера толщиной один пункт будет указываться толщина 20. О При преобразовании координат из логической системы в систему координат устройства следует использовать функции LPtoDP и DPtoLP GDI, поскольку рассчитывать на постоянную связь между этими системами координат уже не приходится.
990 Глава 17. Печать О Некоторые графические алгоритмы при работе с большим изображением используют приращение для перехода к следующей координате. Например, закраска области может осуществляться выводом серии линий, расположенных вплотную друг к другу. Проанализируйте такие алгоритмы и проверьте, не возникают ли при выводе пропуски, перекрытия или иные нарушения. О Функция BitBlt, часто используемая при выводе растров, хорошо работает лишь при выводе на экран или в режиме отображения ММ_ТЕХТ. В универсальном графическом коде вызовы BitBlt следует заменить более общей функцией StretchBU. О Размеры узоров в штриховых кистях GDI зависят от устройства. При использовании штриховых кистей в коде графического вывода с переменным масштабом и при печати окончательный размер этих узоров непредсказуем. Реализуйте собственные аппаратно-независимые штриховые кисти (см. главу 9). О Растры в узорных кистях определяются в системе координат устройства без масштабирования. Таким образом, при рисовании узорной кистью в контексте принтера высокого разрешения исходный (не масштабированный) узор повторяется до заполнения указанной области. Избегайте узорных кистей или масштабируйте растр узора до нужных размеров перед созданием кисти. Текст Текстовые метрики и функции GDI не обеспечивают в достаточной степени вывод текста с точным масштабированием. Главная проблема связана с тем, что GDI работает с целочисленными текстовыми метриками, масштабируемыми до размера шрифта. При выводе нескольких десятков символов в одной строке погрешности ширины и высоты символов накапливаются и начинают влиять на форматирование текста. Поэкспериментируйте с функциями GDI (например, TextOut) и USER (такими, как DrawText), с классами KSurface и KPageCanvas при разном разрешении экрана и масштабе вывода — вы заметите, как быстро накапливаются ошибки. Эта проблема подробно исследовалась в главе 15, посвященной работе с текстом. Одно из возможных решений — использовать эталонный шрифт, размер которого совпадает с размером em-квадрата, описывающего шрифт TrueType. Для решения этой проблемы был создан класс KTextFormator. К этой главе прилагается программа CodePrint, предназначенная для экспериментов с аппаратно-независимым форматированием и многостраничной печатью. В программе CodePrint реализованы простые средства просмотра и печати исходных текстов программ с цветовым выделением синтаксических элементов. Применение класса KTextFormator при форматировании текста гарантирует, что количество строк на странице и позиция символа в строке всегда остаются постоянными независимо от масштаба и разрешения устройства. В работе программы используется простейший лексический анализатор C/C++, который умеет распознавать ключевые слова C/C++, числа, символьные литералы, строковые литералы и комментарии. По результатам работы лексического анализатора каждому символу в строке присваивается цвет. Последовательность одноцветных символов выводится одной функций, перед вызовом которой нужный цвет выбирается для текста.
Вывод в контексте устройства принтера 991 Логика вывода исходных текстов реализована в классе KProgramPageCanvas, производном от класса KPageCanvas, описанного в предыдущем разделе. Ниже приведены два важных метода этого класса. void KProgramPageCanvas::SyntaxHighlight(HDC hDC, int x. int y. const TCHAR * mess) { BYTE f1ag[MAX_PATH]; int len = Jxslen(mess); assertden < MAX_PATH-50): memset(flag. 0. MAX_PATH): ColorText(mess, flag): float width = 0.0: for (int k=0; k<len: ) { int next = 1: while ( (k+next<len) && (flag[k]==flag[k+next]) ) next ++; SetTextColor(hDC. crText[flag[k]]): m_formator.TextOut(hDC. (int) (x + width + 0.5), y. mess+k. next): float w, h; m_formator.GetTextExtent(hDC, mess+k, next, w, h): width += w: k += next: void KProgramPageCanvas::UponDrawPage(HDC hDC. const RECT * rcPaint. int width, int height, int pageno) { if ( rcPaint )// Отказаться от вывода, если текущая страница { // не пересекается с rcPaint RECT rect - { 0. 0. width, height }: LPtoDP(hDC. (POINT *) & rect. 2); if ( ! IntersectRect(& rect. rcPaint. & rect) ) return: } HGDIOBJ hOld = SelectObject(hDC. mJiFont): SetBkMode(hDC. TRANSPARENT): SetTextAlign(hDC. TAJ.EFT | TAJTOP): KGetline parser(mj)Buffer, mjiSize); int skip = pageno * mjlinePerPage: for (int i=0: i<skip: i++) parser.NextlineO; for (i-0; i<m_nLinePerPage: i++) if ( parser.NextlineO ) {
992 Глава 17. Печать SyntaxHighlight(hDC. 0. (int)(m_formator.GetLinespace() * i + 0.5), parser.mjine); } else break; SelectObjectChDC. hOld); } Класс KProgramPageCanvas переопределяет метод KSurface::GetPageCount и реализует более точный способ подсчета страниц, основанный на подсчете строк исходного текста и точной информации о высоте строки. Метод UponDrawPage выводит одну страницу в таблице. Сначала он преобразует прямоугольник страницы из логической системы координат в координаты устройства, чтобы узнать, пересекается ли он с текущим перерисовываемым прямоугольником. Страницы, которые не видны на экране, пропускаются. Затем UponDrawPage при помощи класса KGetline последовательно читает все строки исходного текста, пропускает строки, относящиеся к предыдущим страницам, и выводит только текущую страницу. Вероятно, для повышения быстродействия следовало бы построить индекс. Функция SyntaxHighlight выводит одну строку программы. Она назначает цвета каждому символу в соответствии с лексическими правилами C/C++, обращаясь к лексическому анализатору ColorText, и использует методы класса KTextFormat для точного форматирования выводимого текста. На рис. 17.7 показано окно программы CodePrint, причем в качестве примера выбран ее собственный исходный текст. Рис. 17.7. CodePrint: форматирование текста, одновременный просмотр и печать нескольких страниц
Вывод в контексте устройства принтера 993 Растры Аппаратно-зависимые растры и DIB-секции всегда ассоциируются с совместимым контекстом устройства. Если совместимый контекст устройства ориентируется на конкретный целевой контекст, аппаратно-зависимые растры, созданные для совместимости с экраном, наверняка окажутся несовместимыми с контекстом устройства принтера. Например, если воспользоваться функцией LoadBItmap для загрузки растрового ресурса в формате DDB и создать совместимый контекст устройства для контекста принтера, в общем случае вам не удастся выбрать растр в совместимом контексте, поскольку он может оказаться несовместимым. Вместо этого совместимый контекст устройства следует создать для экранного контекста. И вообще, использовать при печати аппаратно-зависимые растры не рекомендуется — особенно в видеорежимах с 256 цветами, поскольку принтеры не поддерживают аппаратную палитру. Некоторые приложения разделяют большие растры на маленькие фрагменты, чтобы оптимизировать вывод растра на экран или обойти старое ограничение размеров растра в 64 Кбайт. Это особенно важно в Windows 95/98, поскольку до завершения графического вызова GDI все обращения к GDI от других программных потоков блокируются (во избежание проблем с реентерабельностью 16-разрядного кода GDI). С другой стороны, стратегия деления может вызвать большие проблемы с печатью. Во-первых, как было показано выше, при построении EMF у GDI не хватает сообразительности для исключения из EMF неиспользуемых частей исходного растра, в результате чего сгенерированные EMF-файлы могут иметь громадные размеры. Во-вторых, передача большого количества мелких растров драйверу принтера усложняет их обработку драйвером. В-третьих, при делении растра необходимо позаботиться о том, чтобы между частями растра не оставалось пробелов. Если у вас возникли проблемы с печатью растров, вы можете получить важную диагностическую информацию при помощи утилит просмотра и расшифровки EMF-файлов из предыдущей главы. Печать графики в формате JPEG С широким распространением цифровых устройств, работающих с графикой — цифровых фотоаппаратов, сканеров и цветных принтеров, — у нас все чаще возникает необходимость в получении качественных исходных изображений и профессиональном выводе с фотографическим качеством. Печать высококачественных фотографий на компьютере еще никогда не была такой простой и доступной. К сожалению, растровые форматы Win32 не поддерживают сжатия (не говоря уже о качественном сжатии) графики в форматах High Color и True Color. Как правило, никто не хранит свои фотографии в «родном» для Windows формате BMP. В настоящее время для хранения фотографических изображений чаще всего применяется формат JPEG, разработанный группой Joint Photographic Experts Group. GDI до сих пор не поддерживает формат JPEG, хотя в GDI и предусмотрены ограниченные возможности для передачи драйверу принтера изображений
994 Глава 17. Печать JPEG, внедренных в BMP-файлы. Чтобы передать драйверу принтера изображение JPEG или PNG в Windows 98/2000, приложение вызывает функцию ExtEscape с параметрами QUERYSCSUPPORT и CHECKJPEGFORMAT. Если драйвер принтера отвечает положительно, значит, приложение может передать ему изображение JPEG или PNG вызовом SetDIBitsToDevice или StretchDIBits. Однако никто не гарантирует, что ваш принтер поддерживает расшифровку сжатых данных JPEG/PNG, поэтому эту возможность все равно придется реализовывать в приложении. Если вам повезло и драйвер принтера поддерживает расшифровку, это повысит скорость печати. Следующая функция иллюстрирует передачу изображения в формате JPEG на принтер. BOOL StretchJPEGCHDC hDC, int x, int y, int w. int h, void * pJPEGImage. unsigned nJPEGSize, int width, int height) { DWORD esc = CHECKJPEGFORMAT; if ( ExtEscape(hDC, QUERYESCSUPPORT. sizeof(esc), (char *) &esc, 0, 0) <=0 ) return FALSE; DWORD rslt = 0; if ( ExtEscape(hDC, CHECKJPEGFORMAT. nJPEGSize. (char *) pJPEGImage. sizeof(rslt). (char *) &rslt) <=0 ) return FALSE; if ( rslt!=l ) return FALSE; BITMAPINFO bmi ; memset(&bmi , 0. sizeof(bmi)); bmi.bmiHeader.biSize - sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth = width; bmi.bmiHeader.biHeight = - height; // Перевернутое изображение bmi.bmiHeader.biPlanes = 1; bmi.bmi Header.bi Bi tCount = 0; bmi .bmiHeader.biCompression = BI_JPEG; bmi.bmi Header.bi Si zelmage = nJPEGSi ze; return GDIJRROR != StretchDIBits(hDC. x. y. w. h, 0. 0. width, height, pJPEGImage. &bmi. DIB_RGB_C0L0RS. SRCCOPY); } Функция StretchJPEG вызывает ExtEscape дважды. В первый раз она проверяет, поддерживается ли команда CHECKJPEGFORMAT, а во второй — приемлем ли формат JPEG, который мы собираемся передать. Если обе проверки завершаются успешно, изображение JPEG упаковывается в DIB и передается функции StretchDIBits. Если вызов StretchJPEG завершается неудачей, вызывающая сторона должна самостоятельно расшифровать JPEG и передать расшифрованные данные устройству. Расшифровка JPEG считается очень непростой задачей из-за сложности алгоритма сжатия JPEG. С другой стороны, группа IJG (Independent JPEG Group)
Вывод в контексте устройства принтера 995 реализовала сжатие и восстановление JPEG на разных платформах, причем все исходные тексты распространяются бесплатно. Библиотеку IJG для работы с JPEG можно загрузить с сайта www.ijg.org. Хотя библиотека IJG написана на С, а не на C++, в ней использована превосходная объектно-ориентированная архитектура, реализующая скрытие данных и наследование средствами языка С. На прилагаемом компакт-диске библиотека IJG была слегка изменена, чтобы она больше походила на код C++. Переход на C++ упрощает настройку библиотеки без использования указателей на функции. Например, исходный вариант кода IJG поддерживал расшифровку данных только из файлового потока. Благодаря модификации мы можем легко расширить библиотеку и обеспечить расшифровку из буфера, находящегося в памяти. class const_source_mgr : public jpeg_source_mgr { public : void Reset(const unsigned char * buffer, int len ) { bytes_in_buffer -len; next_inputjbyte = buffer; } void init_source(j_decompress_ptr cinfo) { } virtual void term_source(j_decompress_ptr cinfo) { if (cinfo->src) { delete (const_source_mgr *) cinfo->src; cinfo->src = NULL; } } }: GLOBAL(void) jpeg_const_src (j_decompress_ptr cinfo. const unsigned char * buffer, int len) { const_source_mgr * src; if (cinfo->src == NULL) // Впервые для этого объекта JPEG? cinfo->src = new const_source_mgr; src = (const_source_mgr *) cinfo->src; src->Reset(buffer. len); } Класс, приведенный в листинге 17.4, расшифровывает изображения JPEG в формат DIB Windows и генерирует файлы JPEG по изображениям в формате DIB.
996 Глава 17. Печать Листинг 17.4. Класс KPicture: шифрование/расшифровка изображений в формате JPEG class KPicture { void Release(void); int Allocatednt width, int height, int channels, bool bBits=true); public: BITMAPINFO * m_pBMI: BYTE *m_pBits; BYTE * m_pJPEG: int mjnJPEGSize: KPictureO: -KPictureO; int GetWidth(void) const { return m_pBMI->bmiHeader.biWidth; } int GetHeight(void) const { return m_pBMI->bmiHeader.biHeight; } BOOL DecodeJPEGCconst void * jpegimage. int jpegsize); BOOL QueryJPEG(const void * jpegimage. int jpegsize): BOOL LoadJPEGFile(const TCHAR * filename): BOOL SaveJPEGFile(const TCHAR * fileName. int quality): BOOL KPicture::DecodeJPEGCconst void * jpegimage. int jpegsize) { try { struct jpeg_decompress_struct dinfo: jpeg_error_mgr jerr: dinfo.err = & jerr: di nfo.jpeg_create_decompress(): jpeg_const_src(&dinfo. (const BYTE *) jpegimage. jpegsize): di nfo.jpeg_read_header(TRUE); di nfo.jpeg_start_decompress(): intbps = Allocate(dinfo.image_width. dinfo.image_height. di nfo.out_color_components. true): if ( m_pBits==NULL ) return FALSE: for (int h=dinfo.image_height-l; h>=0: h--) // Перевернутое { // изображение
Вывод в контексте устройства принтера 997 BYTE * addr = m_pBits + bps * h; dinfo.jpeg_read_scanlines(& addr, 1); } di nfo.jpeg_fi ni sh_decompress(); dinfo.jpeg_destroy_decompress(); m_pJPEG = (BYTE *) jpegimage; m_nJPEGSize = jpegsize; } catch (...) { return FALSE; } return TRUE; } В листинге 17.4 приведено лишь объявление класса KPicture и функция расшифровки DecodeJPEG. Метод DecodeJPEG преобразует данные изображения JPEG, хранящегося в буфере памяти, прямо в перевернутый формат DIB системы Windows. Метод Allocate управляет выделением памяти и заполнением структуры BITMAPINFO. Поддерживаются как 24-разрядный цветной формат JPEG, так и 8-разрядные изображения в оттенках серого. После расшифровки указатель и размер исходного изображения JPEG сохраняются в классе KPicture на случай, если драйвер принтера согласится их принять. Обратите внимание: библиотека JPEG была модифицирована так, чтобы в расшифрованном изображении составляющие RGB следовали в порядке «синий — зеленый — красный», совместимом с 24-разрядным форматом DIB. На компакт-диске также имеется программа ImagePrint, предназначенная для экспериментов с расшифровкой, выводом на экран и печатью изображений в формате JPEG. В программе ImagePrint изображение JPEG поддерживается классом KImageCanvas, производным от класса KPageCanvas. Основная функция вывода KImageCanvas обеспечивает вывод и печать расшифрованных изображений, а также печать исходного изображения в формате JPEG. Метод UponDrawPage приведен ниже. void KImageCanvas;;UponDrawPage(HDC hDC, const RECT * rcPaint. int width, int height, int pageno) { if ( (m_pPicture==NULL) && (m_pPicture->m_pBMI==NULL) ) int int int int int int int return; sw sh = dpix = dpiy = dpi = dispwi m_pPicture->GetWidth(); m_pPicture->GetHeight(); sw * ONEINCH / width; sh * ONEINCH / height; max(dpix, dpiy); dth = sw * ONEINCH / dpi; dispheight = sh * ONEINCH / dpi; SetStretchBltMode(hDC. STRETCH DELETESCANS);
998 Глава 17. Печать int х - ( width- dispwidth)/2; int у = (height-dispheight)/2; if ( StretchJPEG(hDC, x, y. dispwidth, dispheight. m_pPicture->m_pJPEG. m_pPicture->m_nJPEGSize, sw, sh ) ) return; StretchDIBits(hDC, x, y. dispwidth. dispheight. 0. 0. sw. sh. m_pPicture->m_pBits. m_pPicture->m_pBMI. DIB_RGB_COLORS. SRCCOPY); } Программа ImagePrint была задумана как простейшее средство для печати фотографий, поэтому метод KImageCanvas: :UponDrawPage пытается с максимальной эффективностью использовать дорогую поверхность носителя. Он вычисляет максимальный размер изображения, помещающегося без искажения пропорций на бумаге при текущих размерах полей. Руководствуясь границами листа и обозначениями полей на экране, вы можете легко отрегулировать размеры полей или переключиться на другую ориентацию листа. Сначала метод вызывает функцию StretchJPEG и пытается вывести небольшое изображение в формате JPEG. Если попытка окажется неудачной, приходится передавать большое изображение в формате BMP. Кстати, существует как минимум один драйвер принтера, принимающий изображения в формате JPEG — это драйвер HP 8500 Color PostScript. При выводе в файл вы увидите, что изображение JPEG кодируется в файле PostScript в двоичные данные; это приводит к значительному уменьшению размеров файла. Итоги Настоящая глава объединяет многие темы, рассматривавшиеся в книге (контексты устройств, линии и кривые, заливки, растры, шрифты, текст и EMF) применительно к печати. Мы рассмотрели архитектуру спулера, общую последовательность действий при печати, функции API спулера, предназначенные для получения информации и настройки принтеров, функции поддержки печати в GDI, а также — что самое важное — реализацию профессиональных возможностей печати в приложениях средствами Win32 API. В разделе «Поддержка печати в программах» представлен родовой класс KSurf асе, предназначенный как для вывода на экран, так и для печати. Этот класс обеспечивает полноценное WYSIWYG-представление графических данных в единой логической системе координат. В разделе «Вывод в контексте устройства принтера» приведены два примера нетривиальных программ, использующих классы KSurface и KPageCanvas для решения вполне реальных задач — печати исходных текстов программ и графики в формате JPEG. На этом завершается наше знакомство с традиционным графическим программированием для Windows. Впрочем, GDI, как и любая технология, продолжает развиваться. Благодаря аппаратному ускорению в будущем программы начнут работать с еще большим количеством цветов, а их быстродействие ста-
Итоги 999 нет еще выше. Следующая глава посвящена одному из направлений развития GDI — программированию для DirectDraw. Дополнительная информация Если вы захотите еще больше узнать о печати и спулере, обратитесь к Microsoft DDK. Вы найдете очень подробное описание интерфейса DDI, архитектуры спулера и приемов написания мини-драйверов в архитектуре UniDriver. К DDK также прилагаются исходные тексты драйвера и мини-драйвера, процессора печати EMF и монитора порта. В старые версии Windows NT DDK даже входил полный исходный текст драйвера принтера PostScript. Некоторые проблемы с печатью решаются анализом EMF-файлов спулинга. За информацией и утилитами для работы с метафайлами обращайтесь к главе 16. Примеры программ К главе 17 прилагается несколько примеров программ (табл. 17.2). Таблица 17.2. Программы главы 17 Каталог проекта Описание Samples\Chapt_17\PrinterDevice Samples\Chapt_17\Printer Samples\Chapt_17\CodePrint Samples\Chapt_17\ImagePrint Программа для получения информации о работе спулера и атрибутов контекста устройства принтера. Создана па основе аналогичной программы для работы с экранными устройствами (см. главу 5) Тестовая программа для передачи спулеру низкоуровневых данных и EMF. Иллюстрирует работу с диалоговыми окнами печати и параметрами страниц, простейший цикл печати, применение классов KSurface и KPageCanvas, вывод линий и кривых, заливку замкнутых фигур и аппаратно-пезависимую работу с растрами и текстом Вывод на экран и печать исходных текстов программ с выделением синтаксических элементов в режиме WYSIWYG Просмотр и печать графики в формате JPEG. Программа позволяет передавать на принтер изображения JPEG. Использует библиотеку JPEG из каталога Samples\include\jlib
Глава 18 DirectDraw и непосредственный режим Direct 3D Интерфейс GDI в течение долгого времени считался основным интерфейсом API графического программирования для Windows. Впрочем, в мире персональных компьютеров произошло так много изменений, что и в GDI пришло время фундаментальных усовершенствований (хотя мы знаем, что GDI постепенно усовершенствуется в каждой новой версии Windows). Будущей версии GDI присвоено кодовое название GDI+; это будет GDI нового поколения от Microsoft. Согласно опубликованной документации Microsoft (www.microsoft.com/hwdev/vJdeo/~GDInext.htm), GDI+ создаст инфраструктуру для нововведений в области пользовательского интерфейса. В частности, GDI+ обеспечит простую интеграцию двумерной и трехмерной графики, упростит обработку оцифрованных изображений и установит новые стандарты в области качества графики и быстродействия настольных систем. GDI+ будет поддерживать нетривиальные графические возможности — альфа-наложение, размытие, прозрачные окна, второй буфер, гамма-коррекцию, трехмерный пользовательский интерфейс и т. д. Возникает впечатление, что интерфейс GDI+ в первую очередь направлен на интеграцию традиционного интерфейса GDI с новыми интерфейсами API от Microsoft, предназначенными для программирования игр (DirectDraw и Direct3D). Интеграция плоской и трехмерной графики начнется на уровне API и будет распространяться до уровня DDI (интерфейс драйверов устройств). На уровне DDI GDI+ полное аппаратное ускорение будет обеспечиваться комбинациями двумерных и трехмерных команд. В GDI+ будут определены новые команды для примитивов, не поддерживаемых существующими командами DirectDraw и Direct3D. Говорят, что DirectDraw и Direct3D уже не будут ограничиваться программированием игровых и учебных приложений, а войдут в число базовых компо-
Технология COM 1001 нентов GDI. Другими словами GDI+ это будет GDI + DirectDraw + Direct3D + что-нибудь еще. Как видите, у нас есть все причины, чтобы поскорее заняться DirectDraw и Direct3D. DirectDraw — относительно сложный интерфейс API двумерной графики, для сколько-нибудь приличного описания которого понадобится не менее 200 страниц. Впрочем, непосредственный режим (Immediate Mode) Direct3D настолько сложен, что вам придется прочитать немало книг по компьютерной графике хотя бы для того, чтобы в нем разобраться, не говоря уже об эффективном применении. Эту короткую главу можно рассматривать лишь как краткое введение в DirectDraw и Direct3D. Основное внимание уделяется следующим темам: О знакомство с базовыми концепциями, интерфейсами и методами для программистов GDI; О разработка классов C++, упрощающих программирование для DirectDraw и Direct3D; О возможности применения DirectDraw и Direct3D в «традиционном» программировании для Windows. Технология СОМ Подсистема GDI в Win32 API содержит примерно 500 функций, образующих довольно сложную иерархию без четкой группировки. При проектировании DirectX компания Microsoft позаимствовала модель интерфейса между приложениями и операционной системой из технологии СОМ. Понимание базовых принципов СОМ абсолютно необходимо для написания правильно работающих программ DirectX. СОМ-интерфейсы В технологии СОМ семантически связанные абстрактные методы группируются в абстрактных базовых классах, которые в терминологии СОМ называются интерфейсами. СОМ-интерфейс, как и абстрактный базовый класс, только определяет прототипы всех методов интерфейса на синтаксическом уровне и задает порядок этих методов. Для определения семантики этих методов вместо формального языка, подходящего для машинной проверки, используется запись, более или менее напоминающая естественный язык — просто потому, что на роль такого формального языка не нашлось подходящего кандидата. Все СОМ-интерфейсы являются производными от общего корневого интерфейса I Unknown, который определяется следующим образом: class IUnknown { public: virtual HRESULT stdcall QueryInterface(REFIID riid. void ** ppvObject) - 0;
1002 Глава 18. DirectDraw и непосредственный режим Direct3D virtual ULONG stdcall AddRef(void) - 0; virtual ULONG stdcall Release(void) = 0; }: С каждым СОМ-интерфейсом связывается 128-разрядный идентификатор, который обычно содержит гораздо больше информации, чем ISBN книги, номер машины или водительского удостоверения. Идентификаторы интерфейсов должны быть глобально-уникальными, поэтому они обычно называются GUID (Global Unique ID, глобально-уникальный идентификатор). Например, GUID интерфейса IUknown называется IID_IUnknown и определяется следующим образом: DEFINE_GUID(IID_IUnknown. 0x00000000. 0x0000. 0x0000. ОхСО. 0x00. 0x00. 0x00. 0x00. 0x00. 0x00. 0x46); СОМ-классы СОМ-интерфейс — всего лишь абстрактная спецификация. Чтобы интерфейс приносил практическую пользу, он должен быть воплощен в СОМ-классе. СОМ- класс, реализующий некоторый СОМ-интерфейс, должен определяться как производный от него и реализовывать все методы этого интерфейса. Ниже приведен пример реализации интерфейса I Unknown: class KUnknown : public IUnknown { ULONG m_nRef; // Счетчик ссылок public: KUnknown() { m nRef =0: // В начальном состоянии счетчик ссылок равен 0 ULONG AddRef(void) { return ++ mjnRef; // AddRef увеличивает счетчик ссылок } ULONG Release(void) // Release уменьшает счетчик ссылок { if ( -- m_nRef==0) // Если счетчик ссылок достиг 0 { delete this; return 0; } return mjnRef; } HRESULT QuerylnterfaceCREFIID id. void * * ppvObj) { if ( iid == IIDJUnknown) // Поддерживается только IUnknown { * ppvObj = this; // Вернуть указатель на текущий объект AddRefO; // Увеличить счетчик ссылок return S OK;
Технология COM 1003 return EJOINTERFACE; } }: Создание, применение и удаление СОМ-объектов обычно зависит от счетчика ссылок. Единственным исключением является единичный СОМ-объект, который создается в виде глобальной переменной и поэтому не нуждается в удалении. Следовательно, СОМ-объект обычно содержит хотя бы одну переменную — счетчик ссылок. При создании СОМ-объекта счетчик ссылок инициализируется нулевым значением. Метод AddRef увеличивает счетчик ссылок; этот метод должен вызываться при создании нового указателя на СОМ-объект. Метод Release уменьшает счетчик ссылок и вызывается в том случае, когда указатель на СОМ-объект перестает использоваться. Если счетчик ссылок упал до 0, соответствующий СОМ-объект (кроме единичных объектов) можно удалить. Класс KUnknown предполагает, что его экземпляры создаются в куче оператором new, поэтому они должны удаляться оператором delete. Соответствие между вызовами AddRef и Release чрезвычайно важно для работы программ СОМ. Лишний вызов AddRef не позволит удалить неиспользуемый СОМ-объект, что вызовет утечку памяти/ресурсов. Лишний вызов Release приведет к преждевременному удалению СОМ-объекта, и вероятнее всего — к ошибкам защиты. СОМ-объект должен предоставить реализацию для всех СОМ-интерфейсов, от которых он является производным. Следовательно, он должен реализовывать как минимум интерфейс I Unknown; вероятно, наряду с I Unknown будут реализованы и другие интерфейсы. Метод Query Interface позволяет клиенту СОМ-класса узнать, поддерживается ли тот или иной интерфейс. Query Interface получает ссылку на GUID, возвращает указатель на СОМ-объект, преобразованный к типу конкретного СОМ-интерфейса, а также признак успеха или неудачи. В классе KUnknown, реализующем единственный интерфейс IUnknown, метод Query Interface проверяет, равен ли переданный идентификатор GUID идентификатору IID_ IUnknown. Если идентификаторы совпадают, метод возвращает указатель this, увеличивает счетчик ссылок и возвращает код S0K; в противном случае возвращается код ошибки ENOINTERFACE. Указатель, возвращаемый функцией Querylnterface, называется указателем на объект интерфейса, или просто интерфейсным указателем. Строго говоря, интерфейсный указатель не является указателем на СОМ-интерфейс, поскольку интерфейс — всего лишь спецификация, «условность», а не реально существующий объект. Интерфейсный указатель указывает на адрес СОМ-объекта; первое двойное слово по этому адресу содержит указатель на таблицу указателей на реализации виртуальных методов, определенных в СОМ-интерфейсе. Проще говоря, интерфейсный указатель ссылается на другой указатель, который, в свою очередь, ссылается на массив реализаций виртуальных методов. В нашем простом примере с одним интерфейсом интерфейсный указатель совпадает с указателем на объект. С каждым СОМ-классом также связывается однозначно идентифицирующий его идентификатор GUID. Идентификаторы GUID СОМ-классов обычно относятся к отдельному типу CLSID, формат которого в точности совпадает с форматом GUID.
1004 Глава 18. DirectDraw и непосредственный режим Direct3D Создание СОМ-объекта Итак, у нас имеется СОМ-интерфейс и СОМ-класс. Как воспользоваться ими в других компонентах? Преимущества технологии СОМ главным образом обусловлены четким отделением интерфейсов от реализации, из чего следует, что клиентские компоненты СОМ-класса не видят объявления этого класса. Если объявление класса недоступно, вы не сможете создать новый экземпляр класса оператором new, удалить объект оператором delete или создать СОМ-объект в стеке. Чтобы клиентские компоненты могли создавать объекты, в СОМ определяется обобщенный СОМ-интерфейс ICIassFactory, отвечающий за создание СОМ- объектов. Createlnstance, главный метод ICIassFactory, получает GUID интерфейса, создает новый СОМ-объект и возвращает интерфейсный указатель. К СОМ- классам обычно прилагается специальный класс (называемый фабрикой класса), предназначенный исключительно для создания экземпляров формального класса. СОМ-классы обычно реализуются в виде библиотеки DLL, главная экспортируемая функция которой DllGetClassObject определяется следующим образом: STDAPI DllGetClassObject(REFCLSID rclsid. REFIID riid. LPVOID * ppv); Функция DllGetClassObject DLL COM проверяет GUID всех классов текущей библиотеки DLL. Обнаружив совпадение, она находит нужную фабрику класса и возвращает указатель на объект фабрики класса, который может использоваться для создания одного или нескольких экземпляров СОМ-класса. Операционная система должна регистрировать новые библиотеки DLL COM, чтобы точно знать, где они находятся и какие СОМ-классы реализуют. Общий способ создания СОМ-объектов заключается в использовании функции CoCreate- Instance Win32 API. Функция CoCreatelnstance получает CLSID СОМ-класса и IID СОМ-интер- фейса, ищет в реестре нужный компонент СОМ, загружает его в адресное пространство приложения, находит функцию DllGetClassObject и вызывает ее для создания СОМ-объекта. HRESULT Большинство методов СОМ-интерфейсов возвращают 32-разрядную знаковую величину типа HRESULT. Исключение составляют методы AddRef и Release. Тип HRESULT состоит из трех полей, в которых кодируется признак успешного вызова метода, описание подсистемы, в которой произошел сбой, и код статуса. Старший бит (31) HRESULT содержит 0, если вызов был успешным, или 1 в случае ошибки. Биты с 25 по 16 образуют 11-разрядный код подсистемы. Биты с 15 по 0 образуют 16-разрядный код статуса. Самая важная информация хранится в старшем бите HRESULT. Признак успешного вызова проверяется макросом SUCCEEDED. Этот макрос определяет, является ли HRESULT неотрицательной величиной. У макроса SUCCEEDED имеется парный макрос FAILED, который проверяет, что HRESULT соответствует отрицательной величине. Методы СОМ обычно возвращают S0K (0) в случае успешного завер-
Технология COM 1005 шения, однако сравнивать HRESULT с S_0K не рекомендуется. Методы DirectDraw обычно возвращают признак успешного завершения DD_0K (0). Код подсистемы, как правило, заносится в HRESULT лишь в случае неудачного вызова, чтобы программа могла в какой-то степени локализовать ошибку. В DirectX используются коды подсистемы 0x876 и 0x878. Ниже показано, как формируется значение HRESULT для ошибок DirectDraw/Direct3D. #define _FACDD 0x876 #define MAKE_DDHRESULT(code) MAKE_HRESULT(1. JACDD. code) Например, при создании поверхности DirectDraw с недопустимым форматом пикселов (код DDERRJNVALIDPIXELFORMAT) HRESULT = MAKEDDHRESULT (145). В DirectX определено свыше 200 кодов ошибок HRESULT, поскольку очень важно, чтобы в случае ошибки приложение смогло обнаружить ее возможные причины. DirectX и СОМ В DirectX используются десятки интерфейсов и классов СОМ, однако каноны модели СОМ соблюдаются не в полной мере. Самое заметное нарушение заключается в том, что СОМ-объекты DirectX либо создаются специальной экспортируемой функций, либо строятся на базе существующих СОМ-объектов, не используя родовую функцию CoCreatelnstance. Центральное место в DirectDraw и в непосредственном режиме Direct3D занимает серия интерфейсов IDirectDraw. Опубликованный (то есть формально документированный, распространяемый и используемый) СОМ-интерфейс изменить уже нельзя. Чтобы включить в него новые функциональные возможности, приходится создавать новый интерфейс. Например, после исходного интерфейса IDirectDraw появились интерфейсы IDirectDraw2, IDirectDraw4 и последний интерфейс IDirectDraw7, используемый в DirectX 7.O. DirectDraw экспортирует специальную функцию для создания объекта DirectDraw с поддержкой интерфейса IDirectDraw7: HRESULT WINAPI DirectDrawCreateEx(GUID * lpGUID. LPV0ID * IplpDD. REFIID iid. IUnknown * pUnkOuter): В первом параметре передается указатель на GUID, определяющий графическое устройство с поддержкой DirectDraw/Direct3D на уровне аппаратной реализации, аппаратной реализации на втором мониторе или программной эмуляции. Если передается NULL, используется активное устройство вывода. Константа DDCREATEJMULATEONLY выбирает программную эмуляцию, a DDCREATEHARDWARE0NLY - реализацию с аппаратным ускорением. Данная возможность особенно удобна при тестировании программы и диагностике проблем, встретившихся в другой реализации. Перечисление текущих реализаций DirectDraw/Direct3D в системе осуществляется функцией DirectDrawEnumerateEx. При помощи этой функции ваша программа может найти реализацию, отвечающую ее требованиям. Во втором параметре передается указатель на переменную, в которой сохраняется интерфейсный указатель при успешном создании объекта DirectDraw функцией DirectDrawCreateEx. Третий параметр может быть равен только IID_ IDirectDraw7 — GUID интерфейса IDirectDraw7. Последний параметр зарезерви-
1006 Глава 18. DirectDraw и непосредственный режим Direct3D рован для обеспечения совместимости с механизмом агрегирования СОМ и в настоящее время должен быть равен NULL. Ниже приведен пример инициализации среды DirectDraw функцией Direct- DrawCreateEx. void Demo_DirectDrawCreateEx(KLogWindow * pLog) { IDirectDraw7 * pDD = NULL; HRESULT hr - DirectDrawCreateEx(NULL. (void **) & pDD. IID_IDirectDraw7. NULL): if ( FAILED(hr) ) { pLog->Log("DirectDrawCreateEx failed (%x)". hr); return; } ChecklnterfaceCpLog, pDD. IID_IDirectDraw7, "IDirectDraw7"); CheckInterface(pLog, pDD. IID_IDirectDraw4, "IDirectDraw4"); ChecklnterfaceCpLog. pDD, IID_IDirectDraw2. "IDirectDraw2"); CheckInterface(pLog. pDD, IID_IDirectDraw. "IDirectDraw" ); CheckInterface(pLog. pDD. IID_IUnknown, "IUnknown" ); CheckInterface(pLog, pDD. IID_IDDVideoPortContainer, "IDDVideoPortContainer" ); CheckInterface(pLog, pDD. IID_IDirectDrawKernel. "IIDJDirectDrawKernel" ); ChecklnterfaceCpLog. pDD. IID_IDirect3D7, "IDirect3D7"); CheckInterface(pLog, pDD, IID_IDirect3D3. "IDirect3D3"): pDD->Release(); } Функция Demo_Di rectDrawCreateEx обращается к системе с требованием создать объект DirectDraw и вернуть интерфейсный указатель IDirectDraw7. Если в системе установлена библиотека DirectX 7.0, функция проверяет поддержку других СОМ-интерфейсов при помощи функции Checklnterface. Функция Checklnterface использует Query Interface для получения нового интерфейсного указателя, выводит данные в служебном окне и освобождает указатель. Наконец, DemoDi rectDrawCreateEx освобождает объект DirectDraw методом Release. Эксперимент показывает, что объект DirectDraw, созданный функцией DirectDrawCreateEx, поддерживает все перечисленные интерфейсы, кроме IDirect3D3. На рис. 18.1 в традиционном формате диаграмм СОМ изображены СОМ-интерфей- сы, поддерживаемые объектом DirectDraw. СОМ-объект с поддержкой всех интерфейсов, показанных на рисунке, имеет очень сложную структуру — особенно при смешанной поддержке интерфейсов DirectDraw и Direct3D. По указателям, возвращаемым функцией Querylnterface, можно заметить, что объект DirectDraw не создается как единое целое. Система достаточно умна, чтобы создавать и инициализировать части объекта по мере необходимости.
Общие сведения о DirectDraw 1007 lunknown О IDirectDraw7 О— IDirectDraw4 о— IDirectDraw2 О—г I DirectDraw о— IDDVideoPortContanter о— IDirectDrawKernel О— IDirect3D7 О— ... О— Рис. 18.1. СОМ-интерфейсы, поддерживаемые объектом DirectDraw Как упоминалось выше, интерфейсный указатель ссылается на указатель на таблицу виртуальных функций. Если СОМ-объект создается компилятором C++, последний собирает таблицу виртуальных функций в области постоянных данных программы и генерирует код для занесения указателя на таблицу виртуальных функций во вновь созданный объект. Таблица виртуальных функций объекта DirectDraw собирается во время работы программы в глобальном сегменте данных, доступном для чтения/записи. Такой подход позволяет легко выбрать нужную реализацию в зависимости от текущей настройки системы и даже перехватывать вызовы методов DirectX в отладочных целях. Методика мониторинга СОМ-интерфейсов DirectX описана в разделе «Отслеживание СОМ-интерфей- сов DirectDraw» главы 4. Общие сведения о DirectDraw Хотя СОМ-интерфейсы основаны на абстрактных базовых классах C++, работать с СОМ-интерфейсами значительно сложнее, чем с классами C++. СОМ- интерфейсы разрабатываются прежде всего для того, чтобы компоненты легко работали друг с другом на двоичном уровне, а не для упрощения работы программиста на уровне исходных текстов. Как правило, для работы с СОМ-интерфейсами пишутся оболочки в виде классов C++. СОМ-интерфейсы DirectX ничуть не лучше других СОМ-интерфейсов. Они содержат ограниченное число методов со сложными параметрами, объединяемыми в громадных структурах, и десятками всевозможных флагов. Например, для вывода растра на поверхности в GDI можно воспользоваться такими функциями, как PatBlt, BitBlt, StretchBlt, PlgBlt, MaskBlt, TransparentBlt и AlphaBlend. В DirectDraw для той же цели предусмотрены всего два метода: BltFast и Bit. Учитывая сложность полного описания интерфейсов DirectDraw, мы не будем вдаваться в подробности использования каждого метода. Вместо этого мы Объект DirectDraw
1008 Глава 18. DirectDraw и непосредственный режим Direct3D рассмотрим методы в контексте классов C++ и примерах вывода. Полная информация о любом СОМ-интерфейсе и его методах приведена в MSDN. Интерфейс IDirectDraw7 В листинге 18.1 приведен класс KDirectDraw, который представляет собой несложную оболочку для работы с интерфейсом IDirectDraw7. Листинг 18.1. Класс для работы с интерфейсом IDirectDraw #define SAFE_RELEASE(inf) { if (inf) { inf->Release(); inf - NULL; }} // Оболочка для интерфейса IDirectDraw7 с поддержкой первичной поверхности class KDirectDraw { protected: IDirectDraw7 * m_pDD: RECT m_rcDest; // Приемный прямоугольник KDDSurface m_primary; virtual HRESULT DischargeCvoid); public; KDirectDraw(void); virtual -KDirectDraw(void) { Discharge(); } void SetClientRectCHWND hWnd): virtual HRESULT SetupDirectDraw(HWND hTop. HWND hWnd. int nBufferCount=0. bool bFullScreen = false, int width=0. int height=0. int bpp=0); }: KDirectDraw: :KDirectDraw(void) { m_pDD = NULL: } HRESULT KDirectDraw::Discharge(void) { m_primary.Di scharge(); SAFE_RELEASE(m_pDD); return S_OK: } void KDirectDraw::SetClientRect(HWND hWnd) {
Общие сведения о DirectDraw 1009 GetCli entRect(hWnd. & m_rcDest); ClientToScreen(hWnd. (POINT*)& m_rcDest.left); ClientToScreen(hWnd. (POINT*)& m_rcDest.right); HRESULT KDirectDraw::SetupDirectDraw(HWND hTop. HWND hWnd, int nBufferCount. bool bFullScreen, int width, int height, int bpp) { HRESULT hr - DirectDrawCreateEx(pDriverGUID. (void **) &m_pDD. IID_IDirectDraw7. NULL): if ( FAILEDC hr ) ) return hr; if ( bFullScreen ) hr - m_pDD->SetCooperativeLevel(hTop. DDSCLJULLSCREEN | DDSCLJXCLUSIVE); else hr - m_pDD->SetCooperativeLevel(hTop. DDSCL_NORMAL): if ( FAILED(hr) ) return hr; if ( bFullScreen ) { hr - m_pDD->SetDisplayMode(width, height, bpp. 0. 0); if ( FAILED(hr) ) return hr; SetRect(& m_rcDest. 0. 0. width, height): } else SetClientRect(hWnd): hr « m_primary.CreatePrimarySurface(m_pDD. nBufferCount); if ( FAILED(hr) ) return hr; if ( ! bFullScreen ) hr = m_primary.SetClipper(m_pDD. hWnd); return hr; } В классе KDirectDraw определяются три переменные: интерфейсный указатель m_pDD на IDirectDraw7, приемный прямоугольник mrcDest и первичная поверхность вывода m_primary. Поверхность представлена классом KDDSurface, о котором речь пойдет ниже. Конструктор присваивает mpDD указатель NULL, метод Discharge освобождает выделенные ресурсы (этот метод вызывается в деструкторе). Метод SetupDirectDraw создает объект DirectDraw и осуществляет подготовку к выводу средствами DirectDraw. Метод получает семь параметров: манипулятор окна верхнего уровня, манипулятор дочернего окна, использующего DirectDraw, количество резервных буферов, флаг полноэкранного режима и три целых
1010 Глава 18. DirectDraw и непосредственный режим Direct3D числа, определяющих формат экрана в полноэкранном режиме. Метод Setup- DirectDraw создает объект DirectDraw вызовом функции DirectDrawCreateEx, возвращающей интерфейсный указатель на IDirectDraw7 в переменной m_pDD. Если выполнение функции прошло успешно, вызывается метод IDirectDraw7: :Set- CooperativeLevel, который передает манипулятору главного окна информацию о том, какой нужен режим — полноэкранный или оконный. Полноэкранные программы DirectX обычно относятся к категории игровых или обучающих. Как правило, такие программы присваивают монопольные права на распоряжение всеми ресурсами DirectX. DirectX также поддерживает вывод в оконном режиме и даже одновременный вывод в нескольких окнах несколькими экземплярами DirectDraw. Полноэкранная программа DirectX обычно изменяет разрешение pi цветовой формат экрана в соответствии со своими потребностями. Например, программы, использующие анимацию на базе палитры, должны переключить экран в режим с 256 цветами; программы, стремящиеся добиться максимального быстродействия, могут переключиться в режим с пониженным разрешением, чтобы уменьшить затраты видеопамяти и объем пересылаемых данных. Метод SetupDi rectDraw переключает видеорежим при помощи метода IDirectDraw::SetDisplayMode. Полноэкранная программа должна произвести перечисление поддерживаемых видеорежимов методом IDi rectDraw: :Enumerate- DisplayModes, иначе попытка переключения может завершиться неудачей. Например, многие видеоадаптеры поддерживают видеорежимы с 32-разрядным цветом, но не поддерживают 24-разрядных цветов. Метод SetupDi rectDraw также вычисляет прямоугольник поверхности вывода и сохраняет его в переменной m_rcDest. В полноэкранном режиме приемный прямоугольник соответствует всему экрану; в оконных режимах — клиентской области окна, определяемого параметром hWnd. Обратите внимание: при вызове SetupDi rectDraw передаются два манипулятора, поэтому мы не ограничены использованием DirectDraw только в главном окне. В завершение метод SetupDi rectDraw создает первичную графическую поверхность и настраивает в ней отсечение. Для решения этих задач нам понадобится класс KDDSurface. Интерфейс IDirectDrawSurface7 Все операции вывода в DirectDraw осуществляются с поверхностями, отдаленно напоминающими контексты устройств GDI. Поверхности DirectDraw могут представлять текущий экран или внеэкранный буфер, находящийся в памяти. Для первого случая можно провести аналогию с экранным контекстом устройства, а для второго — с совместимым контекстом устройства, созданным на базе DIB-секции. В настоящее время для работы с поверхностями DirectDraw используется интерфейс IDirectDrawSurface7, содержащий около 50 методов. Если прикинуть, скольким функциям GDI передается манипулятор контекста устройства, возникает желание дополнить IDirectDrawSurface новыми методами, чтобы упростить программирование. Некоторые базовые методы IDirectDrawSurface будут описаны по мере их использования в классе KDDSurface. Класс KDDSurface не только является простой
Общие сведения о DirectDraw 1011 оболочкой для работы с интерфейсом, но и содержит немало методов, упрощающих работу с поверхностями DirectDraw. В листинге 18.2 приведено объявление класса KDDSurface, а фрагменты реализации будут приводиться по мере надобности. Листинг 18.2. Класс для работы с интерфейсом IDirectDrawSurface7 class KDDSurface { protected: IDirectDrawSurface7 * m_pSurface; DDSURFACEDESC2 m_ddsd; HDC m hDC: public: KDDSurfaceO: virtual void Discharge(void): virtual -KDDSurfaceO DischargeC); // Освобождение ресурсов // перед вызовом деструктора // Освобождение всех ресурсов operator IDirectDrawSurface7 * & О return m_pSurface: operator HDC О return m_hDC; nt GetWidth(void) const return m_ddsd.dwWidth; nt GetHeight(void) const return m_ddsd.dwHeight; HRESULT CreatePrimarySurface(IDirectDraw7 * pDD. int nBackBuffer): const DDSURFACEDESC2 * GetSurfaceDesc(void): virtual HRESULT RestoreSurface(void); // Восстановление // потерянных поверхностей // Блиттинг в DirectDraw HRESULT SetClipper(IDirectDraw7 * pDD. HWND hWnd); HRESULT BltCLPRECT prDest. IDirectDrawSurface7 * pSrc, Продолжение &
1012 Глава 18. DirectDraw и непосредственный режим Direct3D Листинг 18.2. Продолжение LPRECT prSrc. DWORD dwFlags. LPDDBLTFX pDDBltFx=NULL) { return m_pSurface->Blt(prDest, pSrc. prSrc. dwFlags. pDDBltFx); } DWORD ColorMatchCBYTE red, BYTE green. BYTE blue); HRESULT FillColor(int xO. int yO. int xl. int yl. DWORD fillcolor): HRESULT BitBltCint x. int y. int w. int h. IDirectDrawSurface7 * pSrc. DWORD flag-O): HRESULT BitBltCint x. int y. KDDSurface & src. DWORD flag-O) { return BitBltCx. y. src.GetWidthO. src.GetHeightO. src. flag); } HRESULT SetSourceColorKeyCDWORD color); // Вывод с использованием контекста устройства GDI HRESULT GetDC(void); // Получение манипулятора DC HRESULT ReleaseDC(void): HRESULT DrawBitmapCconst BITMAPINFO * pDIB. int dx. int dy. int dw. int dh); // Прямой доступ к пикселам BYTE * LockSurfaceCRECT * pRect=NULL); HRESULT Unlock(RECT * pRect=NULL); int GetPitch(void) const { return m ddsd.lPitch; Класс KDDSurface содержит три переменные: указатель на интерфейс IDirect- DrawSurface7, структуру с описанием поверхности и манипулятор контекста устройства GDI. Указатель на IDirectDrawSurface7 возвращается системой при создании поверхности DirectDraw, и все взаимодействие с поверхностью происходит через этот указатель. Структура DDSURFACEDESC2 описывает формат поверхности. В ней хранятся важнейшие атрибуты поверхности — тип, ширина, высота, смещение строк развертки, адрес, формат пикселов и т. д. С каждой поверхностью DirectDraw может быть связан манипулятор контекста устройству GDI, позволяющий осуществлять вывод на поверхности DirectDraw средствами GDI. Хотя поверхности DirectDraw создаются всего одним методом IDirectDraw7:: CreateSurface, существует несколько способов создания поверхности. В классе KDDSurface предусмотрены дополнительные методы, упрощающие создание поверхностей. Ниже приведен конструктор класса KDDSurface и метод создания первичной поверхности, используемой классом KDirectDraw. KDDSurface;;KDDSurface() {
Общие сведения о DirectDraw 1013 m_pSurface - NULL; mJiDC - NULL: mjiDCRef - 0; memset(& mjJdsd. 0. sizeof(m_ddsd)); m_ddsd.dwSize - sizeof(m_ddsd); } HRESULT KDDSurface::CreatePrimarySurface(IDirectDraw7 * pDD. int nBufferCount) { if ( nBufferCount==0 ) { m_ddsd.dwFlags - DDSD_CAPS; m_ddsd.ddsCaps.dwCaps - DDSCAPS_PRIMARYSURFACE; } else { m_ddsd.dwFlags - DDS0_CAPS | DDSDJACKBUFFERCOUNT: mJdsd.ddsCaps.dwCaps - DDSCAPS_PRIMARYSURFACE | DDSCAPSJLIP | DDSCAPS_COMPLEX | DDSCAPSJIDEOMEMORY: m_ddsd.dwBackBufferCount = nBufferCount; } return pDD->CreateSurface(& m_ddsd. & m_pSurface. NULL); } В полноэкранных программах DirectX видеоадаптер может поддерживать простые поверхности, а также поверхности с двумя или тремя буферами. Простая поверхность состоит из одного буфера, в котором производится весь вывод и по содержимому которого генерируется видеосигнал. Поверхность с двумя буферами содержит два буфера: один буфер отображается на экране, а во втором выполняются операции вывода. Переключение буферов в DirectX выполняется методом IDirectDrawSurface7::Flip. Также существуют поверхности с тремя буферами: один буфер отображается, другой ждет отображения, а в третьем выполняются операции вывода. Поверхности с двумя и тремя буферами играют важную роль для обеспечения плавного вывода без мерцания. Впрочем, они возможны только в полноэкранном монопольном режиме, поскольку аппаратное переключение буфера может выполняться только на всем экране, но не в отдельном окне. Чтобы организовать качественный вывод в оконной программе DirectDraw, вам придется использовать внеэкранную поверхность и самостоятельно копировать ее содержимое на первичную поверхность. Метод CreatePrimarySurface получает указатель на интерфейс IDirectDraw7 и количество вторичных буферов. Если количество вторичных буферов равно 0, метод устанавливает в структуре DDSURFACEDESC2 два флага создания простой первичной поверхности; в противном случае устанавливаются дополнительные флаги и присваивается значение полю количества вторичных буферов. Переменная mddsd, относящаяся к типу DDSURFACEDESC2, частично инициализируется в конструкторе класса.
1014 Глава 18. DirectDraw и непосредственный режим Direct3D Вывод на поверхности DirectDraw От создания поверхности DirectDraw можно переходить к графическому выводу. Существует три варианта вывода на поверхности DirectDraw: методами IDirect- DrawSurface7, использующими аппаратное ускорение, средствами GDI или прямыми операциями с пикселами кадрового буфера поверхности. Вывод с аппаратным ускорением Интерфейс IDirectDrawSurface содержит всего три метода вывода: Bit, BltFast и BltBatch (причем последний метод не реализован). Поскольку методы Bit и BltFast могут ускоряться на аппаратном уровне, рекомендуется использовать их всюду, где это возможно, чтобы добиться хорошего быстродействия. Ниже приведено объявление метода Bit. HRESULT BltCLPRECT IpDestRect. LPDIRECTDRAWSURFACE7 IpDDSrcSurface, LPRECT IpSrcRect. DWORD dwFlags. LPDDBLTFX IpDDBltFx); Метод Bit напоминает функцию StretchBlt GDI — он тоже копирует прямоугольный участок поверхности-источника в прямоугольный участок приемной поверхности. Приемная поверхность определяется текущим указателем на IDirectDrawSurface/, а приемный прямоугольник задается параметром IpDestRect. Источник определяется параметром IpDDSrcSurface, а исходный прямоугольник — параметром IpSrcRect. В параметре dwFlags передаются флаги, управляющие процессом блиттинга, а последний параметр содержит указатель на структуру DDBLTFX с дополнительными управляющими полями. Простейшим применением функции Bit является заполнение приемного прямоугольника однородным цветом (по аналогии с функцией PatBlt). Ниже приведен метод KDDSurface: -.Fill Col or, инкапсулирующий однородную заливку. HRESULT KDDSurface::FillColor(int xO. int yO, int xl. int yl. DWORD fillcolor) { DDBLTFX fx; fx.dwSize = sizeof(fx); fx.dwFillColor = fillcolor; RECT re - { xO. yO. xl. yl }; return m_pSurface->Blt(& re. NULL. NULL. DDBLT_COLORFILL. & fx); } Метод Fill Col or заполняет структуру RECT четырьмя переданными параметрами. Поверхность и прямоугольник источника в данном случае не нужны. Параметр dwFlags равен DDBLTCOLORFILL, а структура DDBLTFX в основном определяет цвет заливки. Вывод средствами GDI Интерфейс DirectDraw разрабатывался для того, чтобы программисты могли отойти от GDI. Впрочем, уходить слишком далеко все равно не удастся — время от времени вам понадобится помощь со стороны GDI. Хотя технология DirectDraw обеспечивает вывод с аппаратным ускорением, функции вывода в ней очень ограничены. В DirectX GDI по-прежнему занимает важное место при вы-
Общие сведения о DirectDraw 1015 воде текста и инициализации поверхности растрами. Чтобы использовать GDI для работы с поверхностью DirectDraw, следует вызвать метод IDirectDrawSur- face::GetDC для получения манипулятора контекста устройства GDI. Полученный манипулятор позднее можно освободить методом ReleaseDC. Ниже приведены методы для вызовов GetDC и ReleaseDC, а также метод для вывода DIB на поверхности DirectDraw средствами GDI. HRESULT KDDSurface::GetDC(void) { return m_pSurface->GetDC(&m_hDC); } HRESULT KDDSurface::ReleaseDC(void) { if ( m_hDC==NULL ) return S_0K; HRESULT hr = m_pSurface->ReleaseDC(m_hDC); m_hDC « NULL: return hr; } HRESULT KDDSurface::DrawBitmap(const BITMAPINFO * pDIB. int x. int y. int w, int h) { if ( SUCCEEDED(GetDCO) ) { StretchDIBits(m_hDC. x. y. w. h. 0. 0. pDIB->bmiHeader.biWidth. pDIB->bmiHeader.biHeight. & pDIB->bmiColors[GetDIBColorCount(pDIB)], pDIB. DIB_RGB_C0L0RS. SRCCOPY); return ReleaseDCO: } else return E_FAIL; } Метод DrawBitmap выводит упакованный аппаратно-независимый растр на поверхности DirectDraw. При этом используется функция StretchDIBits, идеально подходящая для загрузки растров на поверхность DirectDraw. Если быстродействие критично, функция DrawBitmap требуется только для загрузки растра на внеэкранную или текстурную поверхность, которая затем выводится на первичной поверхности аппаратно-ускоренным методом Bit. В большинстве книг по DirectX для загрузки растра применяются DDB и DIB-секции в сочетании с совместимыми контекстами устройств, для чего приходится создавать два объекта GDI. Я предпочитаю загрузку растра с использованием DIB, поскольку при этом не изменяются цвета (как при использовании DDB) и не расходуются дополнительные ресурсы GDI. Манипулятор DC, возвращаемый методом IDirectDrawSurface7::GetDC, интерпретируется как манипулятор совместимого контекста устройства. Если вызвать для него функцию GetObjectType, GDI вернет 0BJMEMDC. Впрочем, его не стоит принимать за обычный манипулятор совместимого контекста устройства, поскольку он не был создан функцией CreateCompatibleDC или хотя бы CreateDC.
1016 Глава 18. DirectDraw и непосредственный режим Direct3D Этот манипулятор создается специальной системной функцией NtGdiDcGetDC. Зная манипулятор DC, можно воспользоваться вызовом GetCurrentObjectCmhDC, OBJBITMAP) для получения растра, выбранного в контексте; функция возвращает манипулятор DIB-секции. Если после этого запросить описание DIB-секции функцией GetObject, заполняется вполне нормальная структура DIBSection. Единственное отличие состоит в том, что указатель на графические данные ссылается на адресное пространство режима ядра, что не позволяет обратиться к нему в пользовательском режиме. Тем не менее эта DIB-секция отличается от обычных, поскольку поверхности DirectDraw могут иметь странные форматы пикселов, не относящиеся к стандартным форматам DIB. Например, некоторые драйверы экрана могут поддерживать 8-разрядные поверхности RGB в формате 2-3-2 или 16-разрядные поверхности RGB в формате 4-4-4-4. Прямой доступ к пикселам В некоторых ситуациях даже комбинация функций Bit, BltFast и функций GDI не решает всех проблем. Допустим, вы просто хотите изменить цвет одного пиксела на поверхности DirectDraw; вызывать для этого функцию Bit или функцию GDI было бы слишком долго. DirectDraw позволяет получить доступ к кадровому буферу поверхности посредством фиксации (locking). Метод IDirectDrawSur- face7: -.Lock отображает кадровый буфер поверхности в блок памяти, адресуемый в пользовательском режиме. Фиксация одинаково работает как для первичной поверхности, так и для внеэкранных поверхностей. Работа с зафиксированной поверхностью через указатель на кадровый буфер практически не отличается от работы с массивом пикселов DIB или DIB-секции, что позволяет использовать множество интересных алгоритмов. Фиксация поверхностей навевает воспоминания о старых игровых DOS-программах, которые напрямую работали с видеопамятью и добивались высокого быстродействия, недостижимого средствами GDI. Ниже приведены методы фиксации и освобождения поверхностей. BYTE * KDDSurface::LockSurface(RECT * pRect) { if ( FAILED(m_pSurface->Lock(pRect. & m_ddsd. DDLOCKJURFACEMEMORYPTR | DDLOCK_WAIT. NULL)) ) return NULL; else return (BYTE *) m_ddsd.lpSurface: } HRESULT KDDSurface::Unlock(RECT * pRect) { m_ddsd.lpSurface = NULL: // Содержимое поверхности // становится недоступным return m_pSurface->Unlock(pRect); } Метод LockSurface фиксирует прямоугольный участок поверхности, вызывая метод IDirectDrawSurface7::Lock, что приводит к заполнению структуры DDSURFACEDESC2. Самые важные поля заполненной структуры содержат информацию о формате пикселов поверхности, ширине, высоте, смещении строк развертки, а также указатель на кадровый буфер. Еойи при вызове метода Lock передается допустимый
Общие сведения о DirectDraw 1017 прямоугольник, указатель IpSurface ссылается на левый верхний пиксел этого прямоугольника; в противном случае он относится к первому пикселу поверхности. Метод Unl ock освобождает зафиксированную поверхность. Указатель, возвращаемый методом Lock, может использоваться для непосредственной работы с содержимым поверхности, однако необходима крайняя осторожность, поскольку прямой доступ не учитывает отсечения. Обращение к пикселам, находящимся за допустимыми границами, приведет к ошибкам защиты или порче содержимого других окон (если программа работает в оконном режиме). Приложение должно самостоятельно реализовать необходимое отсечение. Приведенная ниже функция уже не ограничивается простой закраской участка поверхности однородным цветом. BOOL PixelFillRect(KDDSurface & surface, int x. int y. int width, int height. DWORD dwColor[]. int nColor) { BYTE * pSurface - surface.LockSurface(NULL); const DDSURFACEDESC2 * pDesc - surface.GetSurfaceDescO; if (pSurface) { int pitch = surface.GetPitchO; int byt - pDesc->ddpfPixelFormat.dwRGBBitCount / 8; for (int j=0; j<height; j++) { BYTE * pS - pSurface + (y+j) * pitch + x * byt: DWORD color = dwColor[j % nColor]; int i; switch (byt) { case 1: memset(pS. color, width): break: case 2: for (i=0: i<width; i++) { * (unsigned short *) pS - (unsigned short) color; pS +- sizeof(unsigned short): } break: case 3: for (i»0; i<width: i++) { * (RGBTRIPLE *) pS - * (RGBTRIPLE *) & color: pS +- sizeof(RGBTRIPLE): } break: case 4: for (i=0: i<width; i++)
1018 Глава 18. DirectDraw и непосредственный режим Direct3D { * (unsigned *) pS = color; pS += sizeof(unsigned); } break; default: return FALSE; } } surface.UnlockO; return TRUE: } else return FALSE; } Функция PixelFillRect заполняет прямоугольную область разноцветными горизонтальными линиями. Она получает указатель на поверхность функцией LockSurface, вычисляет адрес графических данных в соответствии с форматом пикселов, а затем прямым копированием данных в кадровый буфер поверхности рисует линию за линией, пиксел за пикселом. Методы Blt/BltFast, вывод средствами GDI и прямой доступ к пикселам являются взаимоисключающими. При открытом манипуляторе контекста устройства GDI попытка зафиксировать поверхность завершается неудачей; вывод средствами GDI на зафиксированной поверхности тоже ни к чему не приводит. В Windows 95/98 фиксация поверхности обычно сопровождается установкой системного мьютекса, блокирующего другие программные потоки от работы с 16-разрядной реализацией GDI, из-за проблем реентерабельности. Следовательно, поверхности должны фиксироваться лишь в случае необходимости, а когда такая необходимость отпадает, поверхности следует освобождать. Подбор цветов Параметр KDDSurface:: Fill Color, определяющий цвет заливки, относится к типу DWORD вместо типа C0L0RREF, знакомого нам по GDI. Значение задается в физическом цветовом формате конкретной поверхности, а не в общем формате GDI. DirectDraw в действительности является тонкой прослойкой над аппаратным уровнем. Эта прослойка настолько тонка, что в DirectDraw не существует простого способа определения цветов с использованием цветовых каналов RGB. Физические цвета, приемлемые для DirectDraw, зависят от формата пикселов поверхности. Ниже приведен простой способ подбора цветов, реализованный в виде родового метода класса KDDSurface. const DDSURFACEDESC2 * KDDSurface::GetSurfaceDesc(void) { if ( SUCCEEDED(m_pSurface->GetSurfaceDesc(& m_ddsd)) ) return & m_ddsd; else return NULL; }
Общие сведения о DirectDraw 1019 DWORD KDDSurface::ColorMatch(BYTE red. BYTE green. BYTE blue) { if ( m_ddsd.ddpfPixel Format.dwSize==0 ) // Поверхность не инициализирована GetSurfaceDescO; // Получить описание поверхности const DDPIXELFORMAT & pf = mjdsd.ddpf Pixel Format; if ( pf.dwFlags & DDPF_RGB ) { // x-5-5-5 if ( (pf.dwRBitMask — 0x7C00) && (pf.dwGBitMask == ОхОЗЕО) && (pf.dwBBitMask==0x001F) ) return ((red»3)«10) | ((green»3)«5) | (blue»3); // 0-5-6-5 if ( (pf.dwRBitMask == OxF800) && (pf.dwGBitMask == 0x07E0) && (pf.dwBBitMask==0x001F) ) return ((red»3)«ll) | ((green»2)«5) | (blue»3): // x-8-8-8 if ( (pf.dwRBitMask == OxFFOOOO) && (pf.dwGBitMask == OxFFOO) && (pf.dwBBitMask==OxFF) ) return (red«16) | (green«8) | blue; } DWORD rslt = 0; if ( SUCCEEDED(GetDCO) ) // Получить GDI DC { COLORREF old = ::GetPixel(m_hDC. 0. 0); // Сохранить исходный пиксел SetPixeKmJiDC. 0. 0. RGB(red. green, blue)); // Присвоить ReleaseDCO: // пиксел RGB const DWORD * pSurface = (DWORD *) LockSurfaceO; // Зафиксировать if ( pSurface ) { rslt = * pSurface; // Прочитать первое двойное слово if ( pf.dwRGBBitCount < 32 ) rslt &= (1 « pf.dwRGBBitCount) - 1; // Усечение по bpp UnlockO; // Освободить поверхность } else assert(false); GetDCO: SetPixel(m_hDC. 0. 0. old); // Вернуть исходный пиксел ReleaseDCO; // Освободить GDI DC } else assert(false); return rslt;
1020 Глава 18. DirectDraw и непосредственный режим Direct3D Метод Col orMatch преобразует цвет, заданный красным, зеленым и синим каналами, в физический цвет — двойное слово (DWORD), готовое к занесению в кадровый буфер. Сначала он проверяет структуру DDPIXELFORMAT; если проверка оказывается неудачной, вызывается метод GetSurfaceDesc, возвращающий структуру с описанием текущей поверхности. Затем метод Col orMatch сравнением масок каналов пытается определить, относится ли поверхность к одному из стандартных 15-, 16-, 24 или 32-разрядных форматов RGB. Если маски совпадают, Col orMatch объединяет каналы RGB в правильный физический цвет. Если быстрый путь не приводит к успеху, приходится обращаться к GDI. Программа получает для поверхности манипулятор устройства GDI, сохраняет текущее состояние пиксела (0,0) при помощи функции GetPixel, присваивает пикселу (0,0) значение RGB функцией SetPixel, а затем читает физический цвет из зафиксированной поверхности. Перед возвратом из функции исходное состояние пиксела (0,0) восстанавливается еще одним вызовом SetPixel. Поскольку манипуляторы GDI и фиксация поверхности не могут использоваться одновременно, программа освобождает манипулятор DC перед фиксацией поверхности, а затем снова получает его для восстановления измененного пиксела. Как видите, для простого преобразования RGB-значения в физический цвет работы получается слишком много, поэтому результаты вызова Col orMatch следует по возможности использовать многократно. Метод KDDSurface:: Fill Col or получает физический цвет вместо логического, чтобы можно было организовать кэширование физических цветов. Интерфейс IDirectDrawClipper Первичная поверхность, создаваемая DirectDraw, всегда распространяется на весь экран. Она позволяет рисовать в любой точке экрана, как и контекст устройства, возвращаемый вызовом GetDC(NULL). Для ограничения области вывода в DirectDraw поддерживается механизм отсечения с объектами отсечения, абстрагированными в интерфейсе IDirectDrawClipper. Сначала объект отсечения создается, а затем присоединяется к поверхности DirectDraw. Область отсечения задается так называемым списком отсечения (clip list), который представляет собой не что иное, как структуру RGNDATA, используемую GDI при операциях с объектами регионов. Чтобы инициализировать объект отсечения правильным списком отсечения, проще всего ассоциировать его с окном. Операционная система автоматически управляет списком отсечения при перемещении или изменении размеров окна с учетом его видимости. Приведенный ниже метод KDDSurface: .-SetClipper создает объект отсечения, ассоциирует его с окном и присоединяет к поверхности. Этот метод вызывается методом KDirectDraw:: SetupDi rectDraw после создания первичной поверхности. HRESULT KDDSurface::SetClipper(IDirectDraw7 * pDD. HWND hWnd) { IDirectDrawClipper * pClipper: HRESULT hr - pDD->CreateClipper(0, & pClipper, NULL); if ( FAILEDC hr ) ) return hr;
Общие сведения о DirectDraw 1021 pClipper->SetHWnd(0. hWnd); m_pSurface->SetClipper(pClipper); return pClipper->Release(); } Обратите внимание: после вызова IDirectDrawSurface7::SetC1ipper поверхность получает указатель на объект отсечения, что приводит к увеличению счетчика ссылок объекта. Затем вызывается метод IDirectDrawClipper::Release, который освобождает ссылку на объект, хранящуюся в локальной переменной функции. Простое окно DirectDraw У нас имеются все классы и методы, необходимые для конструирования простого окна DirectDraw. В листинге 18.3 приведен несложный, но достаточно полный класс окна, с поддержкой DirectDraw. Листинг 18.3. Простой класс окна DirectDraw class KDDWin : public «Window, public KDirectDraw { void OnNCPaint(void) { RECT rect; GetWindowRect(m_hWnd. & rect); DWORD dwColor[18]; for (int i-0: i<18; i++) dwColor[i] - m_priтагу.ColorMatch(0. 0, 0x80 + abs(i-9)*12); PixelFillRect(m_primary, rect.left+24. rect.top+4, rect.right - 88 - rect.left. 18. dwColor. 18); BYTE * pSurface = m_primary.LockSurface(NULL); m_primary.Unlock(NULL); if ( SUCCEEDED(m_primary.GetDCO) ) { TCHAR temp[MAX_PATH]; const DDSURFACEDESC2 * pDesc = m_primary.GetSurfaceDesc(); if ( pDesc ) wsprintf(temp. "%6x%6 Ud-bpp. pitched. lpSurface=0xfcx", pDesc->dwWidth. pDesc->dwHeight. pDesc->ddpfPixelFormat.dwRGBBitCount. pDesc->lPitch. pSurface); else strcpy(temp. "LockSurface failed"); SetBkMode(m_primary. TRANSPARENT); SetTextColor(m_primary. RGB<0xFF. OxFF. 0)); Text0ut(m_primary. rect.left+24. rect.top+4. Продолжение^
1022 Глава 18. DirectDraw и непосредственный режим Direct3D Листинг 18.3. Продолжение temp. _tcslen(temp)); m_primary.ReleaseDC(); void OnDraw(void) { SetClientRect(m_hWnd); int n = min(m_rcDest.right-m_rcDest.left. m_rcDest.bottom-m_rcDest.top)/2; for (int i=0; i<n; i++) { DWORD color = m_priтагу.ColorMatch( OxFF*(n-l-i)/(n-l). OxFF*(n-l-i)/(n-l). OxFF*i/(n-l) ); m_priтагу.Fill Col or(m_rcDest.left+i. m_rcDest.top+i. m_rcDest.right-i. m_rcDest.bottom-i. color): LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam, LPARAM IParam) { switch( uMsg ) { case WM_CREATE: m_hWnd = hWnd; if ( FAILED(SetupDirectDraw(GetParent(hWnd). hWnd. false)) ) { MessageBox(NULL. _T("Unable to Initialize DirectDraw"). JCKDDWin"). MB_OK); CloseWindow(hWnd): } return 0; case WM_PAINT: OnDrawO; ValidateRect(hWnd. NULL): return 0; case WMJCPAINT: DefWindowProc(hWnd. uMsg. wParam. IParam): OnNCPaintO: return 0; case WM_DESTR0Y: PostQuitMessage(O): return 0: default: return DefWindowProcChWnd. uMsg. wParam. IParam); void GetWndClassExCWNDCLASSEX & wc)
Построение графической библиотеки DirectDraw 1023 { KWindow::GetWndClassEx(wc); wc.style |= (CSJREDRAW | CSJREDRAW): } } Класс KDDWin объявлен производным от классов KWindow и KDirectDraw. Поддержка DirectDraw инициализируется в обработчике сообщения WM_CREATE вызовом метода KDirectDraw: :SetupDirectDraw. Обработчик сообщения WMPAINT использует метод KDDSurface:: Fill Col or для заполнения клиентской области окна прямоугольниками, цвет которых постепенно изменяется от желтого к синему. Этот пример иллюстрирует вывод с аппаратным ускорением с использованием IDirectDraw7: :Blt. Обработчик WMNCPAINT рисует фон заголовка окна функцией Pixel Fill Rect и при помощи функции вывода текста GDI выводит в заголовке строку с описанием формата первичной поверхности (рис. 18.2). Этот простой класс показывает, как легко включить поддержку DirectDraw в обычной оконной программе при помощи классов KDirectDraw и KDDSurface, а также демонстрирует три способа вывода на поверхности DirectDraw. Рис. 18.2. Простой пример вывода DirectDraw в оконном режиме Построение графической библиотеки DirectDraw Как говорилось в предыдущем разделе, DirectDraw поддерживает всего два метода вывода с аппаратным ускорением, Bit и BltFast, позволяющие заполнять прямоугольные участки однородным цветом и копировать фрагменты изображений между поверхностями DirectDraw. Более сложные графические запросы приходится разбивать на серии Blt/BltFast, использовать прямой доступ к пикселам фиксированной поверхности или прибегать к помощи GDI. DirectDraw хорошо подходит для переноса в Windows игровых DOS-программ, которые обычно работают с обширными графическими библиотеками, ограничивающимися прямым доступом к пикселам. Если тексты графической библиотеки недоступны, вам придется строить свою собственную библиотеку или возвращаться к GDI.
1024 Глава 18. DirectDraw и непосредственный режим Direct3D В этом разделе мы рассмотрим пример построения простейшей библиотеки DirectDraw, поддерживающей операции с пикселами, заполнение замкнутых фигур, вывод линий, текста, простых и прозрачных растров. Вывод пикселов Когда поверхность DirectDraw фиксируется в памяти, программа получает указатель на ее кадровый буфер. Вывод пиксела сводится к простому определению его позиции в кадровом буфере и копированию нескольких байтов. Фиксация и освобождение поверхностей DirectDraw связаны с дорогостоящими вызовами системных функций; мы не можем себе позволить такие затраты для каждого пиксела поверхности. Следовательно, архитектура графической библиотеки должна позволять приложению один раз зафиксировать поверхность и вывести сразу несколько пикселов перед ее освобождением. Ниже приведен родовой класс, который обеспечивает фиксацию/освобождение поверхностей DirectDraw и организует прямой доступ к пикселам. class KLockedSurface { public: BYTE * pSurface; int pitch; i nt bpp; bool Initialize(KDDSurface & surface) { pSurface - surface.LockSurface(NULL); pitch = surface.GetPitchO; bpp = surface.GetSurfaceDesc()->ddpfPi xelFormat.dwRGBBi tCount; return pSurface!=NULL; BYTE & ByteAtCint x. int y) BYTE * pPixel - (BYTE *) (pSurface + pitch * y). return pPixel[x]; WORD & WordAt(int x. int y) WORD * pPixel = (WORD *) (pSurface + pitch * y); return pPixel[x]; RGBTRIPLE & RGBTripleAt(int x. int y) RGBTRIPLE * pPixel - (RGBTRIPLE *) (pSurface + pitch * y); return pPixel[x]:
Построение графической библиотеки DirectDraw 1025 DWORD & DWordAtdnt x. int у) { DWORD * pPixel - (DWORD *) (pSurface + pitch * y); return pPixel[x]; BOOL SetPixel(int x, int y, DWORD color) { switch ( bpp ) case 8 case 15 case 16 case 24 case 32 default } return TRUE; ByteAUx. y) - (BYTE) color WordAt(x, y) - (WORD) color RGBTripleAt(x, y) = * (RGBTRIPLE *) & color; break DWordAt(x. y) - (DWORD) color return FALSE; break; break; break; DWORD GetPixeKint x. int у); //Не приводится void Line(int xO. int yO. int xl. int yl. DWORD color); }: В классе KLockedSurface зафиксированная поверхность представлена тремя переменными: указателем на кадровый буфер, смещением соседних строк развертки и цветовой глубиной пикселов. Метод Initialize фиксирует поверхность DirectDraw и присваивает значения этим переменным. Четыре подставляемых (in-line) метода — ByteAt, WordAt, RGBTripleAt и DWordAt — превращают кадровый буфер в двумерный массив с произвольным доступом. Эти методы обеспечивают чтение и запись 8-, 16-, 24- и 32-разрядных пикселов поверхности. Метод KLockedSurface: : SetPixel обеспечивает обобщенный вывод пикселов поверхности, по аналогии с одноименной функцией GDI. Метод KLockedSurface: -.GetPixel выполняет обобщенное чтение пикселов. Ниже приведен пример использования класса KLockedSurface для реализации метода SetPixel в классе KDDSurface. BOOL KDDSurface-SetPixel(int x. int y. DWORD color) { KLockedSurface frame; if ( frame.Initialize(* this) ) { frame.SetPixel(x. y. color); UnlockO; return TRUE; } else return FALSE; } Чтобы класс обладал достаточно высоким быстродействием, вывод нескольких пикселов должен выполняться за одну фиксацию поверхности. Класс KLockedSurface позволяет использовать при выводе пикселов логические или другие растровые операции. Примеры:
1026 Глава 18. DirectDraw и непосредственный режим Direct3D ByteAtCx. у) |= (BYTE) color; // R2_MERGEPEN WordAtCx. у) "= (DWORD) color; // R2J0RPEN DwordAt(x. y) = 0; // R2_BLACK ByteAtCx. y) = ((ByteAt(x-l. y) + ByteAtCx. y-1). (ByteAt(x+l. y) + ByteAtCx. y+D) / 4; // Размытие Обратите внимание на отсутствие отсечения или проверки границ в классе KLockedSurface. Предполагается, что приложение передает предварительно отсеченные координаты. Приведенная ниже функция рисует на поверхности пикселы. void PixelDemo(void) { KLockedSurface frame; if ( ! frame.Initialize(m_primary) ) return; for (int i=0; i<4096: i++) frame.SetPixeK m_rcDest.left + randO % ( m_rcDest.right - m_rcDest.left). m_rcDest.top + rand О % ( m_rcDest.bottom - m_rcDest.top). m_primary.ColorMatch(rand(n256. rand()*256. rand()*256): m_primary.Unlock(); Вывод линий Любую кривую можно разбить на отрезки, вывод которых поддерживается примитивами любой графической библиотеки. При выводе кривых часто применяется алгоритм Брезенхэма (Bresenham), опубликованный в 1965 году. В алгоритме Брезенхэма линии аппроксимируются пикселами дискретной сетки с использованием итеративного процесса, работа которого зависит от накапливаемой погрешности. По погрешности алгоритм определяет, нужно ли при переходе к следующему пикселу обновлять координаты по обеим осям х и у или только по одной оси. При переходе к следующему пикселу погрешность обновляется в соответствии с отклонением аппроксимирующего пиксела от настоящей линии. Алгоритм Брезенхэма хорош тем, что он обходится без дорогостоящих операций умножения и деления (если не считать удвоение величины за умножение). Ниже приведена реализация алгоритма Брезенхэма в классе KLockedSurface. void KLockedSurface::Line(int xO, int yO. int xl. int yl. DWORD color) { int bps = (bpp+7) / 8: // Байт на пиксел BYTE * pPixel = pSurface + pitch * yO + bps * xO; // Адрес первого пиксела int error; // Погрешность int d_pixel_pos, d_error_pos; // Поправки для error>=0 int d_pixel_neg, d_error_neg; // Поправки для error<0 int dots: // Количество выводимых точек { int dx. dy. inc_x. inc_y; if ( xl > xO ) { dx = xl - xO; inc_x = bps; } else
Построение графической библиотеки DirectDraw 1027 { dx = хО - xl; inc_x = -bps; } if ( yl > уО ) { dy = yl - yO; inc_y = pitch; } else { dy = yO - yl; inc_y = -pitch; } d_pixel_pos = inc_x + inc_y; // Переместить х и у d_error_pos = (dy - dx) * 2; if ( d_error_pos < 0 ) // x dominant { dots = dx; error = dy*2 - dx; d_pixel_neg = inc_x; // Перемещение только по оси х d_error_neg = dy * 2; } else { dots = dy: error = dx*2 - dy; d_error_pos = - d_error_pos; d_pixel_neg = inc_y; // Перемещение только по оси у d_error_neg = dx * 2: switch ( bps ) { case 1: // Цикл для 8-разрядных пикселов. См. CD-ROM case 2: // Цикл для 16-разрядных пикселов. См. CD-ROM case 3: // Цикл для 24-разрядных пикселов. См. CD-ROM break; case 4: for (; dots>=0; dots--) // Цикл для 32-разрядных пикселов { * (DWORD *) pPixel = color; // Вывести 32-разрядный пиксел if ( error>=0 ) { pPixel += d_pixel_pos; error += d_error_pos; } else { pPixel += d_pixel_neg; error += d_error_neg; } } break; Метод KLockedSurface: :Line делится на две части: фазу начальной настройки и цикл вывода пикселов. В фазе начальной настройки задается адрес первого пиксела, количество выводимых пикселов, начальная погрешность, поправки адреса пиксела и погрешности. Цикл вывода поддерживает все стандартные форматы пикселов поверхностей. Для каждого формата программа в цикле устанавливает значение пиксела и переходит к следующему пикселу, выбранному в зависимости от погрешности. Для повышения быстродействия вычисление адреса пиксела оформлено «на месте». Практически все ранние графические библиотеки для игровых DOS-программ были написаны на ассемблере. Впрочем, и в наши дни встречается немало книг,
1028^ Глава 18. DirectDraw и непосредственный режим Direct3D рекомендующих программировать графические примитивы на ассемблере. Если вам доводилось просматривать ассемблерный код, сгенерированный современным компилятором, и вы уверены, что справитесь лучше — что ж, попробуйте... но учтите, что неоптимизированный ассемблерный код замедлит работу вашей программы. Если вы хотите посмотреть, на что способен компилятор, сгенерируйте листинги с командами C/C++ и ассемблерным кодом. Вот как выглядит цикл вывода 32-разрядных пикселов, обработанный компилятором VC 6.0: II II II II II II II _repeat: _elsepart _next: eax ebx есх edx esi edi ebp test jl mov inc test mov Jl add add jmp : add add dec jne : color : dots : error : pPixel : d_error_pos : d_error_neg : d_pixel_neg ebx. ebx _finish eax. color ebx ecx. ecx [edx], eax _elsepart edx, d_pixel_pos ecx. esi _next edx. ebp ecx. edi ebx _repeat if ( dots < 0 ) goto _finish; eax = color dots ++; * (DWORD *) pPixel = color; if ( error<0 ) goto _elsepart; pPixel +« d_pixel_pos error +=d_error_pos goto jnext pPixel +- d_pixel_neg error +- d_error_neg dots--; if ( dots!=0 ) goto_repeat На процессоре Intel, работающем в 32-разрядном режиме, имеется 7 регистров общего назначения, которые могут использоваться компилятором. В нашем цикле вывода, определяющем быстродействие вывода линий, компилятору хватило «ума» задействовать все 7 регистров. Места не осталось лишь для одного важного значения — dj)ixe1_pos. В цикле вывода используются всего две операции, операндами которых не являются регистры, — обращение к d_pixe1_pos и запись пиксела в кадровый буфер. Компилятор отделяет инструкцию проверки от последующего относительного перехода, чтобы «включились» оба конвейера обработки инструкций. Метод KLockedSurface::Line можно расширить для вывода стилевых линий, линий с растровыми операциями и даже с альфа-наложением. Впрочем, более толстые линии следует преобразовывать в заливки замкнутых фигур. Также предполагается, что координаты предварительно прошли отсечение. Ниже приведен пример использования метода Line. void LineDemo(KDDSurface & surface, int x, int y. int Radius) { const int N =19; const double theta - 3.1415926 * 2 / N; const COLORREF color[10] - { RGB(0. 0. 0). RGB(255,0,0). RGB(0.255.0). RGBC0.0. 255). RGB(255.255.0). RGB(0. 255. 255). RGBC255. 255. 0).
Построение графической библиотеки DirectDraw 1029 RGBC127. 255. 0). RGB(0. 127, 255). RGBC255. 0. 127) }: DWORD dwColor[10]: for (int i=0; i<10; i++) dwColor[i] = surface.ColorMatch(GetRValue(color[i]). GetGValue(color[i]) GetBValue(color[i])): KLockedSurface frame; if ( frame.Inistialize(m_priтагу) ) { for (int p=0; p<N; p++) for (int q=0; q<p; q++) frame.Line( (int)(x + Radius * sin(p * theta)). (int)(y + Radius * cos(p * theta)). (int)(x + Radius * sin(q * theta)). (int)(y + Radius * cos(q * theta)). dwColor[min(p-q. N-p+q)]); m_primary.Unlock(); Заливка замкнутых областей DirectDraw поддерживает заливку прямоугольных областей однородным цветом. Непрямоугольные области приходится разбивать на прямоугольные участки или преобразовывать в регионы отсечения. Ниже приведена реализация метода KDDSurface::FillRgn, закрашивающего произвольный регион однородным цветом. RGNDATA * GetCli pRegionData(HRGN hRgn) { DWORD dwSize - GetRegionData(hRgn. 0. NULL); RGNDATA * pRgnData - (RGNDATA *) new BYTE[dwSize]; if ( pRgnData ) GetRegionData(hRgn. dwSize. pRgnData); return pRgnData; } BOOL KDDSurface::Fi1IRgnCHRGN hRgn. DWORD color) { RGNDATA * pRegion = GetClipRegionData(hRgn); if ( pRegion==NULL ) return FALSE; const RECT * pRect - (const RECT *) pRegion->Buffer; for (unsigned i=0; i<pRegion->rdh.nCount; i++) { \ Fi11 Color(pRect->left. pRect->top. pRect->right. pRect->bottom. color); pRect ++; } delete [] (BYTE *) pRegion; return TRUE;
1030 Глава 18. DirectDraw и непосредственный режим Direct3D GDI содержит немало разнообразных функций регионов, позволяющих выводить простые геометрические фигуры и их комбинации, создавать замкнутые траектории и даже контуры текста. В программах DirectDraw рекомендуется опираться на поддержку регионов в GDI. Если быстродействие особенно важно, данные регионов можно обсчитывать заранее и кэшировать. Метод KDDSurface: :FillRgn получает манипулятор объекта региона GDI; он разбивает регион на серию прямоугольников (структура RGNDATA) функцией Get- RegionData GDI, после чего закрашивает каждый прямоугольник однородным цветом при помощи метода IDirectDrawSurface7: .-Bit с учетом состояния текущего объекта отсечения DirectDraw. Возможна и другая реализация — преобразовать список отсечения текущего объекта отсечения DirectDraw в регион GDI, получить его пересечение с выводимым регионом, создать новый список отсечения и вывести результат методом Bit. Недостаток подобного решения заключается в том, что вам придется создать второй объект отсечения DirectDraw и организовать переключение объекта отсечения и поверхности. В следующем примере на поверхности DirectDraw рисуется однородный эллипс: void RegionDemo(void) { HRGN hRgn = CreateEllipticRgnIndirect(& m_rcDest); if ( hRgn ) { m jdMтагу.Fi11Rgn(hRgn. m_primary.ColorMatch(OxFF, OxFF, 0)); DeleteObject(hRgn); } } На рис. 18.3 изображено дочернее окно MDI, в котором средствами DirectDraw нарисованы пикселы, линии и эллипс. ~С> Н^; f-i% ЛИ Рис. 18.3. Пикселы, линии и фигуры на поверхности DirectDraw
Построение графической библиотеки DirectDraw 1031 Отсечение Поверхности DirectDraw поддерживают отсечение с использованием объектов отсечения DirectDraw, создаваемых методом IDirectDraw::Createdipper. Объекты отсечения DirectDraw делятся на две категории: ассоциированные с окном и созданные на базе списка отсечения. Когда объект отсечения ассоциируется с окном методом IDirectDrawClipper:: SetHWnd, операционная система неким волшебным образом следит за тем, чтобы объект отсечения всегда синхронизировался с обновляемым регионом конкретного окна. Следовательно, вывод на поверхности DirectDraw с присоединенным объектом отсечения может ограничиваться видимой частью клиентской области. Мы уже видели, как объекты отсечения обеспечивают правильность работы метода Bit в оконном режиме. Приложение также может напрямую управлять объектом отсечения DirectDraw, изменяя содержимое его списка отсечения, который представляет собой обычную структуру RGNDATA GDI. В документации DirectX предполагается, что программисты DirectX достаточно хорошо разбираются в программировании GDI, поэтому в ней почти ничего не говорится о том, как правильно работать со списками отсечения. Приведенные ниже функция и класс связывают объект региона GDI с объектом отсечения DirectDraw. BOOL SetClipRegion(IDirectDrawClipper * pClipper. HRGN hRgn) { RGNDATA * pRgnData = GetClipRegionData(hRgn); if ( pRgnData==NULL ) return FALSE; HRESULT hr = pClipper->SetClipList(pRgnData. 0): delete (BYTE *) pRgnData; return SUCCEEDED(hr); } class KRgnClipper { IDirectDrawClipper * m_pNew; IDirectDrawClipper * m_p01d; IDirectDrawSurface7 * m_pSrf; public: KRgnClipper(IDirectDraw7 * pDD. IDirectDrawSurface7 * pSrf. HRGN hRgn) { pDD->CreateClipper(0. & rn_pNew. NULL); // Создать объект отсечения SetClipRegion(m_pNew. hRgn);// Получить список отсечения // по данным региону m_pSrf = pSrf; pSrf->GetClipper(& m_p01d); // Получить старый объект отсечения pSrf->SetClipper(m_pNew); // Заменить новым объектом отсечения
1032 Глава 18. DirectDraw и непосредственный режим Direct3D } -KRgnClipperО { m_pSrf->SetClipper(m_p01d); // Восстановить старый объект отсечения m_p01d->Release(); // Освободить старый объект отсечения m_pNew->Release(); // Освободить новый объект отсечения } }: Функция SetClipper заполняет список отсечения объекта отсечения DirectDraw данными объекта региона GDI. Для получения данных она вызывает функцию GetRegionData GDI по манипулятору региона. Как говорилось выше, поскольку данные региона имеют переменный размер, функция должна вызываться дважды — сначала вы получаете размер данных, выделяете память, а затем получаете сами данные. Класс KRgnClipper заменяет объект отсечения, связанный с поверхностью DirectDraw, новым объектом отсечения, созданным по данным объекта региона GDI. Конструктор создает новый объект отсечения, заполняет его список отсечения данными региона GDI и заменяет текущий объект отсечения, связанный с поверхностью. При всех последующих операциях вывода используется новый объект отсечения. Деструктор восстанавливает исходный объект отсечения и освобождает ресурс. В приведенной ниже функции класс KRgnClipper используется для заливки областей. void ClipDemo(void) { HRGN hUpdate = CreateRectRgn(0. 0. I, l); GetUpdateRgn(m_hWnd. hUpdate. FALSE); // Обновляемый регион OffsetRgn(hUpdate. m_rcDest.left. m_rcDest.top); // Экранные координаты HRGN hEl1 ipse = CreateEllipticRgn(m_rcDest.left-20. // Большой эллипс mjrDest.top-20. m_rcDest.nght+20. m_rcDest.bottom+20); CombineRgn(hEllipsef hEl1 ipse, hUpdate. RGN_AND); // Обновляемый регион AND эллипс DeleteObject(hUpdate); KRgnClipper clipper(m_pDD, m_primary. hEl1 ipse); DeleteObject(hEllipse); m_priтагу.Fi11 Color(m_rcDest.1eft-20. m_rcDest.top-20. m_rcDest.right+20, m_rcDest.bottom+20. m_primary.ColorMatch(0. 0. OxFF)); } Функция ClipDemo запрашивает обновляемый регион текущего окна и преобразует его из клиентских координат в экранные, как того требует DirectDraw. Затем функция создает эллиптический регион, размеры которого превышают размеры клиентской области, находит его пересечение с обновляемым регионом и определяет новую область отсечения. Метод KDDSurface:: Fill Color использует-
Построение графической библиотеки DirectDraw 1033 ся для заполнения области, большей клиентской части окна, но благодаря отсечению вывод ограничивается как границами эллипса, так и обновляемым регионом. Внеэкранные поверхности Как показывает метод KDDSurface: :DrawBitmap, для вывода растра на поверхности DirectDraw проще всего воспользоваться функциями GDI. Хотя данные растра можно самостоятельно скопировать на зафиксированную поверхность DirectDraw, для обработки сжатия, поддержки разных форматов растров, масштабирования и палитры, а также преобразования формата пикселов вам придется написать довольно большой объем кода, а это приведет к снижению быстродействия и потере всех преимуществ DirectDraw. Правильный подход к выводу растров в DirectDraw использует преимущества как GDI, так и DirectDraw. Сначала растр загружается на внеэкранную поверхность средствами GDI, а затем выводится на главную поверхность средствами DirectDraw. Создание внеэкранной поверхности и загрузка растра обеспечиваются классом KOffscreenSurfасе, производным от KDDSurface. typedef enum { mem_default. mem_system. memjnonloca1 video. memj oca 1 video }: class KOffScreenSurface : public KDDSurface { public: HRESULT Create0ffScreenSurface(IDirectDraw7 * pDD. int width. int height, int mem=mem_default); HRESULT Create0ffScreenSurfaceBpp(IDirectDraw7 * pDD. int width. int height, int bpp. int mem=mem_default): HRESULT CreateBitmapSurface(IDirectDraw7 * pDD. const BITMAPINFO * pDIB. int mem=mem_default); HRESULT CreateBitmapSurface(IDirectDraw7 * pDD. const TCHAR * pFileName. int mem=mem_default); }: const DWORD MEMFLAGS[] = { 0. DDSCAPSJYSTEMMEMORY. DDSCAPSJIONLOCALVIDMEM | DDSCAPSJ/IDEOMEMORY. DDSCAPS_LOCALVIDMEM | DDSCAPSJ/IDEOMEMORY }: HRESULT KOffScreenSurface::Create0ffScreenSurface(IDirectDraw7 * pDD. int width, int height, int mem)
1034 Глава 18. DirectDraw и непосредственный режим Direct3D { m_ddsd.dwFlags = DDSD_CAPS | DDSDJEIGHT | DDSD_WIDTH; m_ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE | MEMFLAGS[mem]; m_ddsd.dwWidth = width; m_ddsd.dwHeight = height; return pDD->CreateSurface(& m_ddsd, & m_pSurface. NULL); } HRESULT K0ffScreenSurface::CreateBitmapSurface(IDirectDraw7 * pDD. const BITMAPINFO * pDIB. int mem) { if ( pDIB==NULL ) return E_FAIL; HRESULT hr = CreateOffScreenSurface(pDD. pDIB->bmiHeader.biWidth, abs(pDIB->bmiHeader.biHeight). mem); if ( FAILED(hr) ) return hr; return DrawBitmapCpDIB. 0, 0, m_ddsd.dwWidth. m_ddsd.dwHeight); } Метод CreateOffScreenSurface создает внеэкранную поверхность DirectDraw, то есть поверхность, хранящуюся в памяти, но не отображаемую на экране монитора. Память для внеэкранной поверхности может выделяться из системной памяти, локальной или нелокальной видеопамяти в зависимости от флагов поля ddsCaps.dwCaps. Системной памяти хватает в избытке, поскольку ее объем ограничивается только размером системного файла подкачки. К нелокальной видеопамяти относится память, находящаяся под управлением AGP (Advanced Graphics Port) — механизма, обеспечивающего ускоренное копирование данных в видеопамять. По сравнению с системной памятью нелокальная память является более ограниченным ресурсом, но вывод из нее происходит быстрее. Локальная видеопамять является самым дорогим и редким из всех видов памяти. Кстати, при прямом доступе к пикселам из приложения локальная видеопамять оказывается самой медленной, поскольку она расположена «дальше» от процессора. Последний параметр CreateOffScreenSurface показывает, откуда выделяется память поверхности. В отличие от первичной поверхности, при создании внеэкранных поверхностей необходимо указывать их точный размер. Метод CreateOffScreenSurfaceBpp, реализация которого здесь не приводится, позволяет создать внеэкранную поверхность с заданным форматом пикселов. Первый метод CreateBitmapSurface в качестве входных данных получает упакованный DIB-растр. Он создает внеэкранную поверхность по размерам растра, а затем копирует растр на поверхность средствами GDI. Второй метод CreateBitmapSurface, который здесь также не приводится, создает поверхность и загружает в нее растр из внешнего файла. Оба метода используют DIB, что обеспечивает экономию ресурсов по сравнению с DDB-растрами и DIB-секциями, активно рекомендуемыми в литературе по DirectX.
Построение графической библиотеки DirectDraw 1035 После того как растр загружен на внеэкранную поверхность, его можно скопировать на другую поверхность методом IDirectDrawSurface7: :Blt. Класс KDDSurface содержит два метода BitBlt, которые представляют собой простые оболочки для метода Bit, чтобы вызовы больше походили на вызовы функций GDI. Ниже приведена одна из этих оболочек. HRESULT KDDSurface::BitBlt(int x. int у. int w. int h, IDirectDrawSurface7 * pSrc. DWORD flag) { RECT re = { x. y. x+w. y+h }; return m_pSurface->Blt(& re, pSrc. NULL, flag. NULL); } Поддержка прозрачности посредством цветовых ключей Метод IDirectDrawSurface7: :Blt поддерживает вывод прозрачных растров с использованием цветовых ключей. Цветовой ключ является атрибутом поверхности DirectDraw и может задаваться как для исходной, так и для приемной поверхностей. Цветовой ключ, который может представлять собой как отдельный цвет, так и интервал цветов, определяется структурой DDC0L0RKEY. Ниже приведен метод SetSourceCol огКеу класса KDDSurface, задающий цветовой ключ источника с использованием одного физического цвета. HRESULT KDDSurface::SetSourceColогКеу(DWORD color) { DDCOLORKEY key: key.dwColorSpaceLowValue = color; key.dwColorSpaceHighValue = color; return m_pSurface->SetColorKey(DDCKEY_SRCBLT. & key); } Чтобы скопировать внеэкранную растровую поверхность с цветовым ключом источника, вызовите метод Bit с флагом DDBLTKEYSRC. При этом копируются только те пикселы, значения которых отличны от цветового ключа источника. В DirectDraw также поддерживаются цветовые ключи приемника. Шрифт и текст DirectX как простой низкоуровневый интерфейс API, оптимизированный для максимального быстродействия, не обладает встроенной поддержкой шрифтов или вывода текста. Даже реализация OpenGL для Windows работает со шрифтами при помощи специальных расширений. Если вы задействуете средства GDI для операций со шрифтами и вывода текста на поверхностях DirectDraw, можно подумать и об использовании контекста устройства GDI. Однако в играх и приложениях, требующих высокого быстродействия, применение медленных функций GDI неприемлемо. В играх часто встречается другой вариант — программа заранее строит растр с полным
1036 Глава 18. DirectDraw и непосредственный режим Direct3D набором требуемых глифов (назовем его шрифтовым растром). Вместо шрифта программа работает с растром, а вывод текста сводится к копированию фрагментов шрифтового растра. Слабой стороной такого решения является недостаточная гибкость, поскольку программа задействует ограниченный набор шрифтов заданного размера. Оптимальное решение, как и прежде, объединяет два подхода — GDI и шрифтовые растры. Идея заключается в том, чтобы динамически построить шрифтовые растры для заданной гарнитуры и кегля, а затем воспользоваться методами DirectDraw для вывода текста из шрифтовых растров. Шрифтовые растры строятся только при загрузке приложения, что расширяет выбор гарнитур и кеглей без особой потери быстродействия. Шрифтовые растры даже можно кэшировать в растровых файлах на диске и загружать на внеэкранные поверхности (вероятно, в локальную видеопамять для максимального быстродействия) методом Bit, поддерживающим аппаратное ускорение. В листинге 18.4 приведен класс KDDFont, поддерживающий работу с динамически сгенерированными шрифтовыми растрами на внеэкранных поверхностях. Листинг 18.4. Класс KDDFont: работа с динамическими шрифтовыми растрами и вывод текста template <int MaxChar> class KDDFont : public KOffScreenSurface { int m_offset [MaxChar]; // Метрика А int m_advance[MaxChar]; // A + В + С int m_pos [MaxChar]; // Горизонтальная позиция int m_width [MaxChar]; // - min(A. 0) + В - min(C.O) unsigned m_firstchar; int mjiChar; public: HRESULT CreateFont(IDirectDraw7 * pDD. const L0GF0NT & If. unsigned firstchar. unsigned lastchar, C0L0RREF crColor); int Text0ut(IDirectDrawSurface7 * pSurface, int x. int y, const TCHAR * mess, int nChar=0); }: template <int MaxChar> HRESULT KDDFont<MaxChar>;:CreateFont(IDirectDraw7 * pDD. const L0GF0NT & If. unsigned firstchar. unsigned lastchar. C0L0RREF crColor) { m_firstchar = firstchar; mjiChar = lastchar - firstchar + 1; if ( mjiChar > MaxChar ) return E INVALIDARG; HFONT hFont - CreateFontIndirect(&lf);
Построение графической библиотеки DirectDraw 1037 if ( hFont==NULL ) return EJNVALIDARG; HRESULT hr; ABC abc[MaxChar]: int height; { HDC hDC - ::GetDC(NULL); if ( hDC ) { HGDIOBJ hOld « SelectObjectChDC. hFont); TEXTMETRIC tm: GetTextMetrics(hDC. & tm); height = tm.tmHeight: if ( GetCharABCWidths(hDC. firstchar. lastchar. abc) ) hr - S_OK; else hr = E INVALIDARG; SelectObject(hDC. hOld); ::ReleaseDC(NULL. hDC); } if ( SUCCEEDED(hr) ) { int width = 0; for (int i=0; i<m_nChar; i++) { m_offset[i] = abc[i].abcA; m_width[i] » - min(abc[i].abcA. 0) + abc[i].abcB - min(abc[i].abcC. 0); m_advance[i] = abc[i].abcA + abc[i].abcB + abc[i].abcC: width += m width[i]; hr = CreateOffScreenSurface(pDD. width, height): if ( SUCCEEDED(hr) ) { GetDCO; int x = 0; PatBltCm hDC. 0. 0. GetWidthO. GetHeightO. BLACKNESS); SetBkMode(m_hDC. TRANSPARENT); SetTextColor(m_hDC. crColor); // Белый основной цвет Продолжение^
1038 Глава 18. DirectDraw и непосредственный режим Direct3D Листинг 18.4. Продолжение HGDIOBJ hOld = SelectObject(m_hDC. hFont); SetTextAlign(m_hDC. TA_TOP | TA_LEFT); for (int i=0; i<m_nChar; i++) { TCHAR ch = firstchar + i; m_pos[i] = x; ::TextOut(m_hDC. x-m_offset[i], 0. & ch. 1); x += m_width[i]; } SelectObject(m_hDC. hOld); ReleaseDCO; SetSourceColorKey(O); // Цветовой ключ источника - черный } } Del eteObjecK hFont); return hr; }: tempiate<int MaxChar> int KDDFont<MaxChar>::Text0ut(IDirectDrawSurface7 * pDest, int x, int y, const TCHAR * mess, int nChar) { if ( nChar<=0 ) nChar = Jxslen(mess); for (int i=0; i<nChar; i++) { int ch = mess[i] - m_firstchar; if ( (ch<0) || (ch>m_nChar) ) ch = 0; RECT dst - { x + m_offset[ch]. y. x + m_offset[ch] + m_width[ch]. у + GetHeightO }; RECT src = { m_pos[ch]. 0. m_pos[ch] + m_width[ch]. GetHeightO }; pDest->Blt(& dst. m_pSurface. & src. DDBLT_KEYSRC. NULL); x += m_advance[ch]; } return x; } Класс KDDFont рассчитан на поддержку обобщенных шрифтов, предоставляемых GDI. Выражаясь точнее, он поддерживает моноширинные и пропорциональные шрифты и текстовые метрики ABC. Класс KDDFont добавляет к классу KOffScreenSurface новые поля. В массиве m_offset хранятся метрики А всех гли-
Построение графической библиотеки DirectDraw 1039 фов; массив m_advance задает смещения следующих символов; массив m_pos содержит горизонтальную позицию каждого глифа на поверхности, а в массиве m_width хранятся значения ширины глифов. Класс преобразует интервал символов шрифта в шрифтовой растр (первый и последний символы интервала хранятся в отдельных переменных). Максимальное количество символов определяется параметром шаблона. Метод KDDFont: :CreateFont инициализирует шрифтовой растр по исходным данным — указателю на объект IDirectDraw7, структуре LOGFONT GDI, интервалу символов и цвету текста. Он создает логический шрифт GDI по структуре LOGFONT и запрашивает метрики ABC, на основе которых заполняются четыре массива. В результате вычислений определяется ширина и высота шрифтового растра, после чего создается внеэкранная поверхность DirectDraw. Очистка растра и вывод в нем всех глифов осуществляются средствами GDI. К сожалению, мы не можем преобразовать все символы интервала в строку и вывести их одним вызовом функции, поскольку в строке символы могут перекрываться по горизонтали. Каждый символ рисуется отдельно в заранее вычисленной позиции растра. Символы выводятся на черном фоне, и черный цвет назначается цветовым ключом шрифтовой поверхности. Метод KDDFont: :TextOut использует содержимое поверхности шрифтового растра для вывода строки символов на поверхности DirectDraw. Для поиска глифов и их выравнивания в строке задействуются четыре массива, хранящихся в переменных класса KDDFont. Каждый символ выводится в прозрачном режиме с цветовым ключом источника (шрифтовой поверхности) методом IDirectDrawSurface7: :Blt. Метод TextOut выводит текст с цветовым ключом, заданным при создании шрифтовой поверхности. Класс KDDFont можно дополнить методами, изменяющими цвет текста или выводящими текст с применением специальных эффектов. Шрифтовую поверхность можно сохранить в растре и в дальнейшем обойтись без повторных вызовов GDI. Возможны и другие усовершенствования — скажем, разделение глифов дополнительными интервалами. Спрайты Многие игровые программы основаны на использовании простых и прозрачных растров. Прозрачные растры, называемые в играх спрайтами, изображают различные перемещающиеся объекты, при соприкосновении которых в игре происходят те или иные события. Для управления перемещением спрайтов в играх задействуется клавиатура, мышь или другое устройство ввода. Ниже приведена псевдоигровая программа для DirectDraw, иллюстрирующая вывод растров, спрайтов и текста на поверхности DirectDraw. class KSpriteDemo : public KMDIChiId. public KDirectDraw { KOffScreenSurface m_background; POINT m_backpos; KOffScreenSurface m_sprite; POINT m_spntepos; KDDFont<128> m_font; HINSTANCE m hlnst;
1040 Глава 18. DirectDraw и непосредственный режим Direct3D HWND m_hTop; void OnDraw(void): void OnCreate(void): void MoveSprite(int dx. int dy) { m_spritepos.x +- dx * 5; m_spritepos.y += dy * 5; OnDraw(): LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM IParam) { switch( uMsg ) case WM_PAINT: OnDraw(); ValidateRect(hWnd. return 0; case WM_KEYDOWN: switch ( wParam ) { case VKJOME case VK_UP case VK_PRIOR case VK_LEFT : case VK_RIGHT: case VKJND case VK_DOWN case VK NEXT NULL); MoveSprite(-l MoveSprite( 0 MoveSprite(+l MoveSprite(-l MoveSprite( 1 MoveSprite(-l MoveSprite( 0 MoveSpriteC 1 1): 1): 1); break; break; break; 0); break: 0); break; break break break } return 0; case WM_CREATE: m_hWnd = hWnd; OnCreateO: // Продолжить default: return KMDIChild::WndProc(hWnd. uMsg, wParam. IParam); public: KSpriteDemo(HMODULE hModule. HWND hTop) m_spritepos.x m_spritepos.y m_backpos.x m backpos.y = 0 = 0 = 0 = 0
Построение графической библиотеки DirectDraw 1041 mjilnst = hModule; mJYTop = hTop; } }: Класс KSpriteDemo объявлен производным от классов KMDIChild (поддержка дочерних окон MDI) и KDirectDraw (поддержка DirectDraw). Переменные mbackground и m_backpos предназначены для управления фоновым растром, загруженным на внеэкранную поверхность DirectDraw. Размеры фонового растра могут превышать размеры окна, в этом случае организуется прокрутка окна в фоновом растре. Переменные msprite и mspritepos используются при выводе самолета поверх фоновой сцены. В переменной m_font хранится экземпляр класса KDDFont. Метод OnCreate инициализирует фоновый растр, спрайт и логический шрифт. Метод OnDraw выводит изображение в окне, а метод MoveSprite обеспечивает управление полетом с клавиатуры. Ниже приведена реализация метода OnCreate. void KSpriteDemo::OnCreate(void) { if ( SUCCEEDED(SetupDirectDraw(m_hTop. m_hWnd. false)) ) { BITMAPINFO * pDIB = LoadBMP(m_hInst. MAKEINTRESOURCE(IDBJIGHT)); if ( pDIB ) m_background.CreateBitmapSurface(m_pDD. pDIB): pDIB - LoadBMP(m_hInst. MAKEINTRESOURCECIDB_PLANE)); if ( pDIB ) { m_sprite.CreateBitmapSurface(m_pDD, pDIB): m_sprite.SetSourceColorKey(0); // Черный } LOGFONT If; memsetC&lf. 0. sizeof(lf)); lf.lfHeight = - 36; If.IfWeight - FW_B0LD; lf.lfltalic - TRUE; lf.lfQuality - ANTIALIASED_QUALITY; _tcscpy(lf.lfFaceName. "Times New Roman"); m_font.CreateFont(m_pDD. If. ' '. 0x7F. RGB(0xFF. OxFF. 0)): } else { MessageBoxCNULL. _T("Unable to Initialize DirectDraw"). JC'KSpriteDemo"). MB_0K); CloseWindow(m hWnd); Метод OnCreate инициализирует среду DirectDraw в оконном режиме, вызывая метод KDirectDraw: iSetupDirectDraw. Затем он загружает фоновое изображение из ресурса в формате упакованного DIB-растра и инициализирует поверхность фо-
1042 Глава 18. DirectDraw и непосредственный режим Direct3D нового растра. Спрайт тоже загружается из ресурса, и в качестве цветового ключа источника ему назначается черный цвет. Поверхность шрифтового растра инициализируется по структуре LOGFONT, представляющей сглаженный курсивный шрифт кегля 36 пунктов. Ниже приведена реализация метода OnDraw. void KSpriteDemo::OnDraw(void) { SetClientRect(m_hWnd); int dy = (m_rcDest.bottom - m_rcDest.top - m_background.GetHeight())/2; // Выводимая область выходит за границы фонового изображения if ( dy>0 ) { DWORD color = m_primary.ColorMatch(0x80, 0x40. 0); m_primary.Fill Col or(m_rcDest.1 eft. m_rcDest.top, m_rcDest.right. m_rcDest.top + dy. color); // Верхняя полоса color = m_priтагу.ColorMatch(0. 0x40. 0x80); m_primary.FillColor(m_rcDest.left. m_rcDest.bottom - dy-1. m_rcDest.right. m_rcDest.bottom, color); // Нижняя полоса } else dy = 0; // Вывод фонового изображения // Если правый край спрайта выходит за границу окна. // сместить фон влево while ( (m_spritepos.x + m_sprite.GetWidth() + m_backpos.x) > (m_rcDest.right - m_rcDest.left) ) m_backpos.x -* 100; // Если левый край спрайта выходит за границу окна. // сместить фон вправо while ( (m_spritepos.x + m_backpos.x) < 0 ) m_backpos.x += 100; // Убедиться, что текущая позиция фона лежит в допустимом интервале m_backpos.x = max(m_backpos.x. m_rcDest.right - m_background.GetWidth() - m_rcDest.left); m_backpos.x = min(m_backpos.x. 0); m_primary.BitBlt(m_rcDest.left + m_backpos.x. m_rcDest.top + m_backpos.y + dy. m_background); // Вывести спрайт m_primary.BitBlt(m_rcDest.left + m_spritepos.x + m_backpos.x. m_rcDest.top + m_spritepos.y + m_backpos.y. m_sprite. DDBLT_KEYSRC); m_font.TextOut(m_primary. m_rcDest.left+5. m_rcDest.top+l. "Hello. DirectDraw!"); }
Непосредственный режим Direct3D 1043 Вывод «игровой» сцены состоит из четырех этапов. На первом этапе рисуется клиентская область, не закрываемая фоновым изображением. В нашей программе используется фон в виде длинной и узкой полосы. Программа выравнивает фон по центру окна вдоль вертикальной оси, после чего заполняет полосы в верхней и нижней части окна однородными заливками. Фоновое изображение выводится на втором этапе, однако большая часть кода предназначена для вычисления новой позиции фонового изображения, при которой самолет будет виден на экране. На третьем этапе выполняется вывод прозрачной поверхности спрайта с цветовым ключом. На последнем, четвертом этапе в левой верхней части окна выводится простой фиксированный текст. Запустите программу. При помощи клавиш управления курсором можно управлять перемещением самолета по фоновому изображению с автоматической прокруткой. На рис. 18.4 показано окно программы DEMODD, использующей класс KSpriteDemo. Рис. 18.4. Вывод текста, растров и спрайтов в DirectDraw Если вы увлекаетесь программированием игр, попробуйте в виде спрайтов создать объекты вражеских самолетов, реализуйте проверку соприкосновений и стрельбу из оружия. Непосредственный режим Direct3D Хотя технология DirectDraw обеспечивает аппаратное ускорение, возможности вывода в ней весьма ограничены. При работе с DirectDraw все время кажется, что вы пишете драйвер устройства, а не прикладную программу, поскольку вам приходится принимать во внимание множество мелочей. С другой стороны, непосредственный режим Direct3D как API графического программирования обладает гораздо более широкими возможностями. В Direct3D
1044 Глава 18. DirectDraw и непосредственный режим Direct3D поддерживаются логические цвета, Z-буфер, отсечение, альфа-наложение, текстуры, области просмотра, мировые преобразования, матрицы вида, проекции, источники света, линии и треугольники, эффект тумана и т. д. Хотя непосредственный режим Direct3D проектировался как API трехмерной графики, ничто не мешает применять его pi при двумерном выводе, который просто расположен в одной плоскости трехмерного пространства. В этом разделе мы в общих чертах рассмотрим программирование для непосредственного режима Direct3D. Подготовка среды непосредственного режима Direct 3D Для работы в непосредственном режиме Direct3D вам понадобится нечто большее, чем объект DirectDraw и поверхности DirectDraw, инкапсулированные в классе KDirectDraw. Обычно для этого необходим объект Direct3D, объект Direct- 3DDevice, поверхность вывода фона и Z-буфер. Объект Direct3D управляет доступом к поддержке Direct3D. В фоновом буфере выполняется весь графический вывод, а Z-буфер управляет отсечением скрытых поверхностей. Объект Direct- 3DDevice играет роль графического устройства. В листинге 18.5 приведен класс KDirect3D, инкапсулирующий среду Direct3D. Листинг 18.5. KDIrect3D: класс среды непосредственного режима Direct3D class KDirect3D : public KDirectDraw { protected: IDirect3D7 * m_pD3D; IDirect3DDevice7 * m_pD3DDevice; KOffScreenSurface m_backsurface; KOffScreenSurface m_zbuffer; bool m_bReady; virtual HRESULT Discharge(void); virtual HRESULT OnRender(void) return S_0K; virtual HRESULT OnlnitCHINSTANCE hlnst) m_bReady = true; return S_0K: virtual HRESULT OnDischarge(void) m_bReady = false; return S OK;
Непосредственный режим Direct3D 1045 public: KDirect3D(void); ~KDirect3D(void) { Dischargee): } virtual HRESULT SetupDirectDraw(HWND hWnd. HWND hTop. int nBufferCount=0. bool bFullScreen=false, int width=0. int height=0. int bpp=0); virtual HRESULT ShowFrame(HWND hWnd): virtual HRESULT RestoreSurfaces(void); virtual HRESULT Render(HWND hWnd); virtual HRESULT ReCreate(HINSTANCE hinst virtual HRESULT OnResize(HINSTANCE hinst hWnd); HRESULT KDirect3D::SetupDirectDraw(HWND hTop. HWND hWnd. int nBufferCount. bool bFullScreen, int width, int height, int bpp) { HRESULT hr = KDirectDraw::SetupDirectDraw(hTop. hWnd. nBufferCount. bFullScreen, width, height, bpp); if ( FAILEDC hr ) ) return hr; // Устройство с 8-разрядным цветом отклоняется if ( GetDisplayBpp(m_pDD)<=8 ) return DDERRJNVALIDMODE; // Создать фоновую поверхность hr = m_backsurface.CreateOffScreenSurface(m_pDD. width, height); if ( FAILED(hr) ) return hr: // Запросить у DirectDraw доступ к Direct3D m_pDD->QueryInterface( IID_IDirect3D7. (void**) & m_pD3D ); if ( FAILED(hr) ) return hr; CLSID iidDevice - IID_IDirect3DHALDevice; // Создать Z-буфер hr - m_zbuffer.CreateZBuffer(m_pD3D, m_pDD. iidDevice. width, height); if ( FAILED(hr) ) { iidDevice - IID_IDirect3DRGBDevice; hr - m_zbuffer.CreateZBuffer(m_pD3D. m_pDD. iidDevice. width, height); } Продолжение ^> HWND hTop. HWND hWnd); int width, int height. HWND hTop. HWND
1046 Глава 18. DirectDraw и непосредственный режим Direct3D Листинг 18.5. Продолжение if ( FAILED(hr) ) return hr; // Присоединить Z-буфер к фоновой поверхности hr * m_backsurface.Attach(m_zbuffer): if ( FAILED(hr) ) return hr; hr * m_pD3D->CreateDevice( iidDevice. m_backsurface, & m_pD3DDevice ): if ( FAILED(hr) ) return hr; { D3DVIEWP0RT7 vp - { 0. 0, width, height. (float)O.O. (float)l.O }: return m_pD3DDevice->SetViewport( &vp ); } } Класс KDirect3D добавляет в KDirectDraw пять переменных: указатель на объект Direct3D7, указатель на объект Direct3DDevice7, фоновый буфер, Z-буфер и логический флаг. Процедура инициализации начинается с настройки среды DirectDraw вызовом KDirectDraw: .-SetupDirectDraw. После инициализации DirectDraw функция проверяет текущий видеорежим, и если в нем используется палитра — возвращает код ошибки. Программы Direct3D лучше всего работают в режимах High Color и True Color; режим с палитрой тоже поддерживается, но в нем действует слишком много ограничений. Вывод Direct3D чрезвычайно сложен, поэтому все операции следует выполнять на фоновой поверхности. В полноэкранном режиме можно использовать поверхности с двумя или тремя буферами, а в оконном режиме вывод осуществляется на отдельной фоновой поверхности. Функция создает внеэкранную поверхность, размеры которой совпадают с размерами клиентской области окна. Чтобы создать Z-буфер для поверхности вывода, сначала необходимо получить указатель на интерфейс IDirect3D7 объекта DirectDraw, созданного функцией DirectDrawCreateEx. Z-буфер тоже является внеэкранной поверхностью, если не считать того, что для получения информации о форматах Z-буфера, поддерживаемых текущим устройством, используется функция IDirect3D7::EnumZBufferFormats. Функция пытается создать Z-буфер для устройства с аппаратным ускорением, но в случае неудачи переключается на устройство с программной эмуляцией. Созданный Z-буфер необходимо присоединить к фоновой поверхности. Завершающая часть метода KDirect3D: .-SetupDirectDraw создает объект Direct- 3DDevice7 для фоновой поверхности и определяет область просмотра для устройства. Объект Direct3DDevice7 обеспечивает интерфейс к средствам построения трехмерных изображений, реализованных для поверхностей с включенной ЗО-поддержкой. Первые четыре поля области просмотра определяют прямоугольный участок поверхности, в котором осуществляется вывод; два последних поля определяют интервал значений в Z-буфере.
Непосредственный режим Direct3D 1047 Изменение размеров окна В оконном режиме фоновая поверхность и Z-буфер создаются по размерам клиентской области окна. Тем не менее, когда пользователь изменяет размеры окна, эти поверхности необходимо создать заново для новых размеров. Самое простое решение — уничтожить все объекты DirectDraw/Direct3D и создать их с самого начала. Ниже приведены методы удаления и повторного создания объектов среды Direct3D. HRESULT KDirect3D::Discharge(void) { SAFE_RELEASE(mj)D3DDevice); m_backsurface.Discharge(); m_zbuffer.Discharge(): SAFE_RELEASE(m_pD3D): return KDirectDraw::Discharge(); HRESULT KDirect3D::ReCreate(HINSTANCE hlnst, HWND hTop. HWND hWnd) { if ( FAILED(OnDischargeO) ) return E_FAIL: if ( FAILEDC DischargeO ) ) // Освободить все ресурсы return E_FAIL; SetClientRect(hWnd); HRESULT hr = SetupDirectDraw(hTop. hWnd. 0. false. m_rcDest.right - m_rcDest.left. m_rcDest.bottom - m_rcDest.top); if ( SUCCEEDED(hr) ) return Onlnit(hlnst); else return hr; HRESULT KDirect3D::0nResize(HINSTANCE hlnst. int width, int height. HWND hTop. HWND hWnd) { if ( ! m_bReady ) return S__0K; if ( width "(mj-cDest.right - mjxDest.left) ) if ( height—tmjrDest.bottom - m_rcDest.top) ) return S_0K; return Recreate(hlnst. hTop. hWnd):
1048 Глава 18. DirectDraw и непосредственный режим Direct3D Метод Discharge освобождает все ресурсы, связанные с объектом KDirect3D. Метод Recreate вызывает Discharge, чтобы освободить все ресурсы, а затем создает новую среду Direct3D вызовом SetupDirectDraw. Метод OnSize вызывает Recreate при изменении размеров окна. Двухэтапный вывод При использовании фоновой поверхности изображение строится в два этапа: сначала происходит вывод на фоновой поверхности, а потом результат копируется с фоновой поверхности на первичную. Аналогичная методика применяется и к объектам DirectDraw, чтобы подавить мерцание при выводе. Ниже приведены два метода, обеспечивающие двухэтапный вывод в классе KDirect3D. HRESULT KDirect3D::Render(HWND hWnd) { if ( ! m_bReady ) return S_0K; HRESULT hr - OnRenderO: if ( FAILED(hr) ) return hr; hr = ShowFrame(hWnd); if ( hr = DDERR_SURFACELOST ) return RestoreSurfacesO; else return hr; } HRESULT KDirect3D:;ShowFrame(HWND hWnd) { if ( m_bReady ) { SetClientRect(hWnd); return m_primary.Blt(& m_rcDest, m_backsurface. NULL. DDBLT_WAIT); } else return S_0K; } Метод KDirect3D:: Render сначала вызывает виртуальный метод OnRender, выполняющий фактический вывод, а затем метод ShowFrame, копирующий данные с фоновой поверхности на первичную. При запуске нескольких приложений DirectX память, выделенная для поверхности, может быть захвачена другими приложениями. Программа проверяет условие потери поверхности и восстанавливает все потерянные поверхности вызовами IDirectDrawSurface7: .-Restore.
Непосредственный режим Direct3D 1049 Использование Direct3D в окне Класс KDirect3D разрабатывался как родовой класс, который может использоваться где угодно. По этой причине обработку сообщений пришлось реализовать в отдельном классе. Ниже приведен простой класс окна, поддерживающего непосредственный режим Direct3D. class KD3DWin : public KWindow, public KDirect3DDemo { bool m_bActive; HINSTANCE m_hlnst; LRESULT WndProc(HWND hWnd. UINT uMsg. WPARAM wParam. LPARAM lParam) { switch( uMsg ) { case WM_CREATE: m_hWnd = hWnd; m_bActive = false: if ( FAILED(ReCreate(m_hInst. hWnd. hWnd)) ) CloseWindow(hWnd); SetTimer(hWnd. 101. 1. NULL); return 0; case WM_PAINT: ShowFrame(hWnd); break; case WM_SIZE: m_bActive = (SIZE_MAXHIDE!=wParam) && (SIZE_MINIMIZED!=wParam); if ( m_bActive && FAILED(OnResize(m_hInst. L0W0RD(lParam). HIWORD(lParam). hWnd. hWnd)) ) CloseWindow(hWnd); break; case WMJIMER: if ( m_bActive ) Render(hWnd); return 0; case WM_DESTR0Y: KillTimer(hWnd, 101); DischargeO; PostQuitMessage(O); return 0L; return DefWindowProcC hWnd. uMsg. wParam. lParam ); } void GetWndClassEx(WNDCLASSEX & wc)
1050 Глава 18. DirectDraw и непосредственный режим Direct3D { KWindow::GetWndClassEx(wc): wc.style |= (CSJREDRAW | CSJREDRAW); wc.hlcon = LoadIcon(m_hInst. MAKEINTRESOURCE(IDI_GRAPH)): } public: KD3DWin(HINSTANCE hlnst) { mjilnst = hlnst; } }: Класс KD3DWin объявлен производным от классов KWindow (общая поддержка окна) и KDirect3D (поддержка Direct3D). Среда Direct3D инициализируется при обработке сообщения WM_CREATE, изменяется при получении сообщения WM_SIZE и уничтожается при обработке сообщения WM_DESTROY. Обработчик WM_PAINT выводит данные с фоновой поверхности простым вызовом KDirect3D: :ShowFrame. Класс KD3DWin создает таймер, управляющий анимацией в окне. Обработчик сообщения WMJTIMER выводит новый кадр методом KDirect3D::Render. Частота поступления сообщений таймера зависит от архитектуры операционной системы. В Windows 95/98 программа получает не более 18-19 сообщений таймера в секунду; в Windows NT/2000 в секунду может поступать до 100 сообщений. Программы DirectX обычно увеличивают частоту смены кадров за счет использования пассивных циклов при обработке сообщений. С другой стороны, изменение цикла обработки сообщений главного программного потока возможно не всегда. В альтернативном решении смена кадров выделяется в отдельный программный поток. Текстурные поверхности Основные объекты, выводимые средствами Direct3D — точки, линии и треугольники, — обеспечивают вывод простейших геометрических форм в одномерном, двумерном и трехмерном пространстве. Чтобы геометрические фигуры больше походили на объекты реального мира, Direct3D позволяет накладывать текстуры на выводимые треугольники. Текстурный растр должен быть предварительно загружен на текстурную поверхность, используемую Direct3D. Текстурная поверхность представляет собой внеэкранную поверхность с загруженным растром. Для повышения быстродействия и расширения возможностей устройства Direct3D поддерживает несколько разновидностей форматов текстурных растров. Приложению остается лишь выбрать правильный формат текстуры в списке доступных форматов. Приведенный ниже метод KOffScreenSurface: :CreateTextSurface обеспечивает простейшее создание текстурных поверхностей. Создание текстурной поверхности на базе растра требует нескольких дополнительных действий. HRESULT CALLBACK TextureCalIbackCDDPIXELFORMAT* pddpf. void * param) { // Найти простой формат текстуры >=16 бит/пиксел
Непосредственный режим Direct3D 1051 if ( (pddpf->dwFlags & (DDPF_LUMINANCE|DDPF_BUMPLUMINANCE|DDPF_BUMPDUDV|DDPF_ALPHAPIXELS))==0 ) if ( (pddpf->dwFourCC == 0) && (pddpf->dwRGBBitCount>=16) ) { memcpy(param. pddpf, sizeof(DDPIXELFORMAT) ): return DDENUMRET_CANCEL: // Прекратить поиск } return DDENUMRETJDK; // Продолжить HRESULT KOffScreenSurface::CreateTextureSurface(IDirect3DDevice7 * pD3DDevice, IDirectDraw7 * pDD, unsigned width, unsigned height) { // Запросить информацию о возможностях устройства D3DDEVICEDESC7 ddDesc; HRESULT hr = pD3DDevice->GetCaps(&ddDesc); if ( FAILED(hr) ) return hr; m_ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT | DDSDJIIDTH | DDSD_PIXELFORMAT | DDSDJEXTURESTAGE: m_ddsd.ddsCaps.dwCaps = DDSCAPSJEXTURE; mjjdsd.dwWidth - width; m_ddsd.dwHeight = height; // Включить управление текстурами для устройств с аппаратным ускорением if ( (ddDesc.deviceGUID =- IID_IDirect3DHALDevice) || (ddDesc.deviceGUID == IID_IDirect3DTnLHalDevice) ) m_ddsd.ddsCaps.dwCaps2 - DDSCAPS2JEXTUREMANAGE: else m_ddsd.ddsCaps.dwCaps |- DDSCAPS JYSTEMMEMORY; // Отрегулировать ширину и высоту, если этого требует драйвер if ( ddDesc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_P0W2 ) { for ( mjJdsd.dwWidth=l; width > m_ddsd.dwWidth; mjJdsd.dwWidth«=l ); for ( mjJdsd.dwHeight=l; height > m_ddsd.dwHeight; m_ddsd.dwHeight«=l ): } if ( ddDesc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_SQUARE0NLY ) { if ( mjjdsd.dwWidth > m_ddsd.dwHeight ) m^ddsd.dwHeight - mjjdsd.dwWidth; else m_ddsd.dwWidth - m_ddsd.dwHeight: } memset(& m^ddsd.ddpfPixel Format. 0. sizeof(m_ddsd.ddpfPixel Format)); pD3DDevi ce->EnumTextureFormats(TextureCal1 back. & m_ddsd.ddpfPixel Format);
1052 Глава 18. DirectDraw и непосредственный режим Direct3D if ( mjdsd.ddpf Pixel Format. dwRGBBitCount ) return pDD->CreateSurface( & m_ddsd. & m_pSurface. NULL ); else return E FAIL; Пример использования непосредственного режима Direct3D Итак, в нашем распоряжении имеется среда, подготовленная классами KDirect3D и KD3DWin, и поддержка текстурных растров. Чтобы реализовать окно Direct3D, достаточно создать класс, производный от KDirect3D, и переопределить в нем несколько методов. В листинге 18.6 приведен класс простого окна непосредственного режима Direct3D, в котором выводится вращающаяся пирамида. Пример иллюстрирует работу с текстурами и Z-буфером, а также создание анимации. Листинг 18.6. class KDirect3DDemo : public KDirect3D { KOffScreenSurface m_texture[4]; public: HRESULT OnRender(void); HRESULT OnlnltCHINSTANCE hlnst): HRESULT OnDischarge(void); }: HRESULT KDirect3DDemo::0nInit(HINSTANCE hlnst) { D3DMATERIAL7 mtrl; memset(&mtrl. 0. sizeof(mtrl)); mtrl.ambient.г = l.Of; mtrl.ambient.g = l.Of; mtrl.ambient.b = l.Of: m_pD3DDevice->SetMaterial( &mtrl ): m_pD3DDevice->SetRenderState( D3DRENDERSTATE_AMBIENT. RGBA_MAKE(255. 255. 255. 0) ); D3DMATRIX mat: memset(& mat, 0. sizeof(mat)): mat.Jl = mat._22 = mat._33 = mat._44 = l.Of; // Матрица вида. 10 единиц по оси z D3DMATRIX matView = mat: matView._43 = 10.Of: m_pD3DDevice->SetTransform( D3DTRANSF0RMSTATE_VIEW. &matView ); mat. mat. mat. mat. mat. 11 = 22 - 34 = 43 = 44 = 2.Of 2.Of l.Of -O.lf O.Of m_pD3DDevice->SetTransform( D3DTRANSF0RMSTATE_PR0JECTI0N. &mat):
Непосредственный режим Direct3D 1053 // Разрешить использование Z-буфера m_pD3DDevice->SetRenderState( D3DRENDERSTATE_ZENABLE. TRUE); for (int i=0; i<4; i++) { const int nResIDE] = { IDBJIGER. IDB_PANDA. IDB_WHALE, IDBJLEPHANT }; BITMAPINFO * pDIB - LoadBMP(hInst, MAKEINTRESOURCE(nResID[i])); if ( pDIB ) m_texture[i].CreateTextureSurface(m_pD3DDevice. m_pDD. pDIB); else return E FAIL; m_bReady = true; return S_OK; } HRESULT KDirect3DDemo;:OnDischarge(void) { m_bReady = false; for (int i=0; i<4; i++) m_texture[i].Discharge(); return S_OK; } Класс KDirect3DDemo объявлен производным от класса KDirect3D. Он содержит массив объектов KOf fScreenSurface для хранения четырех текстур и переопределяет три метода (инициализация, уничтожение и вывод). Метод Onlnit выбирает простой белый материал, рассеянный белый свет, фиксированные матрицы вида и проекции, а также включает использование Z-бу- фера. В завершающей части метода Onlnit четыре текстурные поверхности инициализируются растровыми ресурсами. Метод OnDischarge освобождает ресурсы, выделенные методом Onlnit. Ниже приведена реализация метода OnRender. HRESULT DrawTriangle(IDirect3DDevice7 * pDevice. int xO, int yO. int zO. int xl. int yl. int zl. int x2. int y2. int z2) { D3DVERTEX vertices[3]: D3DVECT0R pl( (float)xO. (float)yO, (float)zO ) D3DVECT0R p2( (float)xl. (float)yl. (float)zl ) D3DVECT0R p3( (float)x2. (float)y2, (float)z2 ) D3DVECT0R vNormal = Normalize(CrossProduct(pl-p2. p2-p3)); // Инициализировать З вершины фронтальной стороны треугольника
1054 Глава 18. DirectDraw и непосредственный режим Direct3D vertices[0] = D3DVERTEXC pl. vNormal. 0.5f. O.Of ) verticesd] = D3DVERTEX( p2. vNormal. l.Of. l.Of ) vertices[2] = D3DVERTEX( p3. vNormal. O.Of. l.Of ) return pDevice->DrawPrimitive(D3DPT_TRIANGLELIST. D3DFVF_VERTEX. vertices. 3. NULL): HRESULT KDirect3DDemo::OnRender(void) { double time = GetTickCountO / 2000.0; m_pD3DDevice->Clear(0. NULL. D3DCLEARJARGET | D3DCLEAR_ZBUFFER. RGBA_MAKE(0. 0. Oxff, 0). l.Of. 0); if ( FAILEDC m_pD3DDevice->BeginScene() ) ) return E_FAIL; D3DMATRIX matLocal; memset(& matLocal. 0. sizeof(matLocal)); matLocal._11 = matLocal._33 = (FLOAT) cos( time ): matLocal._13 = matLocal._31 = (FLOAT) sin( time ): matLocal._22 = matLocal._44 = l.Of; m_pD3DDevice->SetTransform( D3DTRANSF0RMSTATE_W0RLD. &matLocal ); m_pD3DDevice->SetTexture( 0. m_texture[0] ): DrawTriangle(m_pD3DDevice. 0. 3. 0. 3. -3. 0. 0. -3. 3); m_pD3DDevice->SetTexture( 0. m_texture[l] ): DrawTriangle(m_pD3DDevice. 0. 3. 0. 0. -3. -3. 3. -3. 0): m_pD3DDevice->SetTexture( 0. m_texture[2] ); DrawTriangle(m_pD3DDevice. 0. 3. 0. -3. -3. 0. 0. -3. -3); m_pD3DDevice->SetTexture( 0. m_texture[3] ); DrawTriangle(m_pD3DDevice. 0. 3. 0, 0. -3. 3. -3. -3. 0); m_pD3DDevice->EndScene(); return S_0K; } Метод OnRender заполняет поверхность устройства Direct3D однородным синим цветом и сбрасывает Z-буфер, используя для этого метод IDirect3DDevice7::Clear. Вывод начинается с вызова BeginScene и завершается вызовом EndScene. Метод запрашивает системное время и использует его для настройки матрицы поворота вдоль оси у. Период вращения составляет примерно 12 секунд (2 х pi x 2). Затем метод выводит четыре грани пирамиды, причем на каждую грань накладывается своя текстура. Грани пирамиды рисуются в виде треугольников в трехмерном пространстве. Вспомогательная функция DrawTriangle получает три точки пространства в целочисленных координатах. Для представления вершин, требующихся при выводе точек, линий и треугольников, в Direct3D используется структура D3DVERTEX.
Итоги 1055 Простая вершина содержит координаты точки, вектор нормали и координаты текстуры. Координаты точки определяют местонахождение вершины в пространстве; вектор нормали задает направление поверхности, на которой находится точка, а координаты текстуры определяют позицию соответствующего пиксела на текстурном растре. При наложении текстуры Direct3D автоматически интерполирует текстуру для каждого пиксела треугольника. Функция DrawTriangle преобразует целочисленные координаты к формату с плавающей точкой, вычисляет вектор нормали к поверхности и задает для каждой вершины фиксированные координаты текстуры. Данные сохраняются в массиве D3DVERTEX и выводятся одним вызовом IDirect3DDevice: :DrawPrimitive — основным методом, предназначенным для вывода на устройствах Direct3D. На рис. 18.5 показан один из кадров при вращении пирамиды. Рис. 18.5. Пример использования непосредственного режима Direct3D Из-за богатых возможностей непосредственного режима Direct3D программирование для него оказывается слишком сложным делом, чтобы его можно было подробно описать на страницах этой книги. Обращайтесь к документации DirectX от Microsoft — в ней вы найдете неплохой учебник и примеры программ. Итоги В этой главе были представлены азы программирования для DirectDraw и непосредственного режима Direct3D. Мы рассмотрели процесс создания классов C++
1056 Глава 18. DirectDraw и непосредственный режим Direct3D для обобщенной поддержки DirectDraw/Direct3D. Эти классы отделены от манипулятора окна, поэтому они могут интегрироваться с любыми окнами. В части, посвященной DirectDraw, мы довольно подробно рассмотрели, как использовать метод Bit DirectDraw для вывода с аппаратным ускорением, как напрямую работать с зафиксированной поверхностью и как обратиться за помощью к GDI. Попутно были разработаны классы и методы для работы с внеэкранными поверхностями, текстурными поверхностями, Z-буферами и шрифтовыми поверхностями, а также для вывода текста. Надеюсь, автору удалось показать, что программирование для DirectDraw/ Direct3D — не такая уж сложная задача, особенно при наличии хорошо спроектированных классов C++. Область применения DirectDraw/Direct3D не ограничивается игровыми и учебными программами. Обычные оконные приложения тоже могут воспользоваться аппаратной поддержкой DirectDraw/Direct3D, чтобы улучшить качество вывода и сделать пользовательский интерфейс более удобным. Microsoft предоставляет неплохую документацию, учебники и примеры программ для DirectDraw, непосредственного режима Direct3D и других компонентов DirectX. Документацию и учебники можно найти в MSDN, а примеры программ - в Platform SDK и DirectX SDK. Microsoft также предлагает библиотеку классов для построения приложений непосредственного режима Direct3D; центральное место в этой библиотеке занимает класс CD3DAppl ication. Программный код находится в подкаталогах Include и Src\D3DFrame каталога Samples\MultiMedia\D3DIM комплекта SDK. В этой главе классы Direct3D от Microsoft не использовались, поскольку они слишком жестко объединяют приложение, окно и поддержку DirectDraw/Direct3D. Эта библиотека позволяет создавать приложения с единственным окном, поддерживающим Direct3D. Даже цикл обработки сообщений использует глобальную переменную для передачи сообщений виртуальным обработчикам, определенным в классе CD3DApplication. В библиотеку входит очень удобный класс для работы с текстурами, но нет класса общей поддержки поверхностей DirectDraw. Также есть чрезвычайно полезный класс для загрузки файлов DirectX в формате .X (формат Microsoft для представления трехмерных моделей). В целом библиотека содержит немало полезного кода, но для того, чтобы включить поддержку Direct3D в готовую оконную программу C++, вам придется немало потрудиться над ее адаптацией. Технология DirectX7 появилась относительно недавно. На момент написания этой книги еще не было хороших учебников, которые можно было бы порекомендовать. Возможно, наряду с документацией, учебниками и примерами от Microsoft вам понадобится хорошая книга по OpenGL, поскольку непосредственный режим Direct3D имеет с OpenGL много общего. Примеры программ К главе 14 прилагаются три программы и несколько классов для работы с DirectDraw и непосредственного режима Direct3D (табл. 18.1).
Итоги 1057 Таблица 18.1. Программы главы 18 Каталог проекта Описание Samples\Chapt_18\ddbasic Демонстрация основных возможностей DirectDraw Samples\Chapt_18\DemoDD Применение DirectDraw для вывода в дочерних окнах MDI, рисования пикселов, линий и замкнутых фигур, вывода растров, спрайтов и текста Samples\Chapt_18\DemoD3D Использование непосредственного режима Direct3D в окне SDI, работа со вторичной поверхностью, Z-буферы и текстурные поверхности
Алфавитный указатель А AbortDoc, 976 AbortPrinter, 955 AddFontMemResourceEx, 795 AddFontResource, 794 Adobe Type Manager (ATM), 765 AdvancedDocumentProperties, 964 AlphaBlend, 1007 ALTERNATE, режим заполнения, 501, 505 AngleArc, 455, 466 ANSI_CHARSET, 745 ANTIALIASED_QUALITY, 857, 875 AppendMenu, 588 ARABIC_CHARSET, 746 Arc, 454 ArcTo, 454 В BALTIC__CHARSET, 746 BeginPaint, 312, 390-391 BeginPath, 461, 466, 504, 878, 898 BitBlt, 576, 616, 1007, 1035 BITMAP, структура, 387, 598 BITMAPCOREHEADER, структура, 538 BITMAPFILEHEADER, структура, 549, 596 BITMAPINFO, структура, 214, 544, 594, 858, 920 BITMAPINFOHEADER, структура, 545, 549, 598, 858 BITMAPV4HEADER, структура, 538, 598 BITMAPV5HEADER, структура, 538, 598 BITSPIXEL, 974 BLACKNESS/WHITENESS, 616 BltBatch, 1014 BltFast, 1007, 1014, 1023 BMP, формат заголовок, 536 маски, 536 массив пикселов, 545 цветовая таблица, 536 Borland C++, 52 BoundsChecker (NuMega), 58, 241 BreakChar, 759 BRUSH, структура, 212 С C/C++, 31,56 C++, имена классов, 36 CallNextHookEx, 246 CAPTUREBLT, флаг, 612 CGdiObject, 386 CHINESEBIG5_CHARSET, 746 Chord, 498, 927 ClientToScreen, 344 CLIPCAPS, 974 CLIPOBJ, структура, 218 CloseEnhMetaFile, 899 CloseFigure, 463 стар, таблица, 767 COLOR_GRADIENTINACTIVE- CAPTION, 488 COLOR_SCROLLBAR, 488 COLORREF, 246, 403, 664, 1018 COM (Component Object Model), 31, 1001 CombineRgn, 514 COMMCTRL.DLL, 589 COMPLEXREGION, 393 CopyEnhMetaFile, 908 CopyToClipBoard, 911 CreateBitmap, 565, 583 CreateBitmapIndirect, 566 CreateBitmapSurface, 1034 CreateBrushlndirect, 489 CreateCompatibleBitmap, 567
Алфавитный указатель 1059 CreateCompatibleDC, 343 CreateDC, 307, 392 CreateDIBitmap, 569 CreateDIBPalette, 722 CreateDIBPatternBrush, 484 CreateDIBPatternBrushPt, 484 CreateDIBSection, 595 CreateDiscardableBitmap, 569 CreateEllipticRegion, 508, 922 CreateEllipticRegionlndirect, 508 CreateEnhMetafile, 152, 898 CreateEvent, 79 CreateFile, 177 CreateFont, 806 CreateFontlndirect, 806 CreateFontlndirectEx, 806, 808 CreateHalftonePalette, 411, 706 CreateHatchBrush, 482 CreateIC, 343 CreatePatternBrush, 484 CreatePen, 430, 918 CreatePenlndirect, 433 CreatePolygonRgn, 509 CreatePrimary Surface, 1013 CreateRectRgn, 171, 393 CreateRoundRectRgn, 508 CreateScalableFontResource, 793 CreateService, 181 CreateWindow/CreateWindowEx, 40, 390 CS (Code Segment), 47 CURVECAPS, 974 D D3DVERTEX, структура, 1054 DD_SURFACE_INT, структура, 237 DD_SURFACE_LOCAL, структура, 237 DD_SURFACE_MORE, структура, 237 DDA, алгоритмы, 445 DDBLTFX, структура, 1014 DDCOLORKEY, структура, 1035 DDCREATE_EMULATEONLY, 1005 DDCREATE_HARDWAREONLY, 1005 DDI, интерфейс, 275 DDK (Device Driver Kit), 31 DDPIXELFORMAT, структура, 1020 ddraw.dll, 104 DDSURFACEDESC2, структура, 1016 DEFAULT_CHARSET, 755, 822 DEFAULT_PITCH, 754 DefWindowProc, 591 DeleteEnhMetaFile, 900 DeleteObject, 385, 428, 481 Delphi, 31, 52 DESIGNVECTOR, структура, 794 DEVLEVEL, структура, 222 DEVMODE, структура, 699, 957 DIBSECTION, структура, 387 DIB-секции CreateDIBSection, 595 GetDIBColorTable, 599 SetDIBColorTable, 599 общие сведения, 593, 666 Direct3D, 100, 1043 Direct Animation, 101 DirectDraw, 42, 100, 102, 1000 HAL, 105 HEL, 105 IDirectDraw, интерфейс, 101, 103 IDirectDrawClipper, интерфейс, 1020 IDirectDrawColorControl, интерфейс, 103 IDirectDrawGammaControl, интерфейс, 103 IDirectDrawPalette, интерфейс, 103 IDirectDrawSurface, интерфейс, 103 IDirectDrawSurface7, интерфейс, 103 IDirectDrawVideoport, интерфейс, 103 архитектура, 103 прямой доступ к пикселам, 1016 структуры данных, 232 Directlnput, 100 DirectMusic, 100 DirectPlay, 100 Direct Setup, 100 DirectShow, 101 DirectSound, 100 DirectX, 99, 383 DllGetClassObject, 1004 DocumentProperties, 963 DPtoLP, 492 DrawText, 866, 929
1060 Алфавитный указатель DRVENABLEDATA, 205 DS (Data Segment), 47 DSTINVERT, 620 dumpbin.exe, 54 E EASTEUROPE_CHARSET, 746 EDD_DIRECTDRAW_CLOBAL, структура, 234 EDD_DIRECTDRAW_LOCAL, структура, 233 EDD_SURFACE, структура, 237 Ellipse, 498, 927 EMF (расширенные метафайлы), 82, 604, 897 воспроизведение, 900 записи, 912 недокументированные типы записей, 940 палитры, 922 текст, 928 траектории, 922 EmptyClipBoard, 911 EMRBITBLT, структура, 919 EndDoc, 976 EndPage, 975 EndPath, 463, 504, 922 ENHMETAHEADER, структура, 913 EnumDisplayDevices, 294 EnumDisplaySettings, 295 EnumEnhMetaFile, 930 EnumeratePrinters, 960 EnumFontFamiliesEx, 755 ENUMLOGFONTEXW, структура, 225 EnumObjects, 428, 480 EnumSystemCodePages, 750 EPALOBJ, структура, 215 EqualRegion, 513 ETO_CLIPPED, 850 ETO_GLYPH_INDEX, 850 ETOJGNORELANGUAGE, 850 ETO_NUMERICSLATIN, 850 ETO_NUMERICSLOCAL, 850 ETO_OPAQUE, 850 ETO_PDY, 850 ETO_RTLREADING, 850 ExtCreatePen, 433 ExtCreateRegion, 171, 519 EXTLOGFONTW, структура, 930 EXTLOGPEN, структура, 214 ExtSelectClipRegion, 395 ExtTextOut, 818, 864, 928 F FD_GLYPHSET, структура, 226 FF_DECORATIVE, 754 FF_DONTCARE, 754 FF_MODERN, 754 FF_ROMAN, 754 FF_SCRIPT, 754 FF_SWISS, 754 FillPath, 471, 504, 888 FillRect, 493, 928 FillRgn, 522, 928 FindResource, 909 FirstChar, 759 FIXED, структура, 863 FIXED_PITCH, 754 FlattenPath, 467, 878 FLOATOBJ, структура, 175 FNT, расширение, 758 FON, расширение, 758 FONTEDIT, утилита, 758 FONTOBJ, структура, 228 G GCPJUSTIFY, флаг, 853 GCP_REORDER, флаг, 853 GCP_USEKERNING, флаг, 853 GDI, 93, 102 API, 273 OpenGL, 96 архитектура, 93 манипуляторы, 143 недокументированные функции, 96 объекты, 383 системные DLL, 95 экспортируемые функции, 94 GDI+, 1000 GDI32.DLL, 52, 157, 159 GetAspectRatioFilterEx, 881 GetBkColor, 483, 833 GetBkMode, 483 GetBoundsRect, 904 GetCharABCWidthFloat, 842 GetCharABCWidthI, 847
Алфавитный указатель 1061 GetCharABCWidths, 842 GetCharacterPlacement, 846, 851 GetCharWidth32, 842 GetCharWidthI, 847 GetClientRect, 343 GetClipboardData, 911 GetClipBox, 396 GetClipRgn, 393 GetCurrentObject, 393 GetCurrentProcessId, 163 GetDC, 310, 400 GetDCBrushColor, 480 GetDCOrgEx, 343 GetDCPenColor, 429 GetDefaultPrinter, 972 GetDeviceCaps, 205, 416, 970 GetEnhMetaFileBits, 916 GetEnhMetaFileHeader, 906 GetGlyphlndices, 846, 852 GetKerningPairs, 847 GetMetaRgn, 397 GetNearestColor, 411 GetNearestPalettelndex, 412 GetObject, 387 GetObjectType, 161, 168 GetPaletteEntries, 412 GetPath, 463, 922 GetPathData, 890 GetPixel, 417, 663, 1020 GetPolyFillMode, 501 Get Printer, 961, 974 GetRandomRgn, 398-399 GetRegionData, 516 GetROP2, 423 GetStockObject, 152 GetSurfaceDesc, 1020 GetSysColor, 488 GetSysColorBrush, 488 GetTabbedTextExtent, 865 GetTextABCWidths, 846 GetTextABCWidthsFloat, 846 GetTextCharacterExtra, 839 GetTextCharSet, 819 GetTextCharSetlnfo, 819 GetTextExtentPoint32, 839 GetTextFace, 827 GetUpdateRegion, 391 GetWindowDC, 310 GetWindowRect, 343 GGO_BEZIER, 857, 861 GGO_BITMAP, 860 GGO_GLYPH_INDEX, 857 GGO_GRAY2__BITMAP, 857 GGO_GRAY4_BITMAP, 857 GGO_GRAY8_BITMAP, 857 GGO_METRICS, 857 GGO_NATIVE, 861 GGO_UNHINTED, 861 GIF, формат, 546 glyf, таблица, 767, 773 GLYPHINFO, таблица, 760 GLYPHMETRICS, структура, 856 GRADIENT_RECT, структура, 524 GRADIENTJTRIANGLE, структура, 524 GradientFill, 523 GREEK_CHARSET, 746 GUID, 1002 H HAL, 105 HANDLETABLE, структура, 918 HANGUL_CHARSET, 746 HBITMAP, 210, 594 HBRUSH, 151, 480 HDC, 151 HEBREW_CHARSET, 746 HEL, 105 HENHMETAFILE, 898 HFONT, 151 HGDIOBJ, 151,262,480 HGLOBAL, 214 HINSTANCE, 149 HLS, цветовое пространство, 406, 419 HMENU, 151 HMODULE, 149 HORZRES, 906 HORZSIZE, 906 HPEN, 151, 428 HWND, 151 I IClassFactory, интерфейс, 1004 ICM (Image Color Management), 86 IDirect3D7, интерфейс, 1046 IDirectDraw, интерфейс, 103 IDirectDraw2, интерфейс, 1005 IDirectDraw7, интерфейс, 1005
1062 Алфавитный указатель IDirectDrawClipper, интерфейс, 103, 1020 IDirectDrawColorControl, интерфейс, 103 IDirectDrawGammaControl, интерфейс, 103 I Direct DrawPalette, интерфейс, 103 IDirectDrawSurface, интерфейс, 103 IDirectDrawVideoport, интерфейс, 103 IFIMETRICS, структура, 226 IMAGE_DOS_HEADER, 63 IMAGE_NT_HEADERS, 63 IMAGE_OPTIONAL__HEADER, 64 InflateRect, 491 InsertMenuItem, 588 IntersectRect, 491 InvertRect, 928 InvertRgn, 522, 928 IUnknown, интерфейс, 1001 з JOHAB_CHARSET, 746 JPEG, 607 К KERNEL32.DLL, 97, 159, 183 L LastChar 759 LAYOUT JBITMAPORIENTATION- PRESERVED, 837 LAYOUT_RTL, 838 LFONT, структура, 228 LINEATTRS, структура, 222 LINECAPS, 974 LineDDA, 476 LineDDAProc, 445 LineTo, 442 LoadBitmap, 716, 909 Loadlmage, 717, 909 LoadResource, 149, 909 loca, таблица, 772 LOGBRUSH, структура, 170, 214, 387 LOGFONT, структура, 387, 755 LOGFONTW, структура, 225 LOGPALETTE, структура, 214, 708 LOGPEN, структура, 387 LOGPIXELX, 899 LOGPIXELY, 899 LPDIRECTDRAW, 232 LPDIRECTDRAWSURFACE, 232 LPtoDP, 395, 492 M MAC_CHARSET, 746 MAKEROP4, макрос, 635 MaskBlt, 636 MAT2, структура, 857 MDI (Multiple Document Interface), 40 MERGECOPY, 617, 619 MERGEPAINT, 622 METAFONT, 744 MFC (Microsoft Foundation Classes), 31, 46 Microsoft Knowledge Base, 508 Microsoft Word, 897 MM_ANISOTROPIC, режим отображения, 352, 935 MM_HIENGLISH, режим отображения, 348 MM_HIMETRIC, режим отображения, 350 MM JSOTROPIC, режим отображения, 351 MM_LOENGLISH, режим отображения, 348 MM_LOMETRIC, режим отображения, 350 ММ_ТЕХТ, режим отображения, 348, 487, 842, 977 MM_TWIPS, режим отображения, 351 MoveToEx, 442, 929 MSDN (Microsoft Developer Network), 59 Multiple Master OpenType, шрифты, 794 N NextBand, 959 nmake.exe 54 NOMIRRORBITMAP, флаг, 612, 837 NOTSRCCOPY, 617 NOTSRCERASE, 622
Алфавитный указатель 1063 Novell Netware, провайдер печати, 109 NTFS (NT File System), 75 NTOSKRNL.EXE, 92 NULL, регион отсечения, 393 NULLREGION, 393 NUMCOLORS, 974 О OBJ_ENHMETAFILE, 898 OEM_CHARSET, 746 OffsetClipRgn, 396 OffsetRgn, 520 OffsetViewportOrgEx, 983 OLE, 31 OnDraw, 983 OPAQUE, режим заполнения фона, 427 OpenGL, 89, 96 OpenType, шрифты, 811 OUTLINETEXTMETRIC, структура, 796,811-812 Р PAGESETUP, структура, 968 PageSetupDlg, 968 PaintRgn, 522, 928 PAINTSTRUCT, структура, 312 PALETTE, 210 PALETTEENTRY, структура, 699 PALETTEINDEX, 412, 705 PALETTERGB, 412, 705 PALOBJ, структура, 216 PANOSE, система подстановки шрифтов, 812 PANOSE, структура, 757 PatBlt, 1007, 1014 PATCOPY, 639 PATH, структура, 221 PATHDATA, структура, 224 PATHDEF, структура, 221 PATHDT, структуры, 221 PATHOBJ, структура, 220 PathToRegion, 507, 895 PATINVERT, 635, 872 PATPAINT, 623 PCL, 107 PCX, 546 PDEV, структура, 200 PDEV_WIN32K, 201 РЕ, формат исполняемых файлов, 61, 149 PFE, структура, 227 PFF, структура, 227 PFT, структура, 228 Pie, 498 PLANES, 974 PlayEnhMetaFile, 606, 901, 923-924, 959 PlayEnhMetaFileRecord, 931 PlgBlt, 628, 663, 1007 PNG, формат, 536 POINT, структура, 443, 492, 856 PolyBezier, 449 PolyBezierTo, 442 Poly Draw, 451, 466, 862 POLYGONALCAPS, 974 PolyLineTo, 442 PolyPolygon, 504, 927 PolyPolyline, 462 PolyTextOut, 928 PostScript, 107, 603 PrintBand, 959 PrintDialog, 971 PrintDlg, 966, 968 PRINTDLG, структура, 967-968 PrinterProperties, 964 profile.exe, 54 PS_ALTERNATE, 435, 487 PS_COSMETIC, 433 PS_DASH, 431 PS_DASHDOT, 431 PS_DASHDOTDOT, 431 PS_DOT, 431 PS_ENDCAP_FLAT, 437 PS_ENDCAP_ROUND, 437 PS_ENDCAP_SQUARE, 437 PS_GEOMETRIC, 433 PSJNSIDEFRAME, 431 PS_JOIN_BEVEL, 433 PSJOIN_MITER, 433 PS JOIN_ROUND, 433 PS_NULL, 433 PS_SOLID, 457 PS_USERSTYLE, 435 PT_CLOSEFIGURE, 466 Q Query Interface, 1006 QuickDraw GX (Apple), 855
1064 Алфавитный указатель R R2_MASKPEN, 425, 487, 529 R2_MERGEPEN, 529 R2_NOP, 424 R2_NOT, 424 R2_NOTCOPYPEN, 425 R2_NOTXORPEN, 425 R2_WHITE, 425 R2_XORPEN, 425 RASTERCAPS, 974 RAW, формат спулинга, 109 RC_BITBLT, 577 RC_PALETTE, 698 RDTSC, инструкция процессора, 48 RealizePalette, 412 rebase.exe, 54 RECT, структура, 171, 490, 1014 Rectangle, 492 RectlnRegion, 513 REGION, структура, 217, 221 REGIONOBJ, 517 ReleaseDC, 1015 RemoveFontResource, 794 RemoveFontResourceEx, 794 RestoreDC, 471 RFONT, структура, 229 RGB, цветовое пространство, 286, 4( RGBQUAD, структура, 544 RGBTRIPLE, структура, 544, 667 RGNDATA, структура, 520, 926 RoundRect, 522 RUSSIAN_CHARSET, 746 s SaveDC, 471 SCAN, структура, 218, 517 SelectClipPath, 922 SelectClipRgn, 394, 929 SelectObject, 161, 385 SelectPalette, 385, 706 SelectRegion, 922 SetAbortProc, 976 SetBkColor, 483, 583, 833 SetBkMode, 483, 929 SetBoundsRect, 904 SetBrushOrgEx, 484 SetClipboardData, 911 SetClipPath, 895 Set Clipper, 1032 SetClipRgn, 398 SetDCPenColor, 429, 480 SetDIBColorTable, 599, 725 SetDIBitsToDevice, 561 SetEnhMetaFileBits, 909 SetMenuItemBitmaps, 584 SetMenuItemlnfo, 584, 588 SetMetaRgn, 397, 939 SetMiterLimit, 439 SetPixel, 416, 663, 927 Set Pixel V, 416 SetPolyFillMode, 501 SetRect, 491 SetRectRgn, 172 SetROP2, 423 SetSourceColorKey, 1035 SetStretchBltMode, 558 SetSysColor, 488 SetTextAlign, 929 SetTextCharacterExtra, 839 SetTextColor, 583 SetTextJustification, 840 SetViewportExtEx, 924 SetWindowExtEx, 942 SetWindowRgn, 310, 391, 507 SetWindowsHookEx, 244 SetWorldTransform, 924 SHIFTJIS_CHARSET, 746 SIMPLEREGION, 393 SoftlCE/W, 58 SPOOLSV.EXE, 955 SPRITESTATE, структура, 204, 236 Spy++, 54 SRCAND, 624 SRCCOPY, 556 SRCINVERT, 632 SRCPAINT, 645 SS (Stack Segment), 47 StartDoc, 975 StartPage, 977 STI (Still Image) API, 89 STM_SETIMAGE, сообщение, 909 STRETCH_ANDSCANS, 558 STRETCH_DELETESCAN, 559 STRETCH_HALFTONE, 559 STRETCH_ORSCANS, 558 StretchBlt, 577, 641, 1014 StretchDIBits, 556, 645 STRICT, макрос, 32, 55 StrokeAndFillPath, 471, 888
Алфавитный указатель 1065 StrokePath, 471, 888 SubtractRect, 491 SUCCEEDED, макрос, 1004 SURFACE, 210 SURFOBJ, 208 SYMBOL_CHARSET, 755 T TA_BASELINE, 835 TA_BOTTOM, 836 TA_CENTER, 835 TA_LEFT, 835 TA_NOUPDATECP, 834 TA_RIGHT, 836 TA_RTLREADING, 837 TA_TOP, 835 TA_UPDATECP, 835 TabbedTextOut, 865 TBBUTTON, 55 TEXT, формат спулинга, 110 TEXTCAPS, 974 TEXTMETRIC, структура, 812, 827 TextOut, 834, 860 THAI_CHARSET, 746 TIFF, формат, 546 TRANSPARENT, режим заполнения фона, 427 TransparentBlt, 627, 1007 TRIVERTEX, структура, 524 TrueType, шрифты, 765 инструкции, 782 таблица PostScript, 791 имен, 791 кернинга, 789 формат, 765 TT_PRIM_CSPLINE, 862 TT_PRIM_LINE, 862 TT_PRIM_QSPLINE, 862 TTPOLYCURVE, структура, 861 TTPOLYGONHEADER, структура, 862 TURKISH_CHARSET, 746 и Unicode, 750, 846, 928 UniDriver, 75 UNIDRVUI.DLL, 113 Uniscribe, 854 USER32.DLL, 52, 495, 872 V VARIABLE_PITCH, 754 VERTRES, 906 VERTSIZE, 906 VIETNAMESE_CHARSET, 746 Visual Basic, 31, 52 Visual C++, 52 VTune (Intel), 58 w WidenPath, 468, 502 WIN32K.SYS, 92, 383 WinDbg, 51 WINDING, режим заполнения, 501 Windows NT 4.0/2000, 51 WINSPOOL.DRV, 955 WM_CREATE, сообщение, 40, 1050 WM_DESTROY, сообщение, 1050 WM_DISPLAYCHANGE, сообщение, 699 WM_ERASEBKGND, сообщение, 589 WM_FONTCHANGE, сообщение, 794 WMJNITDIALOG, сообщение, 592 WM_MOUSEMOVE, сообщение, 425 WM_NCPAINT, сообщение, 1023 WM_PAINT, сообщение, 324, 329, 922 WM_PALETTECHANGED, сообщение, 700, 922 WM_PALETTEISCHANGING, сообщение, 711 WM_QUERYNEWP ALETTE, сообщение, 710 WM_SIZE, сообщение, 1050 WNDCLASSEX, структура, 37 WriteFile, 381 WritePrinter, 112,957 WS_EX_LAYOUTRTL, 837 WS_EX_RIGHT, 837 z Z-буфер, 291, 1047 Z-размывка, 292
1066 Алфавитный указатель А адресное пространство режима ядра, доступ, 153 алгоритмы цветовых преобразований растров, 672 альфа-канал, 651 альфа-наложение имитация, 659 общие сведения, 649 аппаратно-зависимые растры (DDB) CreateBitmap, 565 CreateBitmapIndirect, 566 CreateCompatibleBitmap, 567 CreateDIBitmap, 569 LoadBitmap, 570 массив пикселов, 596 общие сведения, 166, 564 аппаратно-независимые растры (DIB) SetDIBitsToDevice, 561 StretchDIBits, 556 вывод, 556 преобразование цветового формата, 559 растровые операции, 559 арабская письменность, 836 архитектура GDI, 93 Windows, 71 графической системы Windows, 84 системы печати, 106 ассемблер, 46 аффинные преобразования ассоциативность, 361 замкнутость, 361 кривые Безье, 360 линии, 360 обратные, 361 общие сведения, 358 параллельность, 360 растры, 667 свойства, 359 тождественность, 361 эллипсы,360 Б базовая линия, 752 Безье, 447 бинарные операции растровые, 422 с регионами, 394 блиттинг, 1014 Брезенхэм, алгоритм, 1026 В векторные шрифты, 762 видеоадаптер, 282 виртуальная память, 158 внешний зазор, 803 внеэкранная поверхность, 1033 внутренний зазор, 803 выключка, 839 выравнивание текста, 833 Г гамма-коррекция, 676 геометрические перья, 436 гистограмма, 686 глифы индекс в таблице, 760 кириллицы, 819 определение, 751 основных пикселов, 426 расшифровка контура, 862 фоновых пикселов, 426 градиентные заливки, 523 в пространстве HLS, 529 радиальные, 530 режимы, 523 д дамп, 275 декоративные шрифты, 755 драйверы ввода-вывода, 59 режима ядра, 93 устройств Microsoft Windows, 72 файловой системы, 59 экрана, 59 ДУГИ AngleArc, 455 Arc, 454 ArcTo, 454 общие сведения, 454
Алфавитный указатель 1067 дуги {продолжение) определение в градусах, 455 преобразование в кривые Безье, 457 3 замкнутые фигуры градиентные заливки, 523 закраска, 532 замкнутые траектории, 504 кисти, 479 многоугольники, 500 общие сведения, 479 прямоугольники, 490 регионы, 509 сегменты, 498 секторы, 498 текстурные заливки, 532 эллипсы, 498 И инкапсуляция, 144 инструкции глифов, 782 Интернет, 85 интерфейсный указатель, 1003 информационный контекст устройства, 315 исполнительная часть, 72 к квадратичные кривые Безье, 861 квантование по октантному дереву, 726 цветов, 726 кватернарные растровые операции, 635 кернинг, 847 кисти LOGBRUSH, структура, 489 базовая точка, 484 логические, объект, 479 общие сведения, 479 пользовательские, 481 системные цвета, 488 стандартные, 480 клиентская область, 391 Кнут, Дональд, 744 коллекции шрифтов, 792 компилятор, 52, 55 контекст устройства Windows 2000, 320 атрибуты, 304 информационный, 315 метафайловый, 316 общие сведения, 297 получение информации о возможностях, 299 родительский, 315 связь с окном, 307 совместимый, 316 создание, 298 контрольная сумма, 157, 159 косметические перья, 435 кривые Безье PolyBezier, 449 PolyBezierTo, 452 Poly Draw, 451 аффинная инвариантность, 447 делимость, 448 общие сведения, 447, 862 преобразование дуг, 457 Л лигатура, 751 линии, 442, 862 логические палитры, 705 палитра по умолчанию, 705 полутоновая палитра, 706 логические шрифты, 767 CreateFont, 806 CreateFontlndirect, 806 CreateFontlndirectEx, 806 LOGFONT, структура, 806 внешний зазор, 803 внутренний зазор, 803 имитация начертаний, 754 метрики А-В-С, 803 надстрочный интервал, 786 подстрочный интервал, 787 локальный провайдер печати, 109 м Мандельброта, множество, 418 манипуляторы, 143, 149
1068 Алфавитный указатель массив пикселов, 545 метарегион, 319, 391 метафайловый контекст устройства, 316 метафайлы, 897 EMF воспроизведение, 900 записи, 912 недокументированные типы записей, 940 палитры, 922 текст, 928 траектории, 922 WMF (метафайлы Windows), 897 микроядро, 73 мини-драйверы, 75 многоугольники, 500, 920 морфологические фильтры, 693 н надстрочный интервал, 786 О обновляемый регион, 391 объектно-ориентированное программирование, 144 классы, 144 манипуляторы, 149 объекты ядра, 149 однородные кисти, 481 отсечение бинарные операции с регионами, 394 видимость, 391 обновляемый регион, 391 общие сведения, 390, 1031 регион Рао, 398 системный регион, 391 п палитры, 697 алгоритм Флойда— Стейнберга, 739 в EMF, 922 квантование цветов, 726 логические, 705 основная палитра, 707 палитры {продолжение) реализация, 707 системная палитра, 698 сообщения, 710 фоновая палитра, 707 параллелограммы, блиттинг, 628, 667 перья, 427 логические, 427 расширенные, 433 стандартные, 429 печать, 947 архитектура, 106 драйвер принтера, 961 единая логическая система координат, 979 процессор печати, 958 прямой вывод в порт, 953 растры, 993 стандартные диалоговые окна, 965 пикселы, 370, 380 отсечение, 390 цвет, 402 подстановка шрифтов, 810 подстрочный интервал, 787 полная ширина, 787, 803 полупрозрачная заливка, 528 полутоновые палитры, 706 провайдер печати, 109 прокрутка, 373 пространственные фильтры, 686 процессоры печати PSCRIPT1, 111 назначение, ПО Р рабочий стол, вывод, 35 радиальные градиентные заливки, 530 Рао, регион, 319 растровая графика, 535 растровые кисти, 485 операции, кодировка, 609 шрифты, 758, 760 растры DIB-секции, 593 GIF, формат, 536 JPEG, формат, 536 TIFF, формат, 536 аппаратно-зависимые (DDB), 564
Алфавитный указатель 1069 растры {продолжение) аппаратно-независимые (DIB), 559 аффинные преобразования, 667 в EMF, 919 печать, 993 пометка команд меню, 584 пространственные фильтры, 686 совместимые контексты устройств, 563 расширенные перья, 433 реализация палитры, 707 регион, 509 в EMF, 921 контекста устройства, 310 метарегион, 319 окна, 391 отсечения, 319, 393 получение данных, 510 Рао, 319 системный, 318 создание объектов, 507 режимы заполнения фона, 427 оконный, 41 отображения MM_ANISOTROPIC, 352, 935 MM_HIENGLISH, 348 MM_HIMETRIC, 350 MMJSOTROPIC, 351 MM_LOENGLISH, 348 MM_LOMETRIC, 350 MM_TEXT, 348, 487, 842, 977 MM_TWIPS, 351 родительский контекст устройства, 315 с сегмент, 498 сектор, 498 семейство шрифтов, 754 системная палитра, 698 системные процессы, 72 системный регион, 318, 391 системы координат в EMF, 924 мировая, 341, 361 страничная, 341 устройства, 343 физическая, 341 совместимый контекст устройства, 316 спулер, 947 среда программирования, 50 стандартные кисти, 480 перья, 429 статические цвета, 702 страничная система координат назначение, 341 режимы отображения, 345 т твипы, 351 текстурные растры, 1050 текстуры, 292 тернарные растровые операции, 609 BLACKNESS/WHITENESS, 616 DSTINVERT, 617 MERGECOPY, 617 MERGEPAINT, 622 NOTSRCCOPY, 617 NOTSRCERASE, 622 PATCOPY, 617 PATINVERT, 635 SRCAND, 620, 639, 644 SRCERASE, 622 SRCINVERT, 623, 644 SRCPAINT, 645 список, 614 траектории, 461 в EMF, 922 замкнутые, 504 получение данных, 463 построение, 461 треугольные градиентные заливки, 523 У указатели и манипуляторы, 148 уменьшение цветовой глубины растра, 726 упакованные DIB-растры, 545 Ф фабрика класса, 1004 Флойда—Стейнберга, алгоритм, 739
1070 Алфавитный указатель фоновая палитра, 707 форматирование текста, 864 ц цвет фона, 427 цветовые ключи, 640 ш ширина символа, 840 шрифты, 744 FontSmart Homage Page (HP), 799 PANOSE, 815 TrueType, 765 TrueType/OpenType, 812 в GDI, 224 глифы, 751 шрифты (продолжение) кодировка, 745 логические, 767 моноширинные, 754 получение информации, 818 растровые, 760 семейства, 754 установка, 793 устройств, 810 штриховые кисти, 482 э эллипсы, 360, 498 Я язык описания страниц (PDL), 951 языковой монитор, 112
ишалтшаьекий аом специалистам ' книжного ^^^ \л/\л/\л/ pitpp г.пкл WWW.PITER.COM БИЗНЕСА! УВАЖАЕМЫЕ ГОСПОДА! ИЗДАТЕЛЬСКИЙ ДОМ «ПИТЕР» ПРИГЛАШАЕТ ВАС К ВЗАИМОВЫГОДНОМУ СОТРУДНИЧЕСТВУ. МЫ ПРЕДЛАГАЕМ ЭКСКЛЮЗИВНЫЙ АССОРТИМЕНТ КОМПЬЮТЕРНОЙ, МЕДИЦИНСКОЙ, ПСИХОЛОГИЧЕСКОЙ, ЭКОНОМИЧЕСКОЙ И ПОПУЛЯРНОЙ ЛИТЕРАТУРЫ. МЫ ГОТОВЫ РАБОТАТЬ ДЛЯ ВАС НЕ ТОЛЬКО В САНКТ-ПЕТЕРБУРГЕ. НАШИ ПРЕДСТАВИТЕЛЬСТВА НАХОДЯТСЯ В МОСКВЕ, МИНСКЕ, КИЕВЕ, ХАРЬКОВЕ. ЗА ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИЕЙ ОБРАЩАЙТЕСЬ ПО СЛЕДУЮЩИМ АДРЕСАМ: Россия, г. Москва Россия, г. С.-Петербург Представительство издательства «Питер», Представительство издательства «Питер», м. «Калужская», ул. Бутлерова, д. 176, оф. 207 м. «Электросила», ул. Благодатная, д. 67, и 240, тел./факс (095) 777-54-67. тел. (812) 327-93-37,294-54-65. E-mail: sales@piter.msk.ru E-mail: sales@piter.com Украина, г. Харьков Украина, г. Киев Представительство издательства «Питер», Филиал Харьковского представительства тел. (0572) 14-96-09, факс: (0572) 28-20-04, издательства «Питер», тел./факс: (044) 490-35-68, 28-20-05. Почтовый адрес: 61093, г. Харьков, 490-35-69. Адрес для писем: 04116, г. Киев-116, а/я 9130. E-mail: piter@tender.kharkov.ua а/я 2. Фактический адрес: 04073, г. Киев, пр. Красных Казаков, д. 6, корп. 1. E-mail: otfice@piter-press.kiev.ua Беларусь, г. Минск Представительство издательства «Питер», тел./факс (37517) 239-36-56. Почтовый адрес: 220100, г. Минск, ул. Куйбышева, 75. 000 «Питер М», книжный магазин «Эврика». E-mail: piterbel@tut.by КАЖДОЕ ИЗ ЭТИХ ПРЕДСТАВИТЕЛЬСТВ РАБОТАЕТ С КЛИЕНТАМИ ПО ЕДИНОМУ СТАНДАРТУ ИЗДАТЕЛЬСКОГО ДОМА «ПИТЕР». £^ Ищем зарубежных партнеров или посредников, имеющих выход на зарубежный рынок. ^ Телефон для связи: (812) 327-93-37. E-mail: grigorjan@piter.com fy£ Редакции компьютерной, психологической, экономической, юридической, медицинской, ^ учебной и популярной (оздоровительной и психологической) литературы Издательского дома «Питер» приглашают к сотрудничеству авторов. Обращайтесь по телефонам: Санкт-Петербург - тел. (812) 327-13-11, Москва-тел.: (095)234-38-15,777-54-67.
ПЗЛАТЕПЬСКПП ПОМ [>^ППТЕР* *4^ WWW.PITER.COM Башкортостан Уфа, «Азия», ул. Зенцова, д. 70 (оптовая продажа), маг. «Оазис», ул. Чернышевского, д. 88, тел./факс (3472) 50-39-00. E-mail: asiaufa@ufanet.ru Дальний Восток Владивосток, «Приморский Торговый Дом Книги», тел./факс (4232) 23-82-12. Почтовый адрес: 690091, Владивосток, ул. Светланская, д. 43. E-mail: bookbase@mail.primorye.ru Хабаровск, «Мире», тел. (4212) 30-54-47, факс 22-73-30. Почтовый адрес: 680000, Хабаровск, ул. Ким-Ю-Чена, д. 21. E-mail: postmaster@bookmirs.khv.ru Хабаровск, «Книжный мир», тел. (4212) 32-85-51, факс 32-82-50. Почтовый адрес: 680000, Хабаровск, ул. Карла Маркса, д. 37. E-mail: postmaster@worldbooks.knt.ru Европейские регионы России Архангельск, «Дом Книги», тел. (8182) 65-41-34, факс 65-41 -34. Почтовый адрес: 163061, пл. Ленина, д. 3. E-mail: book@atnet.ru Калининград, «Вестер», тел./факс (0112) 21 -56-28, 21 -62-07. Почтовый адрес: 236040, Калининград, ул. Победы, д. 6. Магазин «Книги & книжечки». E-mail: nshibkova@vester.ru; www.vester.ru Ростов-на-Дону, ПБОЮЛ Остроменский, пр. Соколова, д. 73, тел./факс (8632) 32-18-20. E-mail: ostrom@don.sitek.net Северный Кавказ Ессентуки, «Россы», ул. Октябрьская, 424, тел./факс (87934) 6-93-09. E-mail: rossy@kmw.ru Сибирь Иркутск, «ПродаЛить», тел. (3952) 59-13-70, факс 51 -30-70. Почтовый адрес: 664031, УВАЖАЕМЫЕ ГОСПОДА! КНИГИ ИЗДАТЕЛЬСКОГО ДОМА «ПИТЕР» ВЫ МОЖЕТЕ ПРИОБРЕСТИ ОПТОМ И В РОЗНИЦУ У НАШИХ РЕГИОНАЛЬНЫХ ПАРТНЕРОВ. Иркутск, ул. Байкальская, д. 172, а/я 1397. E-mail: prodalit@irk.ru; http:/www.prodalit.irk.ru Иркутск, «Антей-книга», тел./факс (3952) 33-42-47. Почтовый адрес: 664003, Иркутск, ул. Карла Маркса, д. 20. E-mail: antey@irk.ru Красноярск, «Книжный Мир», тел./факс (3912) 27-39-71. Почтовый адрес: 660049, Красноярск, пр. Мира, д. 86. E-mail: book-world@public.krasnet.ru Нижневартовск, «Дом книги», тел. (3466) 23-27-14, факс 23-59-50. Почтовый адрес: 628606, Нижневартовск, пр. Победы, д. 12. E-mail: book@nvartovsk.wsnet.ru Новосибирск, «Топ-книга», тел. (3832) 36-10-26, факс 36-10-27. Почтовый адрес: 630117, Новосибирск, а/я 560. E-mail: office@top-kniga.ru; http://www.top-kniga.ru Тюмень, «Друг», тел./факс (3452) 21-34-39, 21-34-82. Почтовый адрес: 625019, ул. Республики, д. 211. E-mail: drug@tyumen.ru Тюмень, «Фолиант», тел. (3452) 27-36-06, факс 27-36-11. Почтовый адрес: 625039, Тюмень, ул. Харьковская, д. 83а. E-mail: foliant@tyumen.ru Татарстан Казань, «Таис», тел. (8432) 72-34-55, факс 72-27-82. Почтовый адрес: 420073, Казань, ул. Гвардейская, д. 9а. E-mail: tais@bancorp.ru Урал Екатеринбург, магазин № 14, ул. Челюскинцев, д. 23, тел./факс (3432) 53-24-90. E-mail: gvardia@mail.ur.ru Екатеринбург, «Валео-книга», ул. Ключевская, д. 5, тел. (3432) 42-07-75, факс 42-56-00. E-mail: valeo@etel.ru
Фень Юань Программирование графики для Windows Е^ППТЕР
Название: Программирование графики для Windows.
Автор: Фень Юань.
2002.
Книга посвящена графическому программированию для Windows с использованием Win32 GDI API. Кроме того, в ней приведены начальные сведения о DirectDraw и краткое введение в непосредственный режим Direct3D. Рассматриваются стандартные возможности, поддерживаемые на всех платформах Win32, 32-разрядные возможности, реализованные только в Windows NT/2000, и новейшие расширения GDI, появившиеся только в Windows 2000 и Windows 98. В книге приведено множество фрагментов кода, подходящих для практического применения. Помимо простейших тестовых и демонстрационных программ, вы найдете в ней множество функций, классов C++, драйверов, утилит и нетривиальных программ, вполне подходящих для использования в коммерческих проектах.
Содержание
Благодарности.
Введение.
О чем эта книга.
Как организована эта книга.
Как читать эту книгу.
Что находится на компакт-диске.
Что дальше?.
От издательства.
Глава 1. Основные принципы и понятия.
Основы программирования для Windows на C/C++.
Hello World, версия 1: запуск браузера.
Hello World, версия 2: вывод текста на рабочем столе.
Hello, World, версия 3: создание полноэкранного окна.
Hello, World, версия 4: вывод средствами DirectDraw.
Ассемблер.
Среда программирования.
Разработка и тестирование.
Компиляторы.
Microsoft Platform SDK.
Microsoft Driver Development Kit.
Microsoft Developer Network.
Формат исполняемых файлов Win32.
Каталог импорта.
Каталог экспорта.
Архитектура операционной системы Microsoft Windows.
HAL.
Микроядро.
Драйверы устройств.
Управление окнами и графическая система.
Исполнительная часть.
Системные функции.
Системные процессы.
Службы.
Платформенные подсистемы.
Итоги.
Примеры программ.
Глава 2. Архитектура графической системы Windows.
Компоненты графической системы Windows.
Мультимедиа.
Video for Windows.
Still Image.
OpenGL .
Windows Media.
Компоненты режима ядра.
Драйверы режима ядра.
Архитектура GDI.
Функции, экспортируемые из GDI32.DLL.
Группы функций GDI.
Вызовы системных функций GDI.
От Win32GDIAPlк системным функциям механизма GDI.
Архитектура DirectX.
Компоненты DirectX.
Архитектура DirectDraw.
Архитектура системы печати.
Клиент спулера Win32.
Служба спулера.
Маршрутизатор спулера.
Провайдер печати.
Процессор печати.
Языковой монитор и монитор порта.
Процесс спулера изнутри.
Графический механизм
Системные функции графического механизма.
Механизм графической визуализации.
Структуры данных графического механизма.
Преобразование в примитивы.
Шрифтовые драйверы.
Драйверы экрана.
Драйвер видеопорта и мини-драйвер видеопорта.
Назначение драйвера экрана.
Инициализация драйвера экрана.
Вывод на поверхность, перехват и возврат.
Дополнительные возможности драйвера.
Поддержка DirectDraw/Direct3D на уровне драйвера экрана.
Драйверы принтеров.
Управляющие драйверы принтеров от Microsoft
Графическая библиотека DLL драйвера принтера. Драйвер принтера для вывода документа HTML
Итоги.
Примеры программ.
Глава 3. Внутренние структуры данных GDI/DirectDraw
Манипуляторы и объектно-ориентированное программирование.
Класс и объект.
Инкапсуляция и маскировка реализации.
Указатели и манипуляторы.
Тождественное отображение.
Табличное отображение.
Когда манипулятора недостаточно.
Расшифровка манипуляторов объектов GDI.
Манипуляторы стандартных объектов — константы.
HGDIOBJ не является указателем.
Максимальное количество манипуляторов GDI
на уровне процесса-12 000.
Максимальное количество манипуляторов
на уровне системы-16
Часть HGDIOBJ содержит индекс.
Часть HGDIOBJ содержит тип объекта GDI.
Поиск таблицы объектов GDI.
Расшифровка таблицы объектов GDI.
Указатель pKernel ссылается на выгружаемый пул.
Поле nCount иногда используется как счетчик выбора объектов.
Поле nProcess связывает манипулятор GDI с конкретным процессом
nUpper: дополнительная проверка.
пТуре: внутренний тип объекта.
pUser: указатель на структуру данных пользовательского режима.
Структуры данных пользовательского режима.
Структура данных пользовательского режима для кистей: оптимизация создания однородных кистей.
Структура данных пользовательского режима для регионов: оптимизация прямоугольных регионов.
Структура данных пользовательского режима для шрифтов: таблица значений ширины.
Структура данных пользовательского режима для контекста устройства: атрибуты
Обращение к адресному пространству режима ядра.
WinDbg и расширение отладчика GDI.
Структуры данных режима ядра.
Таблица объектов GDI в механизме GDI.
Типы объектов GDI в механизме GDI.
Контекст устройства в механизме GDI.
Структура PDEV в механизме GDI.
Поверхности в механизме GDI.
Аппаратно-зависимые растры в механизме GDI.
DIB-секции в механизме GDI.
Кисти в механизме GDI.
Перья в механизме GDI.
Палитры в механизме GDI.
Регионы в механизме GDI.
Траектории в механизме GDI.
Шрифты в механизме GDI.
Другие объекты GDI в механизме GDI.
Структуры данных DirectDraw.
Итоги.
Примеры программ.
Глава 4. Мониторинг графической системы Windows.
Отслеживание вызовов функций Win32 API.
Построение программы мониторинга.
Внедрение DLL-разведчика.
Подключение к цепочке вызовов функций API.
Сбор информации.
Вывод данных .
Управляющая программа.
Отслеживание вызовов Win32 GDI.
Файл определения GDI API.
Декодер данных GDI.
Полный мониторинг API.
Отслеживание СОМ-интерфейсов DirectDraw.
Таблица виртуальных функций.
Определение DirectDraw API.
Модификация таблицы виртуальных функций.
Отслеживание системных вызовов GDI.
Отслеживание интерфейса DDI.
Итоги.
Примеры программ
Глава 5. Абстракция графического устройства.
Современные видеоадаптеры.
Кадровый буфер.
Формат пикселов.
Двойная буферизация, z-буфер и текстуры.
Аппаратное ускорение.
Экранное устройство и перечисление режимов.
Контекст устройства.
Создание контекста устройства.
Получение информации о возможностях устройства.
Атрибуты в контексте устройства.
Связь контекста устройства с окном.
Графический вывод в многооконной среде.
Получение контекста устройства, связанного с окном.
Общий контекст устройства.
Классовый контекст устройства.
Закрытый контекст устройства.
Родительский контекст устройства.
Прочие контексты устройств.
Информационный контекст устройства.
Совместимый контекст устройства.
Метафайловый контекст устройства.
Формальное представление контекста устройства.
Пример: родовой класс рамочного окна.
Класс панели инструментов.
Класс строки состояния.
Класс холста.
Класс рамочного окна.
Тестовая программа.
Пример программы: графический вывод в контексте устройства.
Обновляемый регион окна.
Сообщение WM_PAINT.
Наглядное представление сообщений перерисовки окна.
Итоги.
Примеры программ.
Глава 6. Системы координат и преобразования.
Физическая система координат.
Система координат устройства.
Страничная система координат и режимы отображения.
Режим отображения ММ_ТЕХТ.
Режимы отображения MMJ.OENGLISH и MMJHIENGLISH
Режимы отображения MM.LOMETRIC и MMJHIMETRIC
Режим отображения MM_TWIPS.
Режим отображения MMJSOTROPIC.
Режим отображения MM.ANISOTROPIC.
Базовые точки окна и области просмотра.
Другие функции окна и области просмотра.
Мировая система координат.
Аффинные преобразования.
Функции мировых преобразований в Win32 API.
Использование мировых преобразований.
Использование систем координат.
Реализация преобразований в GDI.
Пример программы: прокрутка и масштабирование.
Игра го в классе KScrollCanvas.
Итоги.
Примеры программ.
Глава 8. Линии и кривые.
Бинарные растровые операции.
Режим заполнения фона и цвет фона.
Перья.
Объект логического пера.
Стандартные перья.
Простые перья.
Расширенные перья.
Получение информации о логических перьях.
Класс для работы с объектами перьев GDI.
Линии.
Кривые Безье.
PolyDraw.
Альтернативное определение кривых Безье.
Дуги.
Определение дуги в градусах: функция AngleArc.
Рисование дуг пером со стилем PSJNSIDEFRAME.
Преобразование дуг в кривые Безье.
Траектории.
Построение траектории.
Получение информации о траектории.
Преобразование объекта траектории
Графические операции с использованием траекторий.
Преобразование пути в регион.
Пример: рисование нестандартных стилевых линий.
Итоги.
Пример программы.
Глава 9. Замкнутые области.
Кисти.
Объект логической кисти.
Стандартные кисти
Пользовательские кисти.
Кисти системных цветов.
Структура L0GBRUSK.
Прямоугольники.
Прямоугольник как структура данных.
Рисование прямоугольников.
Прорисовка границ и элементов управления.
Эллипсы, секторы, сегменты и закругленные прямоугольники.
Многоугольники.
Режим заполнения многоугольников.
Замкнутые траектории.
Регионы.
Создание объекта региона.
Операции с объектами регионов.
Прорисовка регионов.
Градиентные заливки.
Градиентная заливка прямоугольников.
Применение градиентных заливок для создания объемных кнопок Практическое использование заливок.
Полупрозрачная заливка.
Реализация градиентных заливок в цветовом пространстве HLS.
Радиальные градиентные заливки.
Текстурные и растровые заливки.
Узорные заливки Итоги.
Пример программы.
Глава 10. Основные сведения о растрах
Аппаратно-независимые растры.
Файловый формат BMP.
Упакованный аппаратно-независимый растр.
Разделенный аппаратно-независимый растр.
Класс для работы с DIB.
Отображение DIB в контексте устройства.
StretchDIBits.
Исходный прямоугольник.
Приемный прямоугольник и режимы масштабирования.
Преобразование цветового формата.
Растровая операция.
Пример использования функции StretchDIBits.
SetDIBitsToDevice.
Совместимые контексты устройств.
Аппаратно-зависимые растры.
CreateBitmap.
CreateBitmapIndirect
GetObjectи DDB.
CreateCompatibleBitmapMCreateDiscardableBitmap
CreateDIBitmap.
LoadBitmap.
Копирование растров между форматами DIB и DDB.
Прямой доступ к массиву пикселов DDB.
Использование DDB-расгров.
Отображение DDB-расгров.
Использование растров в меню.
Использование растра в качестве фона окна.
CreateDIBSection.
Класс для работы С DIB-секциями.
Функции GetObjectType и GetObjectдл я DIB-секций
GetDIBColorTable и SetDIBColorTable.
Применение DIB-секций: аппаратно-независимый вывод
Применение DIB-секций: вывод в высоком разрешении.
Итоги.
Примеры программ.
Глава 11. Нетривиальное использование растров.
Тернарные растровые операции.
Коды растровых операций.
Диаграмма тернарных растровых операций.
Часто используемые растровые операции.
Прозрачные растры.
Функция PlgBIt.
Кватернарные растровые операции :MaskBlt.
Цветовые ключи: TransparentBIt.
Прозрачность без маски.
Прозрачный вывод с использованием геометрических фигур.
Прозрачный вывод с использованием отсечения.
Предварительная подготовка изображений.
Альфа-наложение.
Пример альфа-наложения с постоянным коэффициентом.
Постепенное проявление и исчезновение растров.
Прозрачные окна.
Альфа-канал: KnacCAirBrush.
Имитация альфа-наложения.
Итоги.
Примеры программ.
Глава 12. Графические алгоритмы и растры Windows
Прямой доступ к пикселам.
Аффинные преобразования растров.
Быстрые специализированные преобразования растров.
Преобразования цветов.
Преобразование растров в оттенки серого.
Гамма-коррекция.
Преобразование пикселов в растрах
Родовой класс преобразований пикселов.
Родовой класс цветоделения.
Пример выделения каналов.
Гистограмма.
Пространственные фильтры.
Фильтры сглаживания и резкости.
Выделение границ и рельеф.
Морфологические фильтры.
Итоги.
Примеры программ.
Глава 13. Палитры
Системная палитра.
Параметры экрана.
Получение системной палитры.
Статические цвета
Логическая палитра.
Палитра по умолчанию.
Полутоновая палитра
Создание специализированной палитры.
Сообщения палитры.
WM_QUERYNEWPALETTE.
WM.PALETTEISCHANGING.
WM_PALETTECHANGED.
Тестовая программа.
Палитра и растры.
Аппаратно-зависимые растры и палитры.
Аппаратно-независимые растры и палитры.
Индекс палитры в цветовой таблице DIB.
DIB-секций и палитра
Квантование цветов.
Сокращение цветовой глубины растра.
Пример программы.
Глава 14. Шрифты
Что такое шрифт?.
Наборы символов и кодировки.
Глифы.
Шрифт.
Семейство шрифтов и начертание.
Растровые шрифты.
Векторные шрифты.
Шрифты TrueType.
Формат файлов шрифтов TrueType.
Заголовок шрифта.
Максимальный профиль.
Отображение символов в индексы глифов.
Индексная таблица.
Данные глифов.
Инструкции глифа.
Горизонтальные метрики.
Кернинг.
Метрики OS/2 и Windows.
Другие таблицы.
Коллекции TrueType.
Установка и внедрение шрифтов.
Ресурсные файлы шрифтов.
Установка открытых шрифтов.
Установка закрытых шрифтов и шрифтов Multiple Master OpenType.
Установка шрифтов из образа в памяти.
Внедрение шрифтов.
Системная таблица шрифтов.
Итоги.
Примеры программ.
Глава 15. Текст
Логические шрифты.
Метрики шрифтов в Windows.
Стандартные шрифты.
Создание логических шрифтов.
Подстановка шрифта.
Система подстановки шрифтов PANOSE.
Получение информации о логическом шрифте.
Метрики растровых и векторных шрифтов.
Метрики шрифтов TrueType/OpenType
Структура LOGFONTи метрики шрифта.
Точность шрифтовых метрик.
Простой вывод текста.
Выравнивание текста.
Вывод текста справа налево.
Дополнительные интервалы.
Ширина символа.
Нетривиальный вывод текста.
Преобразование символов в глифы.
Кернинг.
Расположение символов.
Функция ExtTextOut.
Uniscribe.
Доступ к данным глифов.
Форматирование текста.
Вывод текста с табуляцией.
Простое абзацное форматирование.
Аппаратно-независимоеформатирование текста Эффекты при выводе текста.
Цветтекста.
Начертания.
Геометрические эффекты.
Работа с текстом в растровом формате.
Текст как совокупность кривых.
Текст как регион.
Итоги.
Пример программы.
Глава 16. Метафайлы.
Общие сведения о метафайлах.
Создание расширенного метафайла.
Воспроизведение расширенного метафайла.
Получение информации о расширенном метафайле.
Передача расширенных метафайлов.
Строение расширенных метафайлов.
Записи EMF.
Классификация типов записей EMF.
Расшифровка записей EMF.
Простые объекты GDI в EMF.
Растры в EMF.
Регионы в EMF.
Траектории в EMF.
Палитры в EMF.
Системы координат в EMF.
Команды вывода в EMF
Аппаратная независимость EMF Перечисление записей EMF.
Класс C++ для перечисления записей EMF
Замедленное воспроизведение EMF
Трассировка воспроизведения EMF
Динамическое изменение EMF.
Построение производных метафайлов EMF как средство программирования
Декомпилятор EMF.
Сохранение EMF-файла спулера Итоги.
Дополнительная информация.
Примеры программ.
Глава 17. Печать.
Знакомство со спулером.
Процесс печати.
Язык управления принтером.
Прямой вывод в порт.
Печать с использованием спулера.
Процессор печати EMF.
Перечисление принтеров.
Получение информации о принтере.
Настройка драйвера принтера Базовая печать средствами GDI
Стандартные диалоговые окна печати
Создание контекста устройства принтера
Получение информации о контексте устройства принтера
Последовательность формирования заданий печати Поддержка печати в программах
Единая логическая система координат
Имитация внешнего вида
Одновременный вывод
Печать нескольких страниц на одном листе.
Родовой класс печати.
Вывод в контексте устройства принтера.
Единицы измерения.
Текст.
Исполнительная часть.
Microsoft определяет исполнительную часть (Executive) Windows NT/2000 как совокупность компонентов режима ядра, образующих базовую операционную систему Windows NT/Windows 2000. Помимо HAL, микроядра и драйверов устройств, в исполнительную часть также входят компоненты исполнительной поддержки, диспетчера памяти, диспетчера кэша, структуры процессов, межпроцессных взаимодействий (LPC и RPC), диспетчера объектов, диспетчера ввода-вывода, диспетчера конфигурации и монитора безопасности.
Каждый компонент исполнительной части поддерживает набор системных функций, которые могут вызываться из пользовательского режима (кроме диспетчера кэша и HAL) при помощи прерываний. Кроме того, каждый компонент предоставляет точку входа, доступную только для модулей, работающих в адресном пространстве ядра.
Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Программирование графики для Windows — Фень Юань. — fileskachat.com, быстрое и бесплатное скачивание.
Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.Купить эту книгу
Скачать книгу — Программирование графики для Windows — Фень Юань. — depositfiles
Скачать книгу — Программирование графики для Windows — Фень Юань. — letitbit
Дата публикации:
Теги:
книга по программированию :: графика windows :: Фень Юань
Следующие учебники и книги:
- Стандартизация разработки программных средств — Благодатских В.А., Волнин В.А., Поскакалов К.Ф.
- Приемы ООП, паттерны проектирования, Гамма, Хелм, Джонсон
- Приемы объектно — ориентированного проектирования — Паттерны проектирования — Гамма Э., Хелм Р., Джонсон Р.
- Программирование в среде Visual Basic for Applications — Демидова Л.А., Пылькин А.Н.
Предыдущие статьи:
- Наиболее эффективное использование C++ — 35 новых рекомендаций по улучшению ваших программ и проектов — Мейерс С.
- C++Builder 6 — Справочное пособие — Книга 2 — Классы и компоненты — Архангельский А.Я.
- C++Builder 6 — Справочное пособие — Книга 1 — Язык С++ — Архангельский А.Я.
- C++ Библиотека программиста — Джефф Элджер.
Фень юань — это комплексное руководство по программированию графики для операционной системы Windows, представленное в виде диска с уроками и примерами для практического обучения.
Фень юань, разработанный специально для начинающих программистов, предлагает подробное изучение основных аспектов программирования графики, таких как создание и управление окнами, отображение и анимация объектов, работа с 2D и 3D графикой, а также обработка пользовательского ввода.
Диск содержит практические примеры и уроки, которые позволяют быстро освоить основные концепции программирования графики, а также научиться создавать собственные впечатляющие графические приложения для Windows.
Фень юань представляет собой источник бесценной информации для всех, кто желает развить свои навыки программирования и раскрыть свой творческий потенциал в области графики. Получите доступ к основам программирования графики и откройте новые возможности для создания уникальных и многофункциональных приложений.
Содержание
- Фень юань
- Программирование графики для Windows
- Диск с уроками
- Диск с примерами
- Функциональные возможности Фень юань
- Применение Фень юань в разработке
- Рекомендации по использованию Фень юань
Фень юань
Основной язык программирования, используемый в Фень юань, это С++. Этот язык является основным для разработки приложений под Windows и широко используется в индустрии программного обеспечения. Помимо С++, Фень юань также поддерживает другие языки программирования, такие как C# и Java.
На диске с уроками и примерами представлены различные обучающие материалы, которые позволят освоить Фень юань начинающим программистам. Уроки пошагово рассказывают о базовых принципах программирования графики, демонстрируя практические примеры и задания для самостоятельной работы.
Программирование графики с использованием Фень юань позволяет создавать уникальные и интерактивные пользовательские интерфейсы, а также визуализировать данные и создавать эффектные анимации. Этот инструмент отлично подходит для разработки различных приложений, начиная от игр и мультимедиа, и заканчивая профессиональными программами для дизайна и архитектуры.
Фень юань представляет собой мощный инструмент для разработки графических приложений под Windows. На диске с уроками и примерами вы найдете всю необходимую информацию и материалы, чтобы освоить этот инструмент и создавать потрясающие графические проекты.
Программирование графики для Windows
Для программирования под Windows можно использовать различные технологии, одна из которых — Фень юань. Фень юань предоставляет разработчикам широкие возможности для создания графических интерфейсов приложений на языке программирования С++.
Программирование графики для Windows с помощью Фень юань дает возможность создавать разнообразные эффекты и анимации, управлять расположением и внешним видом элементов интерфейса, обрабатывать события разных типов, такие как клики, перемещения мыши, нажатия клавиш и другие.
Основными преимуществами использования Фень юань являются простота разработки и хорошая производительность приложений, созданных с его помощью. Библиотека Фень юань предоставляет разработчикам удобные инструменты для работы с элементами интерфейса и графическим контекстом.
Для изучения программирования графики для Windows и работы с Фень юань можно использовать диск с уроками и примерами, который предлагается в рамках данной темы. На данном диске содержится подробная документация, примеры на различные темы, задания для самостоятельного изучения и многое другое. Этот диск поможет разработчику освоить графическое программирование для Windows и стать профессионалом в этой области.
| Преимущества программирования графики для Windows с помощью Фень юань | Широкие возможности для создания графических интерфейсов |
| Простота разработки и хорошая производительность | Библиотека Фень юань предоставляет удобные инструменты |
| в работе с элементами интерфейса и графическим контекстом |
Диск с уроками
На диске с уроками вы найдете подробные инструкции по созданию графических приложений на языке Фень юань. Уроки охватывают различные аспекты программирования, включая работу с графическими элементами, анимацию, обработку событий и многое другое.
Каждый урок сопровождается примером, который вы можете выполнить и изучить, чтобы лучше понять принципы работы программирования графики для Windows. Примеры представлены в виде кода, который можно запустить и поиграться с ним, чтобы углубить свои знания и навыки.
Диск с уроками также включает дополнительный материал, такой как шаблоны и библиотеки, которые могут быть полезны при разработке графических приложений. Вы можете использовать эти материалы в своих проектах, чтобы ускорить процесс разработки и улучшить производительность вашего приложения.
Диск с уроками можно использовать как для самостоятельного изучения, так и для обучения в группе. Он предоставляет все необходимые материалы для освоения программирования графики для Windows и быстрого применения полученных знаний в своих проектах.
Не упустите возможность изучить программирование графики для Windows с помощью диска с уроками Фень юань. Получите все необходимые знания и навыки для создания удивительных графических приложений прямо сейчас!
Диск с примерами
Диск с уроками и примерами представляет собой полезный инструмент для тех, кто хочет овладеть программированием графики для Windows с помощью Фень юань. На диске вы найдете множество примеров кода, которые помогут вам разобраться в основных принципах программирования графики и изучить различные техники.
Примеры на диске распределены по темам, что позволяет удобно найти нужный пример и изучить его. Вы сможете увидеть, как создавать различные графические элементы, рисовать простые и сложные фигуры, работать с разными цветами и шрифтами.
Кроме того, диск содержит уроки, которые пошагово объясняют основы программирования графики с помощью Фень юань. Все уроки сопровождаются кодом и визуальными примерами, что поможет вам лучше понять материал.
Диск также содержит дополнительные материалы, которые могут быть полезными вам при изучении программирования графики. Вы сможете найти справочники и документацию, которые предоставят вам дополнительную информацию о различных аспектах программирования графики в Windows.
Функциональные возможности Фень юань
Фень юань предоставляет различные функции и возможности для программирования графики в операционной системе Windows. Вот некоторые из них:
-
Создание и управление графическими объектами, такими как окна, кнопки, текстовые поля и другие элементы интерфейса пользователя.
-
Работа с различными типами графических ресурсов, включая изображения, шрифты и кисти.
-
Отрисовка графических примитивов, таких как линии, кривые, прямоугольники и эллипсы.
-
Возможность использования различных графических эффектов, таких как закрашивание, прозрачность и тени.
-
Реагирование на пользовательские действия, такие как нажатия клавиш и клики мыши.
-
Работа с анимацией и мультимедиа, включая воспроизведение звука и видео.
-
Поддержка многоязычности и международных символов.
Эти функциональные возможности Фень юань позволяют разработчикам создавать интерактивные и визуально привлекательные приложения для Windows с использованием программирования графики.
Применение Фень юань в разработке
Фень юань предоставляет программистам возможность создавать графические приложения для операционной системы Windows, используя язык программирования C++. Библиотека Фень юань предоставляет набор функций и классов для работы с графикой, а также инструменты для создания интерфейса пользователя.
С использованием Фень юань можно создавать 2D и 3D графические приложения, включая игры, визуализацию данных, трехмерное моделирование, компьютерную графику и многое другое. Библиотека предоставляет широкий спектр возможностей для работы с графикой, таких как отрисовка простых геометрических объектов, работа с текстом, текстурирование, анимация и многое другое.
Фень юань обладает высокой производительностью и эффективностью, что делает ее идеальным выбором для разработки графических приложений под Windows. Библиотека оптимизирована для работы с аппаратным ускорением и поддерживает использование графических ускорителей.
Учебные материалы, предоставляемые на диске, позволяют освоить основы программирования графики с использованием Фень юань. На диске содержатся уроки и примеры, которые помогут разобраться в основных концепциях и возможностях библиотеки. Это поможет начинающим программистам быстро освоить Фень юань и приступить к разработке своих графических приложений.
Фень юань является мощным инструментом для разработки графических приложений под Windows. Она позволяет программистам создавать высококачественные и производительные графические приложения с минимальными усилиями. Благодаря своим возможностям и широкому спектру применений, Фень юань стала популярным инструментом среди разработчиков графических приложений для Windows.
Рекомендации по использованию Фень юань
Для того, чтобы эффективно использовать программирование графики для Windows с помощью Фень юань, вам следует учесть несколько рекомендаций:
1. Изучение документации: перед началом работы с Фень юань рекомендуется тщательно изучить документацию, поскольку она содержит полезную информацию о возможностях фреймворка и особенностях его использования.
2. Практика на примерах: для лучшего понимания концепций и методов программирования графики в Фень юань, рекомендуется выполнять упражнения и задания из уроков и примеров, представленных на диске.
3. Освоение основ: перед тем, как перейти к более сложным темам или проектам, необходимо уверенно освоить основные понятия и методы программирования графики в Фень юань.
4. Экспериментирование: не бойтесь экспериментировать и пробовать различные варианты реализации задач и идей. Только путем практики и исследований можно достичь высокого уровня владения Фень юань.
Следуя данным рекомендациям, вы сможете максимально эффективно использовать Фень юань для программирования графики на платформе Windows.
Фень юань — это высокопроизводительная библиотека программирования графики для операционной системы Windows. Она предоставляет разработчикам удобные инструменты для создания впечатляющих визуальных эффектов и интерактивных приложений.
Программирование графики с использованием Фень юань позволяет создавать реалистичные трехмерные модели, анимацию, симуляцию физических процессов и многое другое. Библиотека обладает широкими возможностями и предоставляет разнообразные функции для работы с 2D и 3D графикой.
Фень юань включает в себя мощные инструменты для работы с графикой, включая графический движок, поддержку шейдеров, алгоритмы трассировки лучей и многое другое. Благодаря своей производительности и функциональности, Фень юань широко используется в различных отраслях, включая игровую индустрию, архитектуру, визуализацию данных и промышленный дизайн.
Если вы заинтересовались программированием графики для Windows и хотите создавать впечатляющие визуальные эффекты, то Фень юань — лучший выбор для вас. Эта библиотека не только обладает богатыми возможностями, но и предоставляет интуитивно понятный и простой в использовании интерфейс программирования приложений (API). Начните сегодня и откройте для себя мир графического программирования с Фень юань!
Содержание
- Возможности программирования графики с помощью Фень юань
- Преимущества использования Фень юань для разработки графических приложений
- Основные инструменты и функциональность Фень юань
- Примеры графических приложений, созданных с использованием Фень юань
- Интеграция Фень юань с другими инструментами разработки
- Результаты использования Фень юань: успехи и отзывы разработчиков
Возможности программирования графики с помощью Фень юань
Фень юань обладает широким набором функций, которые позволяют вам контролировать различные аспекты графического вывода. Вы можете настраивать цвета, размеры и стили, создавать анимации, работать с текстом и изображениями, а также использовать специальные эффекты, такие как тени, переходы и прозрачность.
С помощью Фень юань вы можете создавать 2D и 3D графику, включая векторные и растровые изображения. Вы можете рисовать примитивы, такие как линии, окружности и прямоугольники, а также использовать текстуры, шрифты и многое другое.
Фень юань также обладает возможностями работы с графическими устройствами, такими как принтеры и сканеры. Вы можете выводить графику на экран, сохранять ее в файлы и печатать. Благодаря интеграции с операционной системой Windows, Фень юань предоставляет доступ к множеству устройств ввода и вывода, а также позволяет взаимодействовать с другими приложениями.
Фень юань обеспечивает простой и интуитивно понятный интерфейс программирования графики. Он поддерживает различные языки программирования, включая C++, C#, Visual Basic и многие другие. Благодаря своей мощности и гибкости, Фень юань становится популярным инструментом среди разработчиков и дизайнеров, позволяя им воплощать свои творческие идеи в реальность.
Преимущества использования Фень юань для разработки графических приложений
- 1. Простота и удобство в использовании. Фень юань предоставляет разработчикам удобный и интуитивно понятный интерфейс для создания графических приложений под Windows.
- 2. Богатый набор функциональных возможностей. Фень юань обладает мощным инструментарием для работы с графикой, позволяя создавать сложные и красочные приложения.
- 3. Высокая производительность. Фень юань оптимизирован для работы на Windows, что обеспечивает быстрое и плавное взаимодействие с графическим интерфейсом.
- 4. Широкая совместимость. Созданные с помощью Фень юань приложения могут быть запущены на различных версиях Windows без каких-либо дополнительных настроек и модификаций.
- 5. Поддержка множества языков программирования. Фень юань позволяет разработчикам использовать различные языки программирования для создания приложений, включая C++, C#, Visual Basic и другие.
В целом, использование Фень юань для разработки графических приложений на платформе Windows позволяет разработчикам создавать высококачественные и интерактивные приложения с минимальными усилиями и максимальной эффективностью.
Основные инструменты и функциональность Фень юань
Фень юань представляет собой мощный инструмент для программирования графики в операционной системе Windows. Вот некоторые из основных инструментов и функциональности, доступных в Фень юань:
- Графический контекст: Фень юань предоставляет возможность создавать и управлять графическим контекстом, который является основным местом для рисования всех графических элементов.
- Фигуры и линии: Фень юань позволяет создавать различные фигуры, такие как прямоугольники, круги и эллипсы, а также рисовать линии различной толщины и стиля.
- Текст и шрифты: С помощью Фень юань вы можете добавлять текстовые элементы на вашу графическую сцену, выбирать шрифты, задавать цвет, размер и стиль текста.
- Изображения и текстуры: Фень юань поддерживает загрузку и отображение изображений, а также возможность использовать текстуры для заполнения фигур и линий.
- Анимация: Фень юань предоставляет средства для создания анимации, позволяя анимировать перемещение, вращение и изменение размера графических элементов.
- События пользователей: Фень юань поддерживает обработку различных событий пользователей, таких как нажатие кнопок мыши, перемещение мыши и нажатие клавиш на клавиатуре.
Все эти инструменты и функциональность позволяют легко создавать интерактивные и красочные графические приложения для Windows с помощью Фень юань. Он идеально подходит для разработки игр, визуализации данных и создания пользовательского интерфейса.
Примеры графических приложений, созданных с использованием Фень юань
Ниже приведены несколько примеров графических приложений, которые были разработаны с использованием Фень юань:
1. Интерактивный графический редактор. Данный тип приложения позволяет пользователю создавать и редактировать изображения, применять различные эффекты и фильтры к ним, а также сохранять их в различных форматах.
2. 3D моделирование и визуализация. Фень юань предоставляет возможность разработки приложений для создания и визуализации трехмерных моделей. С помощью данного приложения пользователь может создавать сложные 3D объекты, осуществлять их редактирование, применять различные материалы и освещение.
3. Система управления графикой в играх. Фень юань используется для разработки системы управления графикой в компьютерных играх. С его помощью можно реализовать различные эффекты, такие как динамические тени, специальные эффекты, сглаживание изображений и многое другое.
4. Медицинские приложения. Фень юань позволяет разрабатывать графические приложения для медицинских целей. Такие приложения могут использоваться в медицинских учреждениях для визуализации данных, таких как снимки и изображения органов, а также для обработки и анализа полученной информации.
5. Презентационные приложения. Фень юань может быть использован для создания графических презентаций с использованием анимации, эффектов перехода, включения видео и звука. Такие приложения могут быть использованы для проведения презентаций, тренировок и обучения.
Это лишь некоторые примеры графических приложений, созданных с использованием Фень юань. Благодаря своим мощным возможностям и гибкости, Фень юань открывает перед разработчиками множество возможностей для создания разнообразных графических приложений для операционной системы Windows.
Интеграция Фень юань с другими инструментами разработки
Фень юань предлагает широкий набор функций для разработки графических приложений под Windows. Для удобства разработчиков Фень юань интегрируется с различными инструментами и библиотеками.
Одной из ключевых возможностей интеграции Фень юань с другими инструментами является возможность использования его API вместе с языками программирования, такими как C++, C#, Delphi и другими. Это позволяет разработчикам использовать привычный язык программирования, одновременно получая доступ к функциональным возможностям Фень юань.
Кроме того, Фень юань обеспечивает интеграцию с популярными IDE (Integrated Development Environment) для удобства разработки. Например, Фень юань поддерживает интеграцию с Visual Studio, позволяя разработчикам использовать его функциональность, такую как отладка, автодополнение кода и другие инструменты, в процессе создания приложений с использованием Фень юань.
Фень юань также предоставляет возможность интеграции с библиотеками и фреймворками сторонних разработчиков. Например, с помощью Фень юань можно взаимодействовать с библиотеками работы с графикой, базами данных, сетевыми протоколами и прочими, что позволяет использовать возможности этих библиотек вместе с функциональностью Фень юань.
- Интеграция с Visual Studio
- Использование API Фень юань с различными языками программирования
- Интеграция с библиотеками и фреймворками сторонних разработчиков
Интеграция Фень юань с другими инструментами разработки обеспечивает гибкость и удобство для разработчиков, позволяя им использовать все преимущества функциональности Фень юань вместе с инструментами, которые они уже знают и привыкли использовать.
Результаты использования Фень юань: успехи и отзывы разработчиков
Он предоставляет широкий набор функций и возможностей, позволяющих создавать привлекательные и функциональные пользовательские интерфейсы. Разработчики, использующие Фень юань, отмечают высокую скорость работы и простоту в использовании.
Благодаря Фень юань разработчики могут создавать сложные графические приложения, включая игры, инструменты моделирования и визуализации, а также различные специализированные программы. Гибкий подход к программированию позволяет адаптировать Фень юань под различные требования проекта и максимально использовать его возможности.
Отзывы разработчиков о Фень юань в основном положительные. Они отмечают высокую производительность и стабильность среды разработки, а также удобство в работе с графическими элементами. Разработчики также отмечают отличную документацию и активное сообщество поддержки, что делает использование Фень юань еще более привлекательным.
Вывод: Фень юань является эффективным и популярным инструментом для программирования графических интерфейсов в Windows диска. Он предоставляет разработчикам широкий набор возможностей, гибкость, простоту в использовании и высокую производительность. Отзывы разработчиков подтверждают успешность и эффективность Фень юань в создании привлекательных и функциональных пользовательских интерфейсов.
Загрузка…
Навазние: Программирование графики для Windows
Автор: Фень Юань
Издательство: Питер
Год: 2002
ISBN: 5-318-00297-8
PDF: 17 Мб
DJVU: 34 Мб
+ 2 Мб (исходный код)
Книга Фень Юань «Программирование графики для Windows» содержит в себе описание графического программирования для Windows с использованием Win32 GDI API. Также здесь описываются начальные сведения о DirectDraw и краткое введение в непосредственный режим Direct3D. В данном издании приводится рассмотрение стандартных возможностей, которые поддерживаются на всех платформах Win32, 32-разрядных возможностей, воплощённых только в Windows NT/2000, и самых новых расширений GDI, которые появились лишь в Windows 2000 и Windows 98. Здесь же пользователь найдёт много фрагментов кода для их применения на практике. Кроме того что в книге имеются простейшие тестовые коды, читатель сможет найти в ней множество функций, драйверов, утилит, классов C++ и нетривиальные программы, подходящие для применения их в коммерческих проектах. Книга дополняется компакт-диском с полными исходными текстами, файлами рабочих областей Microsoft Visual C++, заранее откомпилированными двоичными файлами (в отладочных и окончательных версиях) и файлами в формате JPEG для глав, в которых описываются графические алгоритмы.
13,246 просмотров всего, 1 просмотров сегодня