Компонент ядра gdi операционной системы класса windows 9x предназначен

From Wikipedia, the free encyclopedia

The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers. Windows apps use Windows API to interact with GDI, for such tasks as drawing lines and curves, rendering fonts, and handling palettes. The Windows USER subsystem uses GDI to render such UI elements as window frames and menus. Other systems have components that are similar to GDI; for example: macOS has Quartz, and Linux has X Window System and Wayland (display server protocol).

GDI’s most significant advantages over more direct methods of accessing the hardware are perhaps its scaling capabilities and its abstract representation of target devices. Using GDI, it is possible to draw on multiple devices, such as a screen and a printer, and expect proper reproduction in each case. This capability is at the center of most «What You See Is What You Get» applications for Microsoft Windows.

Simple games that do not require fast graphics rendering may use GDI. However, GDI is relatively hard to use for advanced animation, lacks a notion for synchronizing with individual video frames in the video card, and lacks hardware rasterization for 3D. Modern games usually use DirectX, Vulkan, or OpenGL instead.

Technical details[edit]

In GDI, a device context (DC) defines the attributes of text and images for the output device, e.g., screen or printer. GDI maintains the actual context. Generating the output requires a handle to the device context (HDC). After generating the output, the handle could be released.

GDI uses Bresenham’s line drawing algorithm to draw aliased lines.^[1]

Version history[edit]

Early versions[edit]

GDI was present in the initial release of Windows. MS-DOS programs had hitherto manipulated the graphics hardware using software interrupts (sometimes via the Video BIOS) and by manipulating video memory directly. Code written in this way expects that it is the only user of the video memory, which was not tenable on multi-tasked environment, such as Windows. The BYTE magazine, in December 1983, discussed Microsoft’s plans for a system to output graphics to both printers and monitors with the same code in the forthcoming first release of Windows.^[2]

Windows XP[edit]

With the introduction of Windows XP, GDI+ complemented GDI. GDI+ has been written in C++. It adds anti-aliased 2D graphics, floating point coordinates, gradient shading, more complex path management, intrinsic support for modern graphics-file formats like JPEG and PNG, and support for composition of affine transformations in the 2D view pipeline. GDI+ uses RGBA values to represent color. Use of these features is apparent in Windows XP components, such as Microsoft Paint, Windows Picture and Fax Viewer, Photo Printing Wizard, and the My Pictures Slideshow screensaver. Their presence in the basic graphics layer greatly simplifies implementations of vector-graphics systems such as Adobe Flash or SVG. Besides, .NET Framework provides a managed interface for GDI+ via the System.Drawing namespace.

While GDI+ is included with Windows XP and later, the GDI+ dynamic library can also be shipped with an application and used on older versions of Windows.^[3]

Because of the additional text processing and resolution independence capabilities in GDI+, the CPU undertakes text rendering.^[4] The result is an order of magnitude slower than the hardware-accelerated GDI.^[5] Chris Jackson published some tests indicating that a piece of text rendering code he had written could render 99,000 glyphs per second in GDI, but the same code using GDI+ rendered 16,600 glyphs per second.

GDI+ is similar (in purpose and structure) to Apple‘s QuickDraw GX subsystem, and the open-source libart and Cairo libraries.

Windows Vista[edit]

In Windows Vista, all Windows applications including GDI and GDI+ applications run in the new compositing engine, Desktop Window Manager (DWM), which is hardware-accelerated. As such, the GDI itself is no longer hardware-accelerated.^[6][7][8] Because of the nature of the composition operations, window moves can be faster or more responsive because underlying content does not need to be re-rendered by the application.^[7]

Windows 7[edit]

Windows 7 includes GDI hardware acceleration for blitting operations in the Windows Display Driver Model v1.1. This improves GDI performance and allows DWM to use local video memory for compositing, thereby reducing system memory footprint and increasing the performance of graphics operations. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. GDI+ continues to rely on software rendering in Windows 7.^[9]

GDI printers[edit]

A GDI printer or Winprinter (analogous to a Winmodem) is a printer designed to accept output from a host computer running Windows. The host computer does all print processing: GDI renders a page as a bitmap, which the printer driver receives, processes, and sends to the associated printer.^[10][11] The combination of GDI and the driver is bidirectional; they receive information from the printer such as whether it is ready to print or is out of paper.

Printers that do not rely on GDI require hardware, firmware, and memory for page rendering while a GDI printer uses the host computer for this. However, a printer with its own control language can accept input from any device with a suitable driver, while a GDI printer requires a PC running Windows. GDI printers can be made available to computers on a network if they are connected as shared printers on a computer which is on and running Windows. Some «generic» GDI drivers such as pnm2ppa have been written; they aim to make GDI printers compatible with non-Windows operating systems such as FreeBSD, but they cannot support all printers.^[10]

