Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

GDI



План:


Введення

GDI (Graphics Device Interface, Graphical Device Interface) - один з трьох основних компонентів або "підсистем", разом з ядром і Windows API складових користувальницький інтерфейс (віконний менеджер GDI) Microsoft Windows.

GDI - це інтерфейс Windows для представлення графічних об'єктів та передачі їх на пристрої відображення, такі як монітори і принтери.

GDI відповідає за отрисовку ліній і кривих, відображення шрифтів і обробку палітри. Він не відповідає за отрисовку вікон, меню і т. п., ця задача закріплена за користувальницької підсистемою, що розташовується в user32.dll і грунтується на GDI. GDI виконує ті ж функції, що і QuickDraw в Mac OS.

Одна з переваг використання GDI замість прямого доступу до обладнання - це уніфікація роботи з різними пристроями. Використовуючи GDI, можна одними і тими ж функціями малювати на різних пристроях, таких як екран або принтер, отримуючи на них практично однакові зображення. Ця можливість лежить в центрі всіх WYSIWYG -додатків для Windows.

Прості ігри, які не потребують швидкої графіки, можуть використовувати GDI. Однак GDI не забезпечує якісної анімації, оскільки в ньому немає можливості синхронізації з кадровим буфером. Також, в GDI немає растеризації для відтворення 3D-графіки. Сучасні ігри використовують DirectX або OpenGL, що дає програмістам доступ до більшої кількості апаратних можливостей.


1. Короткий опис

Для визначення атрибутів тексту та зображення, які виводяться на екран або принтер, використовується програмний об'єкт під назвою "контекст пристрою" (Device Context, DC). DC, як і більшість об'єктів GDI, інкапсулює подробиці реалізації та дані в собі і до них не можна отримати прямий доступ.

Для будь-якого малювання потрібен об'єкт HDC (хендл DC). При виведенні на принтер HDC виходить викликом CreateDC, і на ньому звуться спеціальні функції для переходу на нову сторінку друкованого документа. При виведенні на екран також можна використовувати CreateDC, але це призведе до малювання поверх всіх вікон поза їх межами, тому зазвичай для малювання на екрані використовуються виклики GetDC і BeginPaint, що належать вже не GDI, а USER, і повертають контекст, що посилається на регіон відсікання вікна .

