 |
Введение: почему вывод через GDI остаётся важным?
Сразу же отметим: если вы не читали статью " ", то сначала ознакомьтесь с её содержанием, поскольку в первой части мы рассмотрели историю развития 2D-графики под Windows и выявили современные проблемы на high-end дискретных видеокартах.
Во второй части мы сфокусируемся на важности GDI, объясним особенности 2D-графики более глубоко, а также дадим ссылку на скачивание нашего теста 2D с русскоязычным интерфейсом (на самом деле мы дали ссылку на скачивание в нашем Клубе экспертов ещё в ветке обсуждения первой статьи, чтобы поощрить форумчан). Чтобы полностью понимать результаты этого теста, сначала нужно рассмотреть некоторые теоретические фундаментальные основы.
Почему мы тестируем GDI в эпоху Windows 7 и Direct2D?
Как думают многие наши читатели, с представлением видеокарт класса DirectX 10 и Windows Vista старые методы GDI для отрисовки 2D-графики были признаны устаревшими. Уже некоторое время для разработчиков Microsoft доступна WPF (Windows Presentation Foundation), а также и Direct2D. В любом случае, есть множество весомых причин, почему GDI (Graphics Device Interface) остаётся очень значимым и актуальным, что заставляет нас тестировать производительность GDI даже в новой среде Windows 7. Среди этих причин хотелось бы отметить следующие.
GDI продолжает поддерживать старые видеокарты, а Direct2D требует видеокарт, которые поддерживают стандарт DirectX 10 или более высокий.
GDI поддерживается во всех известных версиях Windows, а Direct2D доступен только в Windows Vista и Windows 7.
Любое графическое приложение, которое работает под Windows XP (и старыми версиями Windows), использует GDI.
Многие разработчики ПО не торопятся переносить свои программы со старых API на новые. Даже сегодня многие разработчики продолжают использовать программные библиотеки, в которых они хорошо разбираются, пусть даже доступны новые технологии. Преобразование из одной библиотеки в другую подразумевает переписывание и повторные тесты всех модулей кода. Поскольку прирост производительности в результате перехода со старых библиотек на новые может быть едва ощутим, разработчики ПО игнорируют такие изменения по чисто экономическим причинам (слишком много времени и усилий за слишком маленький результат). В качестве примера можно взять историю внедрения Direct2D в разных компонентах Mozilla Firefox, и вы получите представление о лени в индустрии по поводу данного процесса преобразования. Кроме того, для многих компаний будет просто самоубийством не поддерживать сообщество пользователей Windows XP в последних версиях программ. Всё это приводит к одному наблюдению: GDI будет с нами до тех пор, пока Windows XP не перестанет представлять большую долю в сообществе конечных пользователей.
Есть также технические причины, которые объясняют продолжающееся использование GDI. Ключевые модули кода GDI (которые содержатся и используются чаще всего в приложениях Windows) уже не такие маленькие. Direct2D также потребляет существенное количество вычислительной мощности и системных ресурсов, но не может сделать ничего, что нельзя было бы реализовать через Direct3D. И те, кто всё же решили отказаться от использования Direct3D, обычно принимают это решение довольно осторожно. Кроме того, GDI работает независимо от устройств вывода, таких как мониторы или принтеры, которые могут использоваться. Поэтому одна и та же процедура в программе может отрисовывать графику на мониторе или выводить документ на принтер, уменьшая размер кода (и соответствующие затраты на обслуживание и риск ошибок) в два раза. Многие из доступных принтеров сегодня являются устройствами GDI, и вряд ли ситуация изменится в ближайшем будущем, даже под Windows 7, где широко доступны драйверы для принтеров только для GDI.
Сами мы рассматриваем переход на WPF и Direct2D как меру, которую усиленно продвигает Microsoft, а также как необратимый шаг вперёд. Но не следует из-за эйфории новых технологий забывать о реальности жизни. Принимая во внимание Windows XP, сегодня более чем достаточно наследственных технологий. Нельзя смотреть только вперёд, игнорируя современное состояние реальности, в которой живёт большинство пользователей. В качестве примера можно привести известную нелюбовь интегрированных графических ядер 780G и 785G к Windows XP.
Мы вернёмся к , но на этот раз мы будем использовать улучшенную утилиту тестирования (читатели могут
и запустить на своих ПК). Мы увидим, что даже самые дорогие видеокарты дают низкую производительность в некоторых тестах. Впечатление такое, что причина кроется в драйверах, которые не были оптимизированы под технологию, принимаемую многими как старую.
2D GDI от Windows XP до Windows 7 в деталях XP: ясная поддержка без конкуренции До Windows XP и включая эту систему, GDI играл ключевую роль в отображении 2D-графики. Возьмём в качестве примера создание и вывод линии. Движения мыши, используемые для отрисовки линии, передавались win32k.sys, центральному компоненту для всех событий. Причём совсем неважно, использовали ли вы мышь, клавиатуру или другие устройства ввода; все данные собирались в этой процедуре для последующего распределения. Затем информацию получало наше приложение, которое превращало её в инструкции рисования GDI. Они направлялись на GDI, тоже в win32k.sys, что показано фиолетовыми стрелками на диаграмме.
Эти простые процедуры, использовавшиеся для программного вывода 2D-графики, также объясняют, почему так легко перейти с них на аппаратное ускорение - если видеокарта обладает достаточными возможностями для независимой их отрисовки. Синяя стрелка на иллюстрации выше показывает, как информация возвращается в вызывающее приложение, чтобы оно было оповещено об изменении содержимого окна (например, когда другие окна уже не закрывают видимый контент), чтобы форсировать перерисовку содержимого.
Видеокарты HD1xxx в линейке ATI Radeon и ранее выпущенные, а также в линейке nVidia GeForce 7xxx и ранее, использовали отдельный блок для ускорения 2D-графики. Он исчез с появлением видеокарт DX10, которые использовали унифицированную архитектуру шейдеров у обоих производителей.
Windows Vista: CPU вместо GPU и буферизация вместо прямой доставки Как мы уже объясняли в , Vista представляет совершенно новый способ вывода графических данных через ОС. До обращения к GDI все функции рисования выполняются так же, как и в Windows XP, то есть через win32k.sys, но работу с окнами в GDI в Vista взял на себя DWM (dynamic window manager). Кроме того, Vista использует только Direct3D для управления окнами. Каждое окно для каждого приложения записывается в текстурную память в качестве 3D-текстуры для видеокарты. Это весьма практичная эволюция для более современных видеокарт, но это также означает, что GDI уже не может считывать или записывать эти данные. В данной ситуации цепочка связи прерывается. В итоге получается двойная буферизация содержимого окна, что мы уже объясняли в
.
Что же здесь происходит? Обратите внимание на красные стрелки на диаграмме. Вместо унифицированного графического драйвера (в XP он назывался DDI Display Driver) адресуется новый CDD (Canonical Display Driver). Этот модуль в Vista независим от видеокарты. Хотя текущее содержание окна хранится в виде текстуры в видеопамяти видеокарты, каждое окно должно храниться в виде соответствующего буфера в оперативной памяти (его размер равен ширине окна умноженной на высоту окна и на четыре байта для 32-битного цвета).
Самое свежее отображение каждого окна преобразуется в битовую картинку в системной памяти, после чего оно преобразуется в 3D-текстуру в памяти видеокарты. Таким образом, DWM управляет всеми окнами и передаёт их контент через Direct3D. DWM также получает данные о том, если окно изменилось в какой-либо области, что приводит к перерисовке (синяя стрелка на иллюстрации выше). В этот момент DWM копирует содержимое системной памяти в видеопамять и отрисовывает окно с помощью Direct3D. Приложениям уже не требуется перерисовывать окна (в отличие от работы под Windows XP).
Упомянутый выше подход по своей сути отключает аппаратное ускорение 2D, приводя к серьёзному падению производительности по сравнению с Windows XP. Это также проявляет себя под Vista в виде запаздывания отрисовки 2D-графики и потребления больших объёмов памяти.
Windows 7: аппаратное ускорение в минимальных дозах Даже во время начального тестирования в мы могли видеть, что Windows 7 вновь предложила, по крайней мере, частичную поддержку аппаратного ускорения команд GDI - для видеокарт с драйверами WDDM 1.1. Если эти драйверы не доступны (например, для некоторых чипсетов с интегрированной графикой Intel), то Windows 7 работает более или менее похоже на Vista. Что это значит для нас, если быть более конкретным? Давайте посмотрим на диаграмму работы 2D-графики под Windows 7.
На первый взгляд, всё выглядит так же, как и под Vista. Однако мы уже видим, что теперь не нужно дважды буферизировать содержимое каждого окна. Вместо системной памяти здесь работает так называемая апертурная память (aperture memory). Под этим термином понимается специфическая область в обычной оперативной памяти, к которой видеокарта может обращаться напрямую. Если содержимое окна будет изменяться из-за перемещения или наложения, это содержимое будет копироваться напрямую из данной памяти в видеопамять на видеокарте.
По сравнению с Windows XP, только подмножество команд GDI поддерживается GPU - а именно ClearType, ColorFill, BitBlt, AlphaBlend, TransparentBlt и StretchBlt. Если вы не знакомы с этими командами, то они выполняют следующее: прямой вывод текста, заполнение поверхности простыми цветами, копирование содержимого окна и прозрачное наложение. Хотя рендеринг сложных геометрических фигур не поддерживается вообще, копии содержимого окна и заполняемые области могут легко передаваться из апертурной памяти напрямую в память видеокарты.
Итог Windows 7 снизила использование памяти, устранив большую часть двойной буферизации содержимого окон. Впрочем, даже Vista выиграла от подобных эффектов благодаря переходу на более новую модель драйверов WDDM. Именно поэтому аппаратное ускорение вновь стало возможным благодаря новому обновлению платформы (которое произошло вместе с внедрением DirectX 11), схожим с Windows 7. Но за это пришлось расплачиваться сложностью и возможными проблемами с драйверами. Но всё это мы детально рассмотрим дальше в нашей статье.
Вывод 2D-графики с помощью GDI: прямой или буферизованный?
На самом деле не так и важно, как XP, Vista или Windows 7 взаимодействуют с GDI; с точки зрения программиста принципы написания кода остались прежними. Чем отличаются эти реализации, мы показали в предыдущей части статьи, особенно со стороны видеокарты. Здесь же мы рассмотрим, как всё это работает под разными ОС.
Команды рисования Неважно, что мы будем говорить о 2D-выходе со стороны GDI, всё построено на хорошо знакомом наборе стандартизированных инструкций рисования. Поскольку детальное описание этих инструкций выходит за рамки статьи, здесь мы скажем только следующее: каждый из графических примитивов, включая линии, кривые, полигоны, прямоугольники и эллипсы, имеет собственную чётко определённую команду, включая свойства, такие как заполнение, ширина линии, цвет и так далее. Эти команды вместе с любыми параметрами, которые они могут использовать, передаются на GDI. Всё что происходит дальше уже не подконтрольно приложению.
Прямое или буферизованное рисование: слон или муравьи В принципе, не так и важно, что использовать: взять миллион муравьёв и перенести песчинки на 100 метров от точки A до точки B, или заполнить большой контейнер песка, загрузить его на слона и перенести за один раз. Оба варианта достигают поставленной цели.
В любом случае, давайте рассмотрим разницу между двумя этими подходами: всё же слон подразумевает намного меньше трафика между двумя конечными пунктами. На координацию усилий миллиона муравьёв требуется больше времени и сил, чем загрузка и транспортировка одного контей
|
|