In order to allow simpler creation of drivers for Winprinters, the Microsoft Universal Printer Driver was created. This allows printer vendors to write Generic Printer Description (GPD) «minidrivers», which describe the printer’s capabilities and command set in plaintext, rather than having to do kernel mode driver development.

Microsoft has moved away from this printing model with Open XML Paper Specification.

Limitations[edit]

Each window consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation.^[12] Many applications are also incorrectly coded and fail to release GDI objects after use, which further adds to the problem.^[13] The total available GDI objects varies from one version of Windows to the next: Windows 9x had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP and later have a configurable limit (via the registry) that defaults to 10,000 objects per process (but a theoretical maximum of 65,536 for the entire session).^[14][15] Windows 8 and later increase the GDI object limit to 65,536 per user logon session.

Earlier versions of Windows such as Windows 3.1 and Windows 98 included a Resource Meter program to allow the user to monitor how much of the total system GDI resources were in use. This resource meter consumed GDI objects itself. Later versions such as Windows 2000 and Windows XP can report GDI object usage for each program in the Task Manager, but they cannot tell the user the total GDI capacity available.

Overflowing GDI capacity can affect Windows itself, preventing new windows from opening, menus from displaying, and alert boxes from appearing. The situation can be difficult to clear and can potentially require a forced reset of the system, since it prevents core system programs from functioning. In Windows 8 and 8.1, a forced log-off occurs as a result of GDI capacity overflow, instead of a reboot.

Successor[edit]

Direct2D is the successor of GDI and GDI+. Its sibling, DirectWrite, replaces Uniscribe. They were shipped with Windows 7 and Windows Server 2008 R2, and were available for Windows Vista and Windows Server 2008 (with Platform Update installed). Later, Microsoft developed Win2D, a free and open-source GDI-like class library. Win2D’s target audience are developers that use C++, C#, and Visual Basic.NET to develop Universal Windows Platform apps.^[16]

See also[edit]

• WinG
• Microsoft Windows library files

Notes and references[edit]

External links[edit]

• Microsoft’s GDI+ page
• Bob Powell’s GDI+ FAQ list
• MSDN article on GDI overview
• Microsoft Security Bulletin MS04-028
• F-Secure: Critical vulnerability in MS Windows may escalate the virus threat
• IGDI+ — Delphi Open Source GDI+ library.

From Wikipedia, the free encyclopedia

The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers. Windows apps use Windows API to interact with GDI, for such tasks as drawing lines and curves, rendering fonts, and handling palettes. The Windows USER subsystem uses GDI to render such UI elements as window frames and menus. Other systems have components that are similar to GDI; for example: macOS has Quartz, and Linux has X Window System and Wayland (display server protocol).

GDI’s most significant advantages over more direct methods of accessing the hardware are perhaps its scaling capabilities and its abstract representation of target devices. Using GDI, it is possible to draw on multiple devices, such as a screen and a printer, and expect proper reproduction in each case. This capability is at the center of most «What You See Is What You Get» applications for Microsoft Windows.

Simple games that do not require fast graphics rendering may use GDI. However, GDI is relatively hard to use for advanced animation, lacks a notion for synchronizing with individual video frames in the video card, and lacks hardware rasterization for 3D. Modern games usually use DirectX, Vulkan, or OpenGL instead.

Technical details[edit]

In GDI, a device context (DC) defines the attributes of text and images for the output device, e.g., screen or printer. GDI maintains the actual context. Generating the output requires a handle to the device context (HDC). After generating the output, the handle could be released.

GDI uses Bresenham’s line drawing algorithm to draw aliased lines.^[1]

Version history[edit]

Early versions[edit]

GDI was present in the initial release of Windows. MS-DOS programs had hitherto manipulated the graphics hardware using software interrupts (sometimes via the Video BIOS) and by manipulating video memory directly. Code written in this way expects that it is the only user of the video memory, which was not tenable on multi-tasked environment, such as Windows. The BYTE magazine, in December 1983, discussed Microsoft’s plans for a system to output graphics to both printers and monitors with the same code in the forthcoming first release of Windows.^[2]

Windows XP[edit]

With the introduction of Windows XP, GDI+ complemented GDI. GDI+ has been written in C++. It adds anti-aliased 2D graphics, floating point coordinates, gradient shading, more complex path management, intrinsic support for modern graphics-file formats like JPEG and PNG, and support for composition of affine transformations in the 2D view pipeline. GDI+ uses RGBA values to represent color. Use of these features is apparent in Windows XP components, such as Microsoft Paint, Windows Picture and Fax Viewer, Photo Printing Wizard, and the My Pictures Slideshow screensaver. Their presence in the basic graphics layer greatly simplifies implementations of vector-graphics systems such as Adobe Flash or SVG. Besides, .NET Framework provides a managed interface for GDI+ via the System.Drawing namespace.