Функціонал:

  • висновок одними і тими ж викликами на екран, принтер, "екран в пам'яті" (доступний додатком за вказівником і створений ним bitmap в пам'яті, також можливе виділення bitmapов в пам'яті відеокарти - CreateCompatibleBitmap - і малювання на них, такі бітові карти не доступні за вказівником , але подальша перемальовування з них на фізичний екран відбувається дуже швидко без навантаження процесора і шини, і особливо швидко в разі Remote Desktop).
  • висновок в метафайл - запам'ятовування послідовності команд малювання у файлі, можна програти заново, векторний графічний файл. wmf є саме цей метафайл з невеликим додатковим заголовком на початку.
  • висновок тексту різними шрифтами, в т. ч. TrueType і OpenType, а також шрифтами, вшитими в принтер (при зображенні документа на екрані використовується найближчий схожий програмно реалізований шрифт). Букви завжди заливаються одним кольором ("поточний колір"), проміжки між ними або залишаються прозорими, або ж заливаються іншим кольором ("поточний колір фону"). Не підтримується розташування букв по кривій.
  • багатий набір операцій з bitmapамі, включаючи масштабування, автоматичне перетворення із стандартних форматів в поточний формат екрану без зусиль з боку програміста (StretchDIBits), малювання на bitmapах декількох стандартних форматів, що знаходяться в пам'яті, і величезна кількість логічних операцій комбінування квітів 2 bitmapов - вже наявного на пристрої призначення і знову мальованої.
  • багатий набір операцій векторної графіки (приблизно той же, що в PostScript, але використовується інший вид сплайнів). Проведена лінія має атрибути - товщину, малюнок пунктиру і колір (зібрані разом в т. н. Об'єкті PEN) і спосіб згладжування кутів багатокутника. Заливка може бути одноколірної, однією з стандартних штрихувань або ж bitmapом 8 на 8 (ці атрибути зібрані в "об'єкті BRUSH"). У Windows NT також з'явилися сплайни Безьє.
  • всі кольори у викликах - завжди в RGB, незалежно від системи кольорів поточного пристрою. Виняток - окремі пікселі всередині bitmapов, які можуть бути і у вигляді, визначеному пристроєм.
  • підтримка регіонів відсікання і всіх основних логічних операцій над ними. Координати в них - 16-бітові цілі (що обмежувало розмір екрану Windows, навіть досить пізніх версій, до 32K пікселів).
  • підтримка матриці поворотів / розтягувань - World Transform, не підтримується для регіонів відсікання, тільки для векторної графіки.

2. Реалізація

У Windows 9x і більш ранніх реалізована в 16-бітної GDI.DLL, яка в свою чергу довантажує виконаний у вигляді DLL драйвер відеокарти. Драйвер відеокарти спочатку і був зобов'язаний реалізувати взагалі все малювання, в т. ч. малювання на bitmapах в пам'яті у форматі екрану. Пізніше з'явилася DIBENG.DLL, в якій було реалізовано малювання на bitmapах стандартних форматів, драйвер був зобов'язаний пропускати в неї всі виклики, крім тих, для яких він задіяв апаратний прискорювач відеокарти.

Драйвер принтера довантажувати таким же чином і мав той же інтерфейс "зверху", але "знизу" він замість малювання в пам'яті / на апаратурі генерував послідовності команд принтера і відсилав їх в об'єкт Job. Ці команди як правило були або бінарні і не читаються людиною, або PostScript.

У Windows NT GDI була повністю переписана з нуля заново, причому на Сі + + (за чутками, у Microsoft тоді не було компілятора цієї мови і вони використовували cfront). API для додатків не змінився (крім додавання кривих Безьє), для драйверів - обгортки на мові Сі навколо реалізованих на Сі + + нутрощів (зразок BRUSHOBJ_pvGetRbrush).

Сама GDI була розміщена спочатку в WINSRV.DLL в процесі CSRSS.EXE, починаючи з NT4 - в win32k.sys. Драйвери завантажувалися туди ж. DIBENG.DLL була переписана наново і перенесена туди ж як сукупність викликів EngXxx - EngTextOut та інші. Логіка взаємодії драйвера-GDI-DIBENG залишилася приблизно та ж.

GDI32.DLL в режимі користувача реалізована як набір спеціальних системних викликів, провідних в win32k.sys (до NT4 - як обгортки навколо виклику CsrClientCallServer, посилав повідомлення в CSRSS.EXE).

У Windows Vista з'явилася модель драйверів WDDM, в якій була скасована можливість використання апаратури двомірної графіки. При використанні WDDM всі GDI-додатки (тобто всі звичайні системні частини Windows UI - заголовки і рамки вікон, робочий стіл, таскбара і інше) використовують GDI-драйвер cdd.dll (Canonical Display Driver), який малює на деяких bitmapах в пам'яті, своїх для кожного вікна (вміст вікна стало запам'ятовуватися в пам'яті, до того Windows ніколи так не робила і завжди перемальовувала вікна заново, крім якихось спеціальних вікон з прапором CS_SAVEBITS). Зображення з cdd.dll витягуються процесом dwm.exe (Desktop Window Manager), який є Direct3D-додатком і отрісовиваєт "картинки вікон" на фізичному екрані через Direct3D.

Сам же WDDM-драйвер підтримує тільки DirectDraw і Direct3D і не має відношення ні до GDI, ні до win32k.sys, сопрягаясь з модулем dxgkrnl.sys в ядрі.


3. Критика

Вкрай сильно критикується підсистема друку Windows, особливо у випадку порівняння її з CUPS.

Причини: бінарний формат потоку завдання друку (у CUPS це PostScript), і реалізація обробки цього потоку у вигляді декількох DLL усередині одного процесу SPOOLSV.EXE (CUPS замість цього використовує звичайний конвеєр з декількох процесів на зразок pstoraster | rastertoepson | parallel, який можна при бажанні запустити зі звичайного UNIX shell). Таким чином, CUPS підтримує розробку фільтрів завдань друку (наприклад, для платних принтерів в готелях) навіть на скриптових мовах зразок Perl.

Однак тут мова скоріше про компоненти, що лежать нижче GDI.

Однак CUPS має серйозні проблеми з підтримкою WinPrinterов начебто всіх дешевих лазерних принтерів Hewlett-Packard. Так як вони не підтримують стандартний формат PCL, для них треба ставити величезні, складні в настройках і побудові пакети, такі як HP OfficeJet (порт "hpoj" під FreeBSD). При цьому CUPS чудово підтримує струменеві принтери, дорогі моделі лазерних принтерів Hewlett-Packard і принтери PostScript.


4. Зразкові аналоги

Нижні рівні технології X11, використовуваної в UNIX-подібних ОС, таких як Linux.

При цьому X11 біднішими можливостями, ніж GDI (наприклад, є проблеми з підтримкою незалежних від пристрою квітів), і для отримання повного аналога GDI необхідно додати ще ряд бібліотек, таких як SDL.

5. GDI +

Microsoft Windows GDI +
Компонент Microsoft Windows
Деталі
Поставляється з

Windows XP
Windows Server 2003
Windows Vista Starter

Також доступний для

Windows NT 4.0 SP6
Windows 2000
Windows 9x

Замінює

Microsoft Windows GDI

Замінений на

Desktop Window Manager

Пов'язані компоненти

Luna

З виходом Windows XP з'явився нащадок підсистеми, GDI +, заснованої на C + + [1].

GDI + є покращеною середовищем для 2D-графіки, в яку додані такі можливості, як згладжування ліній (antialiasing), використання координат з плаваючою точкою, градієнтна заливка, внутрішня підтримка таких графічних форматів, як JPEG і PNG, куди краща підтримка регіонів відсікання з можливістю використовувати в них координати з плаваючою точкою (а не 16-бітові цілі) та застосування до них World Transform, перетворення двовимірних матриць і т. п. GDI + використовує ARGB -кольору. Ці можливості використовуються в інтерфейсі Windows XP, а їх присутність в базовому графічному шарі полегшує використання систем векторної графіки, таких як Flash або SVG.

Динамічні бібліотеки GDI + можуть розповсюджуватися разом з додатками для використання в попередніх версіях Windows.

GDI + схожий з підсистемою Quartz 2D у Apple і бібліотеками з відкритим кодом libart і Cairo.

GDI + є не більш ніж набір обгорток над звичайною GDI. У Windows 7 з'явився новий API Direct2D, який є приблизно те ​​ж, але реалізований "зверху донизу" аж до драйвера відеокарти (точніше, використовує якісь можливості Direct3D в цьому драйвері), і може використовувати апаратне прискорення - тобто тривимірний відеопроцесор для малювання деяких двомірних об'єктів (antialiasing і т. д.)


5.1. Уразливості

14 вересня 2004 була виявлена ​​уразливість в GDI + та інших графічних API, пов'язана з помилкою в коді бібліотеки JPEG. Ця помилка дозволяла виконати довільний код на будь-якій системі Windows. Патч для виправлення вразливості був випущений 12 жовтня 2004 [2].

Примітки

  1. GDI + Flat API - msdn.microsoft.com/en-us/library/ms533969 (VS.85). aspx (Англ.) . MSDN Library. Microsoft. Читальний - www.webcitation.org/65sPv17Mm з першоджерела 3 березня 2012.
    Підсистема GDI + доступна як "плоский" набір з 600 функцій, реалізованих в gdiplus.dll. Ці функції "обгорнуті" в 40 класів C + +. Microsoft не планує надавати підтримку для коду, який звертається до плоского набору напряму, а не через класи і методи C + +. . NET Framework пропонує набір альтернативних C + + обгорткових класів, що входять в простір імен System.Drawing.
  2. MS04-028: Buffer overrun in JPEG processing (GDI +) could allow code execution - support.microsoft.com / default.aspx? scid = kb; en-us; 833987

Цей текст може містити помилки.

Схожі роботи | скачати
© Усі права захищені
написати до нас