While GDI+ is included with Windows XP and later, the GDI+ dynamic library can also be shipped with an application and used on older versions of Windows.^[3]

Because of the additional text processing and resolution independence capabilities in GDI+, the CPU undertakes text rendering.^[4] The result is an order of magnitude slower than the hardware-accelerated GDI.^[5] Chris Jackson published some tests indicating that a piece of text rendering code he had written could render 99,000 glyphs per second in GDI, but the same code using GDI+ rendered 16,600 glyphs per second.

GDI+ is similar (in purpose and structure) to Apple‘s QuickDraw GX subsystem, and the open-source libart and Cairo libraries.

Windows Vista[edit]

In Windows Vista, all Windows applications including GDI and GDI+ applications run in the new compositing engine, Desktop Window Manager (DWM), which is hardware-accelerated. As such, the GDI itself is no longer hardware-accelerated.^[6][7][8] Because of the nature of the composition operations, window moves can be faster or more responsive because underlying content does not need to be re-rendered by the application.^[7]

Windows 7[edit]

Windows 7 includes GDI hardware acceleration for blitting operations in the Windows Display Driver Model v1.1. This improves GDI performance and allows DWM to use local video memory for compositing, thereby reducing system memory footprint and increasing the performance of graphics operations. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. GDI+ continues to rely on software rendering in Windows 7.^[9]

GDI printers[edit]

A GDI printer or Winprinter (analogous to a Winmodem) is a printer designed to accept output from a host computer running Windows. The host computer does all print processing: GDI renders a page as a bitmap, which the printer driver receives, processes, and sends to the associated printer.^[10][11] The combination of GDI and the driver is bidirectional; they receive information from the printer such as whether it is ready to print or is out of paper.

Printers that do not rely on GDI require hardware, firmware, and memory for page rendering while a GDI printer uses the host computer for this. However, a printer with its own control language can accept input from any device with a suitable driver, while a GDI printer requires a PC running Windows. GDI printers can be made available to computers on a network if they are connected as shared printers on a computer which is on and running Windows. Some «generic» GDI drivers such as pnm2ppa have been written; they aim to make GDI printers compatible with non-Windows operating systems such as FreeBSD, but they cannot support all printers.^[10]

In order to allow simpler creation of drivers for Winprinters, the Microsoft Universal Printer Driver was created. This allows printer vendors to write Generic Printer Description (GPD) «minidrivers», which describe the printer’s capabilities and command set in plaintext, rather than having to do kernel mode driver development.

Microsoft has moved away from this printing model with Open XML Paper Specification.

Limitations[edit]

Each window consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation.^[12] Many applications are also incorrectly coded and fail to release GDI objects after use, which further adds to the problem.^[13] The total available GDI objects varies from one version of Windows to the next: Windows 9x had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP and later have a configurable limit (via the registry) that defaults to 10,000 objects per process (but a theoretical maximum of 65,536 for the entire session).^[14][15] Windows 8 and later increase the GDI object limit to 65,536 per user logon session.

Earlier versions of Windows such as Windows 3.1 and Windows 98 included a Resource Meter program to allow the user to monitor how much of the total system GDI resources were in use. This resource meter consumed GDI objects itself. Later versions such as Windows 2000 and Windows XP can report GDI object usage for each program in the Task Manager, but they cannot tell the user the total GDI capacity available.

Overflowing GDI capacity can affect Windows itself, preventing new windows from opening, menus from displaying, and alert boxes from appearing. The situation can be difficult to clear and can potentially require a forced reset of the system, since it prevents core system programs from functioning. In Windows 8 and 8.1, a forced log-off occurs as a result of GDI capacity overflow, instead of a reboot.

Successor[edit]

Direct2D is the successor of GDI and GDI+. Its sibling, DirectWrite, replaces Uniscribe. They were shipped with Windows 7 and Windows Server 2008 R2, and were available for Windows Vista and Windows Server 2008 (with Platform Update installed). Later, Microsoft developed Win2D, a free and open-source GDI-like class library. Win2D’s target audience are developers that use C++, C#, and Visual Basic.NET to develop Universal Windows Platform apps.^[16]

See also[edit]

• WinG
• Microsoft Windows library files

Notes and references[edit]

External links[edit]

• Microsoft’s GDI+ page
• Bob Powell’s GDI+ FAQ list
• MSDN article on GDI overview
• Microsoft Security Bulletin MS04-028
• F-Secure: Critical vulnerability in MS Windows may escalate the virus threat
• IGDI+ — Delphi Open Source GDI+ library.

{{{Название}}} это компонент Windows. Дата появления — {{{Дата появления}}} Дата удаления = {{{Дата удаления}}}

—>

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, что даёт программистам доступ к большему количеству аппаратных возможностей.

Краткое описание[]

Для определения атрибутов текста и изображения, которые выводятся на экран или принтер, используется программный объект под названием «контекст устройства» (Device Context, DC). DC, как и большинство объектов GDI, инкапсулирует подробности реализации и данные в себе и к ним нельзя получить прямой доступ.

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

Функциональность:

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

Реализация[]

В Windows 9x и более ранних реализована в 16-битной GDI.DLL, которая, в свою очередь, подгружает выполненный в виде DLL драйвер видеокарты. Драйвер видеокарты первоначально и был обязан реализовать вообще все рисование, в том числе рисование через битмапы в памяти в формате экрана. Позже появилась DIBENG.DLL, в которой было реализовано рисование на битмапах типичных форматов, драйвер был обязан пропускать в неё все вызовы, кроме тех, для которых он задействовал аппаратный ускоритель видеокарты.

Драйвер принтера подгружался таким же образом и имел тот же интерфейс «сверху», но «снизу» он вместо рисования в памяти/на аппаратуре генерировал последовательности команд принтера и отсылал их в объект 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),^[1] который рисует на некоторых битмапах в памяти, своих для каждого окна (содержимое окна стало запоминаться в памяти, до того Windows никогда так не делала и всегда перерисовывала окна заново, кроме неких специальных окон с флагом CS_SAVEBITS). Изображения из cdd.dll извлекаются процессом dwm.exe (Desktop Window Manager), который является Direct3D-приложением и отрисовывает «картинки окон» на физическом экране через Direct3D.

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

Критика[]

Крайне сильно критикуется подсистема печати 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.

Примерные аналоги[]

Нижние уровни технологии X11, используемой в UNIX-подобных ОС, таких, как Linux.

При этом X11 беднее возможностями, чем GDI (например, есть проблемы с реализацией независимых от устройства цветов), и для получения полного аналога GDI необходимо добавить ещё ряд библиотек, таких, как SDL.

{{{Название}}} это компонент Windows. Дата появления — {{{Дата появления}}} Дата удаления = {{{Дата удаления}}}

С выходом Windows XP появился потомок подсистемы, GDI+, основанной на C++^[2] Подсистема GDI+ доступна как «плоский» набор из 600 функций, реализованных в gdiplus.dll. Эти функции «обёрнуты» в 40 классов C++. Microsoft не планирует оказывать поддержку для кода, который обращается к плоскому набору напрямую, а не через классы и методы C++. .NET Framework предлагает набор альтернативных C++ обёрточных классов, входящих в пространство имен System.Drawing..

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 и т. д.)

Уязвимости[]

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

Примечания[]

Ссылки[]

• Microsoft’s GDI+ page
• Bob Powell’s GDI+ FAQ list
• MSDN article on GDI overview
• Microsoft Security Bulletin MS04-028
• F-Secure: Critical vulnerability in MS Windows may escalate the virus threat

Шаблон:Windows API

Компоненты Microsoft Windows
Основные	Aero • ClearType • Диспетчер рабочего стола • DirectX • Панель задач (Пуск • Область уведомлений) • Проводник (Пространство имён • Специальные папки • Ассоциации файлов) • Windows Search (Smart folders • iFilters) • GDI • WIM • SMB • .NET Framework • XPS • Active Scripting (WSH • VBScript • JScript) • COM (OLE • DCOM • ActiveX • Структурированное хранилище • Сервер транзакций) • Теневая копия • WDDM • UAA • Консоль Win32
Службы управления	Архивация и восстановление • COMMAND.COM • cmd.exe • Средство переноса данных • Просмотр событий • Установщик • netsh.exe • PowerShell • Отчёты о проблемах • rundll32.exe • Программа подготовки системы (Sysprep) • Настройка системы (MSConfig) • Проверка системных файлов • Индекс производительности • Центр обновления • Восстановление системы • Дефрагментация диска • Диспетчер задач • Диспетчер устройств • Консоль управления • Очистка диска • Панель управления (элементы)
Приложения	Контакты • DVD Maker • Факсы и сканирование • Internet Explorer • Журнал • Экранная лупа • Media Center • Проигрыватель Windows Media • Программа совместной работы • Центр устройств Windows Mobile • Центр мобильности • Экранный диктор • Paint • Редактор личных символов • Удалённый помощник • Распознавание речи • WordPad • Блокнот • Боковая панель • Звукозапись • Календарь • Калькулятор • Ножницы • Почта • Таблица символов • Исторические: Movie Maker • NetMeeting • Outlook Express • Диспетчер программ • Диспетчер файлов • Фотоальбом • Windows To Go
Игры	Chess Titans • Mahjong Titans • Purble Place • Пасьянсы (Косынка • Паук • Солитер) • Сапёр • Пинбол • Червы
Ядро ОС	Ntoskrnl.exe • Слой аппаратных абстракций (hal.dll) • Бездействие системы • svchost.exe • Реестр • Службы • Диспетчер управления сервисами • DLL (формат модулей) • PE • NTLDR • Диспетчер загрузки • Программа входа в систему (winlogon.exe) • Консоль восстановления • Windows RE • Windows PE • Защита ядра от изменений
Службы	Autorun.inf • Фоновая интеллектуальная служба передачи • Файловая система стандартного журналирования • Отчёты об ошибках • Планировщик классов мультимедиа • Теневая копия • Планировщик задач • Беспроводная настройка
Файловые системы	ReFS • NTFS (Жёсткая ссылка • Точка соединения • Точка монтирования • Точка повторной обработки • Символьная ссылка • TxF • EFS) • WinFS • FAT • exFAT • CDFS • UDF • DFS • IFS
Сервер	Active Directory • Службы развёртывания • Служба репликации файлов • DNS • Домены • Перенаправление папок • Hyper-V • IIS • Media Services • MSMQ • Защита доступа к сети (NAP) • Службы печати для UNIX • Удалённое разностное сжатие • Службы удаленной установки • Служба управления правами • Перемещаемые профили пользователей • SharePoint • Диспетчер системных ресурсов • Удаленный рабочий стол • WSUS • Групповая политика • Координатор распределённых транзакций
Архитектура	NT • Диспетчер объектов • Пакеты запроса ввода/вывода • Диспетчер транзакций ядра • Диспетчер логических дисков • Диспетчер учетных записей безопасности • Защита ресурсов • lsass.exe • csrss.exe • smss.exe • spoolsv.exe • Запуск
Безопасность	BitLocker • Защитник • Предотвращение выполнения данных • Обязательный контроль целостности • Защищённый канал данных • UAC • UIPI • Брандмауэр • Центр обеспечения безопасности • Защита файлов
Совместимость	Подсистема UNIX (Interix) • Виртуальная машина DOS • Windows on Windows • WOW64

Шаблон:Microsoft APIs

Что за программа gdi windows

Windows GDI+ — это API на основе классов для программистов C/C++. Она позволяет приложениям использовать графику и форматированный текст как на дисплее, так и на принтере. Приложения на основе API-интерфейса Microsoft Win32 не обращаются к графическому оборудованию напрямую. Вместо этого GDI+ взаимодействует с драйверами устройств от имени приложений. GDI+ также поддерживается Microsoft Win64.

Где применимо

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

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

Аудитория разработчиков

Интерфейс на основе классов GDI+ c++ предназначен для использования программистами C/C++. знание Windows графического пользовательского интерфейса и архитектуры, управляемой сообщениями, является обязательным.

Требования к среде выполнения

GDI+ можно использовать во всех приложениях на основе Windows. GDI+ было введено в Windows XP и Windows Server 2003. Сведения о том, какие операционные системы требуются для использования определенного класса или метода, см. в разделе «Дополнительные сведения» документации по классу или методу.

Источник

Поиск утечки GDI объектов: Как загнать мастодонта

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

В 2016 году, когда большинство программ выполняются в песочницах, из которых даже самый некомпетентный разработчик не сможет навредить системе, странно сталкиваться с проблемой, о которой дальше пойдет речь. Если честно, я надеялся, что она ушла в далекое прошлое вместе с Win32Api, но недавно я с ней столкнулся. До этого я лишь слышал жуткие байки старых более опытных разработчиков, что такое может быть.

Проблема

Утечка или использование слишком большого числа GDI объектов.

Симптомы:

Message: A generic error occurred in GDI+.
Source: System.Drawing
TargetSite: IntPtr GetHbitmap(System.Drawing.Color)
Type: System.Runtime.InteropServices.ExternalException

Почему?

В системах семейства Windows может быть одновременно создано не более 65535 объектов GDI. Число, на самом деле, невероятно большое и ни при каком нормальном сценарии и близко не должно достигаться. На процесс установлено ограничение в 10000, которое хоть и можно изменить (в реестре изменить значение HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsGDIProcessHandleQuota в пределах от 256 до 65535), но Microsoft настоятельно не рекомендует увеличивать это ограничение. Если это сделать, то у одного процесса будет возможность положить систему настолько, что та даже не сможет нарисовать сообщение об ошибке. В этом случае система сможет ожить только после перезагрузки.

Как исправлять?

Если Вы живете в аккуратном управляемом CLR’ом мире, то вероятность 9 из 10, что у Вас в приложении обычная утечка памяти. Проблема хоть и неприятная, зато довольно обыденная и есть по меньшей мере дюжина отличных инструментов для ее поиска. Подробно останавливаться на этом не буду. Вам лишь будет нужно использовать любой профилировщик, чтобы посмотреть, не увеличивается ли число объектов-оберток над GDI ресурсами, это: Brush, Bitmap, Pen, Region, Graphics. Если это действительно так, то Вам повезло, можете закрывать вкладку со статьей.

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

Что Вам будут советовать другие?

Официальное руководство от Microsoft или другие статьи по этому поводу, которые Вы найдете в интернете, будут советовать примерно следующее:

Найти все Create%SOME_GDI_OBJECT% и узнать, есть ли соответствующий ему DeleteObject(или ReleaseDC для HDC-объектов), а если и есть, то, возможно, существует сценарий, при котором он не вызовется.

Есть еще чуть улучшенная версия этого метода, она содержит дополнительный первый шаг:

Скачать утилиту GDIView. Она умеет показывать конкретное количество GDI объектов по типу и единственное, что настораживает, так это то, что сумма всех не соответствует значению в последней колонке. На это можно попробовать не обращать внимание, если она поможет хоть как-то сузить зону поиска.

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

Что предложу я?

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

После чего запустил процесс на отладку в Visual Studio, а здесь выбрал его в дереве процессов. Первая точка останова сработала мгновенно:

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

Задача: Найти те вызовы функций GDI, которым не соответствует удаление. В логи присутствует все необходимое: список вызовов функций в хронологическом порядке, их возвращаемые значения и параметры. Получается, что мне нужно взять возвращаемое значение функции Create%SOME_GDI_OBJECT% и найти вызов DeleteObject с этим значением в качестве аргумента. Я выделил все записи в Api Monitor, вставил в текстовый файл и получил что-то вроде CSV с разделителем TAB. Запустил VS, где думал написать программу, чтобы попарсить это, но, прежде чем она загрузилась, мне пришла в голову идея получше: экспортировать данные в базу и написать запрос, чтобы выгрести то, что меня интересует. Это был правильный выбор, потому что позволил очень быстро задавать вопросы и получать на них ответы.

Есть множество инструментов, чтобы импортировать данные из CSV в базу, потому не буду на этом останавливаться (mysql, mssql, sqlite).

У меня получилась вот такая таблица:

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

И наконец запрос, который найдет все текущие объекты:

(Строго говоря, он просто найдет все вызовы Delete на все вызовы Create)

На рисунке сразу видны вызовы, на которые так и не нашлось ни одного Delete.

Остался последний вопрос: Как найти откуда вызываются эти методы в контексте моего кода? И здесь мне помог один хитрый трюк:

Резюме:

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

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

Источник

GLGDI+ или «переходим с GDI+ на OpenTK»

Почему выбор пал именно на OpenTK? Во-первых, OpenTK предоставляет класс GLControl (является прямым наследником UserControl), который позволяет упростить переход на данную библиотеку. Во-вторых, в комплекте идет класс TextPrinter, который позволяет довольно просто выводить текст на экран. В-третьих во время гугления я нашел небольшой архив «Engine.zip» с набором классов для 2D-отрисовки, инициализации OpenGL и прочими приятностями.

Некоторые моменты

Заключение

Библиотека лежит на GoogleCode, под BSD лицензией. Если кому понадобится — пользуйтесь на здоровье. Чтобы понять как работать с библиотекой — посмотрите исходный текст сэмпла, который идет в комплекте, он очень простой:

Все описанные выше «моменты» в нем учтены.
Данную библиотеку я пока не рекомендовал бы использовать для продуктов, нацеленных на массового пользователя — она слишком молода для этого, но в утилитах вполне пригодна к использованию.
На данный момент планов по развитию библиотеки у меня нет — мне ее функционала хватает. Но багфиксы и патчи приветствуются 🙂

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

Вот теперь редактор карт работает значительно быстрее и ничего не тормозит, чего и вам желаю!

UPD: забыл указать ссылку на сайт OpenTK
UPD2: исправил баг с путями в исходниках сэмпла (как в архиве, так и в SVN)

Источник

Что за программа gdi windows

GDI (Graphics Device Interface, Graphical Device Interface) — один из трёх основных компонентов или «подсистем», вместе с ядром и Windows API, составляющих пользовательский интерфейс (оконный менеджер GDI) Microsoft Windows.

GDI — это интерфейс Windows для представления графических объектов и передачи их на устройства отображения, такие, как мониторы и принтеры.

Содержание

Краткое описание [ ]

Для определения атрибутов текста и изображения, которые выводятся на экран или принтер, используется программный объект под названием « контекст устройства » (Device Context, DC). DC, как и большинство объектов GDI, инкапсулирует подробности реализации и данные в себе и к ним нельзя получить прямой доступ.

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

Реализация [ ]

В Windows 9x и более ранних реализована в 16-битной GDI.DLL, которая, в свою очередь, подгружает выполненный в виде DLL драйвер видеокарты. Драйвер видеокарты первоначально и был обязан реализовать вообще все рисование, в том числе рисование через битмапы в памяти в формате экрана. Позже появилась DIBENG.DLL, в которой было реализовано рисование на битмапах типичных форматов, драйвер был обязан пропускать в неё все вызовы, кроме тех, для которых он задействовал аппаратный ускоритель видеокарты.

Драйвер принтера подгружался таким же образом и имел тот же интерфейс «сверху», но «снизу» он вместо рисования в памяти/на аппаратуре генерировал последовательности команд принтера и отсылал их в объект 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).

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

Критика [ ]

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

Однако CUPS имеет серьёзные проблемы с поддержкой WinPrinterов вроде всех дешевых лазерных принтеров Hewlett-Packard. Так как они не поддерживают распространенный формат PCL, для них надо ставить огромные, сложные в настройках и построении пакеты, такие, как HP OfficeJet (порт «hpoj» во FreeBSD). При этом CUPS прекрасно поддерживает струйные принтеры, дорогие модели лазерных принтеров Hewlett-Packard и принтеры PostScript.

Примерные аналоги [ ]

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

Уязвимости [ ]

Примечания [ ]

Ссылки [ ]

Контакты • DVD Maker • Факсы и сканирование • Internet Explorer • Журнал • Экранная лупа • Media Center • Проигрыватель Windows Media • Программа совместной работы • Центр устройств Windows Mobile • Центр мобильности • Экранный диктор • Paint • Редактор личных символов • Удалённый помощник • Распознавание речи • WordPad • Блокнот • Боковая панель • Звукозапись • Календарь • Калькулятор • Ножницы • Почта • Таблица символов • Исторические: Movie Maker • NetMeeting • Outlook Express • Диспетчер программ • Диспетчер файлов • Фотоальбом • Windows To Go

Ntoskrnl.exe • Слой аппаратных абстракций (hal.dll) • Бездействие системы • svchost.exe • Реестр • Службы • Диспетчер управления сервисами • DLL ( формат модулей ) • PE • NTLDR • Диспетчер загрузки • Программа входа в систему (winlogon.exe) • Консоль восстановления • Windows RE • Windows PE • Защита ядра от изменений

Autorun.inf • Фоновая интеллектуальная служба передачи • Файловая система стандартного журналирования • Отчёты об ошибках • Планировщик классов мультимедиа • Теневая копия • Планировщик задач • Беспроводная настройка

Active Directory • Службы развёртывания • Служба репликации файлов • DNS • Домены • Перенаправление папок • Hyper-V • IIS • Media Services • MSMQ • Защита доступа к сети (NAP) • Службы печати для UNIX • Удалённое разностное сжатие • Службы удаленной установки • Служба управления правами • Перемещаемые профили пользователей • SharePoint • Диспетчер системных ресурсов • Удаленный рабочий стол • WSUS • Групповая политика • Координатор распределённых транзакций

NT • Диспетчер объектов • Пакеты запроса ввода/вывода • Диспетчер транзакций ядра • Диспетчер логических дисков • Диспетчер учетных записей безопасности • Защита ресурсов • lsass.exe • csrss.exe • smss.exe • spoolsv.exe • Запуск

BitLocker • Защитник • Предотвращение выполнения данных • Обязательный контроль целостности • Защищённый канал данных • UAC • UIPI • Брандмауэр • Центр обеспечения безопасности • Защита файлов

Источник

Взаимодействия между GDI и GDI+

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

Оригинальная версия продукта: Windows Интерфейс графического устройства
Исходный номер КБ: 311221

Сводка

Некоторые правила применяются при смешивании GDI и GDI+ кода. Например, не следует вовлекать вызовы GDI и GDI+ одного целевого объекта. Можно обернуть объект Graphics вокруг HDC, но вы не должны получать доступ к HDC непосредственно из GDI до тех пор, пока объект Graphics не будет уничтожен.

Четыре основных сценария взаимодействия между GDI и GDI+ в этой статье:

Использование GDI на объекте GDI+ Graphics, при помощи экрана

Одним из примеров необходимости использования GDI на объекте GDI+ Graphics, опираемом на экран, является нарисовка резинки или прямоугольника фокуса. GDI+ в настоящее время не имеет прямой поддержки raster operations (ROP), поэтому GDI необходимо использовать непосредственно, R2_XOR необходимые операции пера. В этом случае вы можете получить HDC, на который будет направлен Graphics::GetHDC() вывод GDI. GDI+ не следует пытаться использовать объект Graphics для жизни HDC (т. е. пока Graphics::ReleaseHDC() не называется).

Использование GDI на объекте GDI+ Graphics с помощью bitmap

Когда вызван объект Graphics, который имеет не экран, а битовую карту, создается HDC памяти и создается и выбирается новый объект в Graphics::GetHDC() HBITMAP HDC памяти. Эта новая битовая карта памяти не инициализирована с изображением исходной битма, а скорее с шаблоном sentinel, который позволяет GDI+ отслеживать изменения в bitmap. Любые изменения, внесенные в битовую карту памяти с помощью кода GDI, становятся очевидными в изменениях в шаблоне sentinel. Когда Graphics::ReleaseHDC() называется, эти изменения копируется обратно в исходную bitmap. Так как битовая карта памяти не инициализирована с изображением bitmap, получаемый таким образом HDC должен считаться только пишите и поэтому не подходит для использования с roPs, использование которого требует возможности чтения цели, например R2_XOR. Кроме того, для этого подхода существует затрата на производительность, так как GDI+ необходимо скопировать изменения обратно в исходную bitmap.

Использование GDI+ на GDI HDC

Вы можете упростить использование GDI+ hdC с помощью конструктора Graphics, который принимает HDC в качестве параметра. Участники рисования класса Graphics можно использовать для рисования на HDC таким образом. После прикрепления объекта Graphics к HDC операции GDI не должны выполняться в HDC до тех пор, пока объект Graphics не будет уничтожен или не выходит из сферы действия. Если для hdC требуется вывод GDI, либо уничтожайте объект Graphics перед использованием исходного HDC, либо используйте для получения нового HDC, а затем следуйте правилам, описанным ранее в этой статье, для обеспечения связи при использовании GDI на объекте Graphics::GetHDC() GDI+.

Использование GDI+ на HBITMAP памяти GDI

Конструктор GDI+ Bitmap, который принимает параметр в качестве параметра, не использует фактический источник в качестве заднего изображения HBITMAP HBITMAP для bitmap. Скорее, копия изображения выполнена в конструкторе, и изменения не пишутся обратно в исходную битовую карту даже во время выполнения деструктора. Новую битовую карту можно использовать как копию при создании, поэтому для получения GDI+ нарисовать память из GDI и применить изменения к подходу, как следует из следующих HBITMAP HBITMAP действий:

Источник

Графические и мультимедийные компоненты
пользовательского режима могут
взаимодействовать с ядром операционной
системы двумя способами. В GDI, DirectDraw,
DirectSD и OpenGL вызовы пользовательского
режима проходят через библиотеку
gdi32.dll, предоставляющую интерфейс к
сотням системных функций. Для взаимодействия
с драйверами видеопорта и мультимедийными
драйверами вызовы пользовательского
режима используют обычный интерфейс
API файлового ввода-вывода, входящий в
базовый сервис Windows. Вызовы системных
функций файлового ввода-вывода
обрабатываются диспетчером ввода-вывода
исполнительной части режима ядра,
который обращается к соответствующим
драйверам. Вызовы GDI, DirectDraw, DirectSD и OpenGL
проходят через графический механизм,
который передает их драйверам конкретных
устройств.

К числу модулей операционной системы
относятся ntoskrnl.exe (передача системных
функций, диспетчер ввода-вывода),
win32k.sys (графический механизм), mcdsvr32.dll
(сервер MCD) и hal.dll (HAL). Исполнительная
часть ядра Windows NT/2000, ntoskrnl.exe, является
самой важной составляющей ядра ОС. В
графической системе она в основном
отвечает за передачу вызовов функций
графической системы графическому
механизму, поскольку в последнем
используется тот же механизм вызова
системных функций, что и другие системные
функции. HAL предоставляет в распоряжение
драйвера графического устройства
средства для таких операций, как чтение
и запись аппаратных регистров. Благодаря
этому другие компоненты ядра в меньшей
степени зависят от платформы.

11. Архитектура графической системы Windows (gdi)

GDI (Graphics
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,
что даёт программистам доступ к большему
количеству аппаратных возможностей.

12. Архитектура directx

DirectX (от англ. direct — прямой,
непосредственный) — это набор API,
разработанных для решения задач,
связанных с программированием под
Microsoft Windows. Наиболее широко используется
при написании компьютерных игр. Пакет
средств разработки DirectX под Microsoft Windows
бесплатно доступен на сайте Microsoft.
Зачастую обновленные версии DirectX
поставляются вместе с игровыми
приложениями, так как DirectX API обновляется
достаточно часто, и версия, включённая
в ОС Windows, обычно является далеко не
самой новой.

Структура DirectX очень сильно отличается
от OpenGL. DirectX
основан на
модели COM(Component Object Model). В
отличии от простого вызова функций эта
модель предполагает выполнение некоторых
дополнительных действий, связанных с
компонентной архитектурой DirectX. Такая
архитектура имеет как достоинства так
и недостатки. В частности, код, в котором
используются вызовы DirectX обычно не
является лёгко читаемым и понимаемым.
Поэтому даже рисование простого
треугольника требует огромного объёма
кода. И для упрощения программирования
разработчики Microsoft создали отдельную
библиотеку, которая скрывает часто
используемый код.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #